> I bet it’s smooth given how concurrent friendly Go is with channels and go routines etc.
You can do the same in any language with threads, and a library providing channels. Hell, you could probably do it better with a library, go's channels are unnecessarily error prone with nils, channel closing, and cleanup behavior.
While I agree on channels, you can't easily reproduce the behavior of Go's threads in other languages. The whole Go IO library is built with support for Go's green threads. The result is that 1000 Go threads waiting on IO operations will actually issue only a handful of OS non-blocking IO calls and have the runtime handle polling and waking up the right threads.
Not sure how relevant this is for UI operations, to be fair. The C#/JS style async/await model actually seems more amenable to controlling which works happens on the necessarily single GUI thread and which parts happen in background threads, and how to sync them later.
To be fair that video game was released (in early access) during Rust 0.8 - the language was already popular on HN I think, but not as a "you should use this in prod" type of thing.
At least in my own experience, I tried building a relatively simple static SPA NextJS React app with their router, and wanted to host it on CloudFlare Pages.
It ran locally in dev mode just fine. Once I deployed it on CFP, the router broke. No errors in the console, it just didn't work.
If I'm forced to use Vercel to make a simple SPA work, which then forced me into paying for their service, that's the problem.
There's a reason everyone writes their GUI apps in Electron nowadays. Browser have spent 30 years figuring out fast rendering, it's hard to beat that, even with native code.
That figures, their lead platform was the Mac where HiDPI is totally ubiquitous, so their renderer probably has no provisions for subpixel font rendering.
While I do not doubt that there are people who experience this on some monitor/OS combinations, I have used zed on basic 1080p and 1440p 24" monitors with no issue. Sometimes I have general issues with some monitors in macos, which is usually due to some super-resolution/sharpness setting on the monitor itself that I need to adjust, but nothing specific to zed. All I say is that these issues are far from universal with non-hidpi monitors.
As I said, I do notice when it is blurry, and in such a case it is a problem with anything that is rendered on that monitor not just zed. As I said, this does not happen "on any monitor" that is not hidpi. I use multiple operating systems on my day to day work, so I am not as brainwashed by apple as to not notice when such rendering issues arise.
I know some people have bad experiences with 1440p and macos for some reason, but I haven't had any such experience that I could not fix. So all these are not universal. Some people act as if any monitor below 200dpi will look terrible on macsos. This is definitely not the case.
Other operating systems have three times the horizontal resolution when rendering fonts. It’s simply not possible to fix it on macOS because they removed subpixel rendering. It’s absolutely true that macOS fonts look substantially more blurry than fonts on other operating systems that implement subpixel rendering when you’re using a 1440p monitor.
This discussion goes back twenty years, with Apple going for preserving the original typeface appearance over crispness. It depends what you value the most and is entirely subjective.
1) How much font hinting to apply. More hinting changes the shape to make glyphs line up better with pixels so that less antialiasing is required. macOS prefers very light hinting to preserve shapes at the cost of blurriness. This is what you are talking about.
2) Subpixel rendering. This effectively triples the horizontal resolution when rendering fonts, and does not affect the shape at all. Fonts look dramatically better on normal dpi displays when using it. macOS removed support for this many years ago. This is what I'm talking about.
While this is probably annoying, I have to imagine that non-hidpi displays are becoming rarer and rarer. It's probably not a great idea to spend a lot of work on a feature that will only ever see declining use.
My guess: their shaders or text rendering don't account for sub-pixel anti-aliasing, which is critical to getting decent text rendering on low pixel density displays.
If they'd used Skia (which is what Electron and Chromium use), they would've got this for free. Instead they tried to reinvent the world and didn't realise how big the world was.
As far as I can figure out, the root issue is even simpler than that. Their hinter is broken. The edges of characters aren't aligned with the pixel grid, so there's lots of fuzzy/blurry looking text.
I love how we just reinvent the wheel again, and again, and again, and again...
MacOS native apps have had great sub-pixel rendering all along, but I guess since we have to develop everything in Electron now it's time to reimplement all the exiting functionality.
> MacOS native apps have had great sub-pixel rendering all along
Apple removed subpixel anti-aliasing in Mojave, seven years ago, because it's not necessary on the HiDPI/Retina displays they ship as standard. They still do greyscale anti-aliasing but that's not the same thing as subpixel.
> because it's not necessary on the HiDPI/Retina displays they ship as standard.
I disagree. Subpixel anti-aliasing triples the available horizontal resolution, and makes text crisper. The algorithms are known and regardless of the density it should always be applied to text and vector graphics elements.
The RGB stripe layout is so useful that OLED manufacturers are moving to it in 2026, away from the long-derided PenTile where magenta/green fringing is seen even on the densest displays.
In fact rendering on macOS is completely broken, and I don't know how people stand by it. At any scaling factor selected that is not a perfect factor of the actual hardware resolution (the 'looks like' value in Settings), the final framebuffer is scaled and interpolated to the display resolution, and everything is noticeably more blurry.
Windows has had some form of hardware-independent rendering since Windows 7, and proper pixel density control arrived in Windows 8.
Subpixel rendering is effective but it's also a massive pain in the ass to maintain, especially if you want to take full advantage of the GPU. Microsoft has kept it around for much longer but even they are steadily moving away, bits and pieces of the Win11 UI render with greyscale AA regardless of system settings because their newer GUI toolkits don't even attempt to support subpixel fonts.
That said, for something like a text editor where fonts are central the entire application and the worst subpixel edge cases like animation are unlikely to come up, it's maybe not unreasonable to ask them to go the extra mile. It's going to be a sticking point on Windows and Linux for a long time if they don't.
> Giving us $50 trains to Tromsø instead of $500 planes.
It's only $50 if the government pays for the rest of the ticket. $50 per passenger won't even cover track maintenance. Source: My ass, but I still think I'm right.
You can do the same in any language with threads, and a library providing channels. Hell, you could probably do it better with a library, go's channels are unnecessarily error prone with nils, channel closing, and cleanup behavior.