Most active commenters
  • (6)
  • EnPissant(6)
  • veber-alex(5)
  • jsheard(3)
  • conartist6(3)
  • cyanf(3)
  • rvnx(3)
  • ricardobeat(3)

←back to thread

677 points meetpateltech | 94 comments | | HN request time: 0.263s | source | bottom
1. extr ◴[] No.45117263[source]
Zed is so great, I do wish they would focus just a little bit more on bringing the UI just a bit more up to parity with VS Code, I would switch full time.
replies(3): >>45117325 #>>45117438 #>>45118430 #
2. sirodoht ◴[] No.45117325[source]
What do you feel is missing from the UI?
replies(8): >>45117370 #>>45117454 #>>45117649 #>>45117711 #>>45117750 #>>45118013 #>>45118359 #>>45118829 #
3. tmdh ◴[] No.45117370[source]
I feel like the UI is not as smooth as VSCode. There is a slight lag when scrolling.
replies(4): >>45117436 #>>45117474 #>>45117479 #>>45117502 #
4. Longhanks ◴[] No.45117436{3}[source]
Wait what? Isn't a super fast UI one of their main selling points, what led them to write their own rendering in Rust?

...and now they lose to a web app?

replies(3): >>45117487 #>>45117533 #>>45117622 #
5. TheRoque ◴[] No.45117438[source]
What's so great about zed ?
replies(4): >>45117489 #>>45117862 #>>45118952 #>>45124588 #
6. sapiogram ◴[] No.45117454[source]
Their font rendering looks awful on non-high dpi displays, and the devs don't seem to care at all. https://github.com/zed-industries/zed/issues/7992
replies(6): >>45117670 #>>45117671 #>>45118505 #>>45118602 #>>45118711 #>>45119498 #
7. mlnj ◴[] No.45117474{3}[source]
Smoothness and frames per second is the core of why they were building a very optimized editor. Not sure if it is just your machine that it is not leveraging the right bits.

For me the extension ecosystems is something I really like about VSCode, but that is an entirely different matter.

8. rtaylorgarlock ◴[] No.45117479{3}[source]
Wow. This might be the 1st time i've seen someone comment negatively regarding UI performance. Zed is one of the fastest programs i use. I used to laugh when seeing them market fps and such, but yeesh it's fast
replies(1): >>45118237 #
9. seanssel ◴[] No.45117487{4}[source]
I have no idea what they're talking about. Maybe they're used to a smooth scroll animation in VS Code or something? Zed feels snappier/lighter in just about every way to me.
replies(1): >>45117524 #
10. simonw ◴[] No.45117489[source]
It uses a fraction of the memory of VS Code and is much faster to launch.
replies(3): >>45117638 #>>45118055 #>>45118794 #
11. macawfish ◴[] No.45117502{3}[source]
This could be an issue with GPU drivers. I experienced some incompatibility with GPU kernel drivers that allowed Zed to crash the whole window manager during text selection.
12. sayrer ◴[] No.45117524{5}[source]
No kidding. It is /so/ fast. It has remote development like VS Code, and most of the features I use, so it's my main thing now. Claude Code was the only thing that made me wince, since I wondered if I was living in the dark ages. VS Code of course has many more extensions, but I don't use that many.
13. sapiogram ◴[] No.45117533{4}[source]
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.
replies(1): >>45119382 #
14. ◴[] No.45117622{4}[source]
15. johnisgood ◴[] No.45117638{3}[source]
Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow. Emacs starts up faster than an empty Zed window, unfortunately. It is still way faster than IntelliJ but comparing it to that is a low bar.

VSCodium starts up faster for me than Zed which I compiled yesterday with release mode. Here I am referring to the time spent just on waiting for the window to start up, not the extensions and all that I am using with VSCodium, that takes time. I wonder why this is, that VSCodium shows the window quicker than Zed.

Regardless, I will give Zed a try with Go development. I assume Zed has extensions, too? Are there any extensions for Go? If so, I might replace VSCodium with Zed but only if it has similar features to VSCodium. If not, I will stick to VSCodium as there is no reason for me to change.

replies(2): >>45117908 #>>45117953 #
16. kenhwang ◴[] No.45117649[source]
Top of my head switching between IntelliJ and Zed:

- Git UI is extremely barebones with no support for other VCS

- No merge tool or side-by-side diffs

- Configuration is all JSON

- Would be nice having a full file tree for the search editor instead of just the list; having the functionality split between a tab and the outline panel is quite clunky.

- Ability to move panels (files/git/console/debugger/etc) into standalone windows or other configurations (multiple docks per side, multiple copies of the same panel linked to a specific tab).

