The Creators of the Atom Code Editor Open-Source Zed, Their New Rust-Based High-Performance Editor

runs only on MacOS
And
get it into the hands of millions of developers
Seems contradictory
- Yup. Especially since it's written in Rust... Like why? Rust has a great cross-platform story.
  
  they've written a custom GPU framework to achieve the performance the level of performance they have. it's currently only compatible with macos, but is being ported to other operating systems.
- runs only on MacOS for now
  it will be released on both Linux and Windows, with Linux support currently being the top ranking issue on their GitHub page. they have a tracking issue showing that many pr's have already been merged working towards Linux support.
- I guess if you are committed to supporting a hard to support platform, may as well get it out of the way first?
  But yeah, seems like a pretty poor release.

Sounds cool! Too bad it's only on MacOS atm
- They wrote their own GUI toolkit (oof) and it's hardware accelerated (argh), so OS portability is going to be unusually difficult unless they planned for it from the beginning. No mention of that in the article, so I doubt they did.
  
  They already have very experimental Linux support. You have to build whole app yourself though. I'd say that in month or two we'll get a binary. You can track Linux porting progress in this issue
  
  I mean on the one hand, the hardware acceleration is awesome. The GUI toolkit is not of course (I assume MacOS has a default one to make everything look like it belongs?), but at least they made it look like a native app instead of the usual electron shit where it's clearly a web page with a window border and some design 15y old me might think is cool but 16y old me would already have been ashamed of.
  
  Its already possible to build manually on linux and there's a tracking issue.
  *edit. same as the other post
  
  Sounds like gimp with gtk (gimp toolkit) all over again
- I'm waiting for it to come on Linux.

