For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | brikym's commentsregister

It will also pull more users in. I don't want to be looking at code. I want more of a codex style app where it's easy to shove all my projects in one place and context switch endlessly.

If you don't want to be looking at code, why download a code editor? Why not just use the Codex app?

Turning Zed into Codex alienates the existing user base who installed Zed because it's a code editor. If I wanted Codex I would have installed Codex.


Let's hope John takes his job Siriously

Some disgruntled Atlassian employee wants his stocks to be more valuable despite the SLT dumping millions per day.

Not unlikely given the crash in Atlassian's share price over the last year or so. When I was in NetApp a long time back, such rumours would often do the rounds when the share price took a dip, with Oracle and IBM usually touted as the likely buyers. NetApp is still doing strong more than a decade later :-).

It's happening. Cursor 3 moved to rust. A lot of people are using Zed (rust) instead of vscode.

It won't be "happening" until Slack, Teams, and Discord leave Electron behind. They are the apps that need to be open 24/7.

It's not entirely clear what the connection is.

We're not doing Electron because some popular software also using it. We're doing Electron because the ability to create truly cross-platform interfaces with the web stack is more important to us than 300 MB of user memory.


> web stack is more important to us than 300 MB of user memory.

May I never have to use or work on your project's software.


> We're doing Electron because the ability to create truly cross-platform interfaces with the web stack is more important to us than 300 MB of user memory.

It's closer to 1GB but trust me, everyone is well aware of your priorities.


"I would rather spend the user's money than my engineer's time"

Teams works similarly in browser tab and "natively". Slack was similar if I remember correctly.

You should check the memory use of that browser tab. You’re not saving much either way running in a browser or in Electron, which is effectively a browser.

I only ever use Discord in a browser window.

"cursor 3" is just a landing page. The editor is still the old vscode fork...

Are you sure about Cursor? I haven't seen anything about that, I think it's still based on VSCode/electron.

No. I saw they rebuilt it with some rust involved. It's no longer a vscode fork.

We now know what happens to a lot of influencers and wannabes: https://dailyhive.com/vancouver/dubai-porta-potty-influencer...

The car junk yards are also really sketchy https://www.youtube.com/watch?v=IrGCv3sZXAQ


Problems such as 'Dubai porta-potty'

The idea of style being separate from content is great for something like a blog or a wiki article but when you're building an app each design needs completely different html and then it makes sense to couple. No naming. No hunting down styles. The html is your ccs. You get a formatter to sort the classes and it will compress away all the repetitive junk. Besides who looks at code much these days anyway.

As far as I can tell these tools have quite a low ceiling. Great to start off with but but at some point I just find it easier to express myself with bezier curve handles than prompting. Canva, and Stitch (and maybe Claude Design) don't go that far.

There is always one thing that bites you because Cloudflare is different. I just built an AI game (sleuththetruth.com) and the primary reason it's so slow to prompt a new board is actually not because of AI latency. It's because CF workers have a limit of 6 connections (including spawned workers). There is no way to gulp down all the wiki images I want all at once. If I had put the backend on Railway I don't think I'd have this issue.

You can farm out the requests to a bunch of Durable Objects. Each DO will have a separate six-concurrent limit. And you can send unlimited concurrent requests to Durable Objects. (This is not an exploit, this is working as intended. The concurrency limit exists to prevent creating excessive connections from a single machine; farming to DOs means the requests are spread out.)

Also note that as of recently, the concurrent limit applies only up to the point that response headers are received, not during body streaming.


Great tip. I knew about #2 which still doesn't help me but #1 is nowhere in their docs!

just keep-alive it with pipelining, depending on the server, 100k+ RPS.

Fair. I've made some changes to improve it.

Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You