Zed is basically a slightly more featured text editor, so it does a good job when I just want to open something quickly and do small edits. So it's really replacing Sublime Text.

But I find myself hopping out to other tools when I'm using Zed which wasn't really common with IntelliJ. So I still want to use a proper IDE for proper development work.

replies(3): >>45117696 #>>45117882 #>>45117973 #
17. jsheard ◴[] No.45117670{3}[source]
That figures, their lead platform was the Mac where HiDPI is totally ubiquitous, so their renderer probably has no provisions for subpixel font rendering.
replies(1): >>45119819 #
18. delta_p_delta_x ◴[] No.45117671{3}[source]
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.

replies(2): >>45118939 #>>45119837 #
19. WA ◴[] No.45117696{3}[source]
No side-by-side diff is a deal-breaker for me unfortunately.
replies(2): >>45117789 #>>45119539 #
20. valentinnnnn ◴[] No.45117711[source]
I can’t really pin down the reason but somehow vscode just feels a bit more „balanced“ to me - the font sizes, little borders, icons and details, it’s more consistent.
21. pseufaux ◴[] No.45117750[source]
Merge tool is the big one for me
22. ronyeh ◴[] No.45117789{4}[source]
I use git icdiff (a plugin) in my terminal. I use Zed and VSCode GUI editors, but I don’t care to use their git tools. Command line git is fine.

https://www.jefftk.com/icdiff

23. digitaltrees ◴[] No.45117862[source]
It’s built by the team that built atom which was way better than vscode but was mothballed when Microsoft bought GitHub.

They built it from scratch and not on electron bloat so it is a much better foundation. It will take a long time to reach parity with vscode but when it does it will smoke it.

replies(1): >>45118796 #
24. seanssel ◴[] No.45117882{3}[source]
The IntelliJ 3-way mergetool/diff viewer is best in class. I haven't found anything else that touches it.
replies(2): >>45118219 #>>45118436 #
25. yobert ◴[] No.45117908{4}[source]
Zed has easy to use extensions, but also Go support is built in. (syntax highlighting, gofmt on save, and language server support)
replies(1): >>45118859 #
26. tracker1 ◴[] No.45117953{4}[source]
I'm not a Zed developer, but I'm pretty sure LSP interfaces are pretty much standardized now, in large part to VS Code's efforts, so they're pretty consistent across most editors that support them.

That doesn't mean Zed will have all the other extensions that VS Code has... Recently added the new SQL Server extension(s) and it's been at least interesting, in a way slightly better than using SMMS. It's pretty much burrowing the UI from Azure Data Studio (or whatever it was called). Haven't tried similar for PG/SQLite etc yet.

27. modernerd ◴[] No.45117973{3}[source]
> Configuration is all JSON

Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?

> Ability to move panels (files/git/console/debugger/etc) into standalone windows

Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)

replies(2): >>45118310 #>>45118319 #
28. SJMG ◴[] No.45118013[source]
https://github.com/zed-industries/zed/discussions/20086
29. trashface ◴[] No.45118055{3}[source]
Do people really need that with modern computers? My computer is 10 years old and I just restarted VS in the last project I was working on. It was about 4-5 seconds before I could edit the text, which doesn't seem long. And I have 17GB available memory. Anyway it doesn't matter because I just don't restart VSCode that much. I do open projects in new windows and those can get slow, but the slow ones are mostly just rust code with rust-analyzer overhead, and when dealing with rust, slow-opening projects are only the beginning.

I don't know, it feels like Zed popularity is just people chasing the latest editor hotness, a time-honored traditional programmer ritual to be sure, but still, just a ritual. And now it seems zed devs have to put AI in front of all other initiatives, probably because of the VC funding they took.

I could see not wanting to use VSCode for other reasons, like MS pivoting back to "be evil", but at least in my little bubble, performance is not one of them.

replies(1): >>45118821 #
30. conartist6 ◴[] No.45118219{4}[source]
Me either. I thought by now it would be standard UX everywhere, but that is very much not so.
replies(1): >>45118420 #
31. hu3 ◴[] No.45118237{4}[source]
> Wow. This might be the 1st time i've seen someone comment negatively regarding UI performance

Here you go: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

> I found Copilot tab completion completion to be VERY slow in Zed, for some reason.

> Zed still takes a relatively long time to start on my old desktop. I thought something was wrong but no, it is just THAT slow