Looking forward to the memes once this dies
(Zed's dead)

I'll be watching this one. It looks nice. Please come to Linux. I do loves me my vim. I did not like setting it up as much as I thought I would to be an IDE. I'm sorry I was mean Zed.
- I've been trying out Helix as of late. It's a bit different than vim, but I'm beginning to like it.
  
  Helix's autocomplete is too bad for me to be able to like it
- Yes, that was mean, because nobody is able to make another editor as powerful as vim.
  
  Time will tell for sure, but helix is looking really good and once they have support for plugins I'm rather sure it will be a very, very powerful editor.

I tried it briefly. It certainly is a lot snappier than Atom ever was, I'll give it that. Seemed to be pretty good with Python, but when I opened some C++ source, it went around reformatting my indentation and replaces tabs with spaces. I will have to see if there is a way to disable all that, as I found it obnoxious.
- If I wrote an IDE and detected tabs I'd just have it delete the codebase
  
  It was more than just tab conversion. For example, it decided on its own that:
  
  if(...) { ... } else { ... }
  would look better like:
  
  if(...) { ... } else { ... }
  I mean I guess I could live with that, but really? I imagine there's some config where you can disable all this, but it just doesn't seem worth some giant git commit every time I touch a file with the editor.

Honestly even if they had coded this to anything other than MacOS I wouldn't use it, I'm not too keen on learning a software that's developed by a team that archived their previous project, given how popular atom was when they decided to archive it it concerns they could just do the same with this one.
- On the plus side, the fact they stopped Atom development has allowed our community fork of Pulsar to flourish and it has seen loads of active development over the last year. I do find it hard to blame the original team, it was clearly a Microsoft thing to make sure they put all focus on VSCode.
- I’m assuming it was a MS decision

Shout out for Lapce.
I remember reading a bit about this (from Atom) a while back and having iffy feelings... I don't wish to slander based on vague memories but certainly at the time I hoped Lapce would catch on instead.
It's still in development, but has a handful of aspects that I really like as the right way to go about things.
https://lapce.dev/

Nice, been finding vscode more and more laggy after each update, so hopefully this is something to replace it with at some point.
- The inevitable cycle of modern open-source text editors. First there was Atom, then that got too slow and most switched to VS Code. Next seems to be Zed... I wonder what comes after it!
  
  Lapce looks pretty cool, for an alpha.
  
  Seems fair tbh. As long as the total usability goes up to that is!
- I had the same prob, when I swapped to Codium and paired down my plugins, it was snappy again.

How did Zed get so much publicity? Do they happen to have a lot of funding or something? I've seen a million of these posts and I'm just really uninterested, as does a big portion of comments I see.

🎉

I don't see the need of it.

It's strange because how much "powerful" or "high performance" a code editor needs? It's just , a code esitor you can code in notepad lol
- You can code in Notepad in the same way you can eat off the floor with your hands. Using better tools is a nicer experience.
  As for performance, when one of the world's most popular editor runs on Electron, it's not that hard to see why performance could be an issue when working on large projects on older hardware.
  I've never personally had an issue with VSCode's performance, but I'm also fortunate enough to be in a position where I can afford a relatively modern machine. Many others have to make do with what they have, which is why Zed might appeal to them.
  
  I mean, I rock JetBrains for a lot of stuff. It's a pig on resources, but man does it have a great feature set.
  
  Electron has other drawbacks than performance as well.
  The big one for me is that my workflow is based on vim, where you split tabs into buffers. There is no way to split a tab into windows in VSCode. Only windows into tabs, which is super dumb and annoying because related files are never shown together unless you click a bunch of tabs. Apparently the reasoning for this insane behavior is "yeah well electron is based on chromium so tough luck we can't do shit".
- I'll be honest it was surprising how much nicer using GPU accelerated terminal was for me.
  If you are in a ui enough snappyness is a nice to have for sure.
  That said this is an IDE not just a text editor, the automated tools is what sets the apart.
- I could notice the slowness of Atom when I compared it to VS Code. Sublime is also noticeably faster than VS Code, but the gap doesn't feel so wide that I want to jump the ship.
  I think it depends on the number of characters in the file that make the difference more noticeable.
- You can really see the difference between opening VSCode and Zed, even more so if you compare it to something like JB's Fleet editor.
  To be fair, it's not the easiest to compare right now since Zed is lacking a million features of Code, but if all the work they've done keeps it as fast as it is with features like user extensions it will be well worth it.
  I usually have ~10 different VS Code windows open at a time (yay microservices ❤️), so having something as fast as Zed would be really appreciated.
- Yeah like Atom or VSCode this is more a half-IDE in concept. Assuming it gets enough support it's somewhere between a text editor (but will be more sluggish than pure text editors and struggle with very large files but then you ought to have specialized log viewers for that anyways) and an actual IDE (but have only limited IDE features).
- Agreed. It's weird to put the performance of a text editor at the center of PR.
  I have sooooo many questions.
  Why do they compare a text editor's performance with that of IDEs??? CLion is possibly the slowest of all Jetbrains IDEs because the C++ language is very complex. Choosing CLion makes even less sense because IntelliJ is now public-testing a lightweight C++ CLion spinoff, which is faster than CLion.
  Why should I care whether my editor is written with Rust? C was fine as long as I trust the devs on security. Async doesn't matter at all to the enduser...
  Besides, if I wanted a snappy editor I just use vim.
  My fear is that they might have concluded that all the performance boost they made wasn't important as a text editor, and they are presenting some weird comparison to hide it.
  Besides, if you write C++, the bottleneck is not the typing response, but the code analyzer.
  It's also not like C++ is a language used by majority of customers. Why not advertise with JavaScript instead? Python? Those are also better fit for text editors. Because statically typed languages like C++ can benefit hugely from a full-fledged IDEs, taking away the room for this text editor further.
  It feels like their AI integration is not outstanding (probably not, indeed).
  The collaborative editing might not align well with their emphasis on responsiveness, either, because the network latency will be felt. Not to mention that collaborative editing is pioneered by IntelliJ, also.
  Why do you need another channel/chat management tool if your team already has a Slack? Why would your team use a chat platform that can be used only by mac users?
  As I indicated in my other comment, it's possible that the PC port of their GPUI-based GUI can be far slower due to the heave reliance on Apple Silicon. I even doubt a port is possible in the first place, especially if their code heavily relies on Apple-specific APIs for the Silicon.
  And all descriptions of their features are suspiciously vague. How are they better than a marketing scheme to raise the stock price?
  Maybe it is going to be just an average editor in the era of remote-office (looking at channels and collab edit), ChatGPT-assists (AI-integration) and async. Maybe it's a proof-of-concept that will soon give ways to another generation of editors.