> I have tried it out and by default it was so slow as to be unusable. After discovering it required some customization in /etc (because it's the only GUI application that fails to recognize my GPU on a very popular distro with next to zero customization, because I game a lot on Linux - weird how that's a me problem and not a Zed problem) it got better, but still noticeably slower than VS Code.

> I mean, good AI tab completion feels like a super power. Zed’s is not that good. It’s slow and normally not at all what I want.

> Zed tab is a lot worse in comparison (partly because it’s slow)

> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).

> All I'm saying is that contrary to what someone else said about the software being "fast" I tried it and at startup, it was unusably slow.

> Tried using zed on Linux (pop os, Nvidia) several months ago, was terribly slow, ~1s to open right click context window.

> Zed is as close as it gets, I also use it, but it is still slow and cumbersome sometimes.

I'll stop here. There are other 4 pages of comments to pick anecdotes from, in this simple search alone.

replies(2): >>45118937 #>>45119841 #
32. aseipp ◴[] No.45118310{4}[source]
Yes, a GUI for settings is nice if only for one thing: so there can be a search box that you can use to search over all the settings to find what you need in a pinch. It's a lot friendlier if I can do something like "Open Settings > Ctrl+F > 'Font'" or whatever than having to go find the manual and look it up.

I don't care about the configuration language so much personally (though JSON is of course pretty lame in a lot of ways for that task.)

replies(1): >>45119529 #
33. kenhwang ◴[] No.45118319{4}[source]
> Curious as someone dabbling with building an editor: what do you prefer? A different configuration language? A GUI? How do you save and sync settings? Just with JetBrains account sync?

Really just a GUI for editing, the storage format can still be JSON and synced/backed up however you handle text files.

It just really nice having settings grouped by categories, with dropdowns for possible values, indicators for changes from default values or values overridden by project settings, search/hide/filters, and tooltips for what it does.

Right now the experience with Zed is: open the settings file, open the default settings file for documentation, and basically use search and copy-paste magic value strings/int/float/nulls into the right nested object/key.

> Is Zed's "zoom in" feature (shift-escape) that quickly maximises the active pane (excluding the file browser/git pane) enough? Or are you looking for the separate window experience of IntelliJ? (e.g. JetBrains lets you pop-out the commit window, I believe, which can be nice since once you close it you're back in the editor with nothing to switch or rearrange.)

Really the separate window experience (including the file browser/git pane). Really nice having the git panel just open on a window so you can quickly glance at changed files and quickly jump back to them for more editing. Or having search results able to spawn tabs in another pane/window so you don't have to keep switching back to search or rearranging the tab after opening the file from it.

Or even just expanding the workspace across monitors. Right now you can't even move tabs into its own window or across windows.

34. extr ◴[] No.45118359[source]
People are bringing up a lot of sophisticated stuff. Honestly for me it would just be a more flexible panel system that lets me see eg: File Explorer, Git UI, AI mode, etc, all at the same time.
35. user432678 ◴[] No.45118420{5}[source]
Sublime Merge comes to mind, but I used it briefly before switching to JetBrains products.
replies(1): >>45119779 #
36. cpuguy83 ◴[] No.45118430[source]
Anyone running this on Linux? I find it works fairly poorly there. To be fair, vscode is also not great for me (especially vim mode) on Linux.
replies(3): >>45118692 #>>45119018 #>>45143211 #
37. koakuma-chan ◴[] No.45118436{4}[source]
> I haven't found anything else that touches it.

Have Claude Code resolve merge conflicts, problem solved.

replies(2): >>45118833 #>>45119901 #
38. stouset ◴[] No.45118505{3}[source]
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.
replies(3): >>45118543 #>>45119251 #>>45122441 #
39. ◴[] No.45118543{4}[source]
40. freehorse ◴[] No.45118602{3}[source]
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.
replies(1): >>45119269 #
41. WD-42 ◴[] No.45118692[source]
Running on Linux here. Working great for me. If you are referring to font rendering, unfortunately the Rust ecosystem for it is still young, so there are improvements to be made.
42. EnPissant ◴[] No.45118711{3}[source]
I won't use zed for this very reason.
43. veber-alex ◴[] No.45118794{3}[source]
VScode starts very quickly for an electron app. MS did a great job there.

Memory usage of the IDE doesn't matter much when your language servers can eat 10s of gigs of RAM.

replies(2): >>45119389 #>>45122969 #
44. veber-alex ◴[] No.45118796{3}[source]
So...nothing.
replies(3): >>45119387 #>>45119611 #>>45162191 #
45. veber-alex ◴[] No.45118821{4}[source]
I agree with you.

I tried Zed several times and I just don't see the point.

The main issues with VScode over something like the Jetbrains IDEs is that language servers are just not as powerful or as integrated to the IDE as the Jetbrains solution can be and Zed does nothing to solve it.

I don't think it being a native app offers much added value.

replies(1): >>45121391 #
46. insane_dreamer ◴[] No.45118829[source]
Git: IntelliJ is miles ahead. And we’re talking about essential features like three-may merge panel, diffing 2 files, diffing same file between branches, diffing folders, etc

Tests:. Zed is bare bones compared to IntelliJ (rerun failed tests, export list of failures, go to failed lines easily etc

The AI stuff is cool but it won’t get me to switch from PyCharm.

47. insane_dreamer ◴[] No.45118833{5}[source]
One area I would not trust CC
48. johnisgood ◴[] No.45118859{5}[source]
It's builtin? Nice. I will give it a try, then!

I wonder why the startup time is slow though, may have to debug that one.

49. cyanf ◴[] No.45118937{5}[source]
The other examples you listed are valid, but A.I tab auto complete is a model & inference issue unrelated to the editor.
replies(2): >>45119374 #>>45119600 #
50. AlexandrB ◴[] No.45118939{4}[source]
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.

replies(2): >>45118979 #>>45119423 #
51. cyanf ◴[] No.45118952[source]
Snappiness is the primary reason for using Zed.
52. jsheard ◴[] No.45118979{5}[source]
> 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.

Discussion from the time: https://news.ycombinator.com/item?id=17476873

replies(1): >>45119169 #
53. neurostimulant ◴[] No.45119018[source]
I don't notice any major issue yet, except for that freezing on wayland which seems to be fixed already.
54. delta_p_delta_x ◴[] No.45119169{6}[source]
> 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.

replies(2): >>45119323 #>>45119335 #
55. EnPissant ◴[] No.45119251{4}[source]
It's not rare at all. It's more common than not for people developing on monitors.
replies(1): >>45120901 #
56. EnPissant ◴[] No.45119269{4}[source]
You may not notice because macOS fonts look terrible (blurry) on any monitor that is not hidpi. Zed is just par for the course here.

Meanwhile on Linux and Windows, they still implement subpixel rendering so fonts look great on 1440p.

replies(2): >>45119504 #>>45124185 #
57. ◴[] No.45119323{7}[source]
58. jsheard ◴[] No.45119335{7}[source]
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.

59. rvnx ◴[] No.45119374{6}[source]
It is a feature that they control. Whether it comes from the model, a bad prompt, a bad provider or a bug in their implementation is their responsibility (especially considering you have to pay per-request AI features).
replies(1): >>45119699 #
60. ◴[] No.45119382{5}[source]
61. robinhood ◴[] No.45119387{4}[source]
Your comment is as insulting as it is indicative of a complete lack of knowledge about the world of editors and software development in general.
replies(2): >>45119606 #>>45119802 #
62. ◴[] No.45119389{4}[source]
63. c-hendricks ◴[] No.45119423{5}[source]
- As mentioned, macOS removed subpixel anti aliasing a while ago

- Zed is not an electron app

- In the linked issue you can see that this issue does not exist in Electron.

64. TiredOfLife ◴[] No.45119498{3}[source]
At least on Arch it works fine on 13" 1080p, 24" 1440p and 27" 4k displays.
65. ricardobeat ◴[] No.45119504{5}[source]
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.
replies(1): >>45119562 #
66. ricardobeat ◴[] No.45119529{5}[source]
You get almost the same effect by typing “font” as a config key and going over autocomplete suggestions.
67. ricardobeat ◴[] No.45119539{4}[source]
This is a great divider between people who want an IDE vs a text editor - Zed explicit is the latter.
68. EnPissant ◴[] No.45119562{6}[source]
There are 2 issues on Apple:

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.

69. fkyoureadthedoc ◴[] No.45119600{6}[source]
Idk if 'linux + gpu = problem' is surprising or very relevant either.
70. veber-alex ◴[] No.45119606{5}[source]
If you think "build by atom team" and "not electron" are any kind of serious advantage for any peace of software than your are the one who lacks knowledge about software development.
replies(1): >>45119614 #
71. rvnx ◴[] No.45119611{4}[source]
I think you do not understand the value proposition of Zed.

It is an editor made for people who are used to double-clicking individual files rather than opening a folder in VS Code, so they close and open their editor dozens or even hundreds of times per day.

Let's say VS Code takes 5 seconds to boot.

Some programmers may argue: "yes, I spend 3 hours on a project or just leave it open overnight, so 5 seconds per week is nothing"

But here is not the case, it is for programmers who come from Notepad/Sublime/Notepad++/emacs/vi, and who opens a single file and closes the editor right after.

If you work 2 hours, maybe 4 files per minute, this means 120 * 4 openings = 480 openings.

It means you would have wasted 2400 seconds (40 minutes per day!) waiting for VS Code to open (about 33% of the 2-hour work session spent waiting)

Yes, like with Notepad or Zed, you lose some features like Colors or Syntax checking, but still, time is the most precious thing in life.

For users who come from very advanced but slow text editors like Microsoft Word (used in coding exams: https://stackoverflow.com/questions/76102874/single-and-doub... or programming courses: https://youtu.be/0TVugOJtAiU?t=162 ), this is truly revolutionary and life-changing.

replies(3): >>45119775 #>>45121680 #>>45121704 #
72. rvnx ◴[] No.45119614{6}[source]
Made me think about: https://news.ycombinator.com/item?id=43041923 where they mention Atom as well
replies(1): >>45125318 #
73. cyanf ◴[] No.45119699{7}[source]
That’s true if we’re evaluating Zed as a product, but the GP is discussing Zed U.I perf specifically.
74. veber-alex ◴[] No.45119775{5}[source]
You are right. I don't understand.

How can any software developer work when they need to open and close 4 files per minute? I have never met or heard of anyone working like this.

replies(1): >>45120229 #
75. conartist6 ◴[] No.45119779{6}[source]
Yeah, no, I tried that thinking it was going to be the JetBrains merge as a standalone product and it simply does not have the three-way sauce. Sublime doesn't even offer any way I can view a live base->left or base->right view as I do the merge does it?
76. sexyman48 ◴[] No.45119802{5}[source]
A complete lack of knowledge? At least GP understood 90% of his peers don't know vscode is built on a browser framework, and wouldn't care.
77. jamesgeck0 ◴[] No.45119819{4}[source]
It's frustrating because even on macOS, every other text editor looks better on a 1440p display.
78. jamesgeck0 ◴[] No.45119837{4}[source]
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.
79. coder543 ◴[] No.45119841{5}[source]
> Here you go

That is a list of search results of people complaining that VS Code is slow compared to Zed.

replies(1): >>45125674 #
80. neurostimulant ◴[] No.45119901{5}[source]
"vibe merging"
81. typpilol ◴[] No.45120229{6}[source]
Right lol. It's so ridiculous
82. stouset ◴[] No.45120901{5}[source]
That's wild to me. That's something I don't think I can ever go back to at this point.
replies(1): >>45121074 #
83. EnPissant ◴[] No.45121074{6}[source]
Do you use macOS? Fonts look great on Linux with hinting and subpixel rendering at 1440p. I could never use macOS with such a setup.
84. ◴[] No.45121680{5}[source]
85. bergheim ◴[] No.45121704{5}[source]
This has to be a joke.

No one ever closes emacs.

86. heavyset_go ◴[] No.45122441{4}[source]
FHD and below will keep existing on mobile for hardware and power consumption reasons
87. eviks ◴[] No.45122969{4}[source]
> for an electron app

But the comparison here is broader than electron apps...

88. freehorse ◴[] No.45124185{5}[source]
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.

replies(1): >>45125186 #
89. wolvesechoes ◴[] No.45124588[source]
It is new and is talked about a lot on HN and Reddit. And it is not developed by Big Bad Corporation, instead it is developed by Good VC-backed Startup.

In this demographics, hype rarely is connected to technical qualities, they are used more as a post-hoc rationalization.

90. EnPissant ◴[] No.45125186{6}[source]
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.
91. conartist6 ◴[] No.45125318{7}[source]
It would be relevant that they were the team behind Atom if they seemed to understand the lessons of Atom...

Instead of learning from what worked and fixing what didn't, they just threw everything away and wandered off in some totally different direction. They did the reactionary kind of learning instead of the theory-building kind: https://xkcd.com/242/

92. hu3 ◴[] No.45125674{6}[source]
There are tons of complains about zed performance there.

Do you think messages like this are talking about VSCode performance?

> In my personal experience I couldn't use Zed for editing python. Firstly, when navigating in a large python repository, looking up references was extremely slow (sometimes on the order of minutes).

93. johntash ◴[] No.45143211[source]
Zed was working great for me on linux. It recently broke support for using a remote env over ssh, but locally still works fine.
94. digitaltrees ◴[] No.45162191{4}[source]
Did you miss the point about it being built on a fundamentally better tech stack by a team with a track record of better design decisions?