I've seen a million and one text editors, and almost all of them offer the feature of being "fast <rocket emoji>" or "gpu driven" or "cleanly implemented" (now "AI integrated"; LOL). Never features that users actually care about. Perhaps this is just my ego taking, but I think I would struggle to develop such an app. What is the point in programming if you aren't presenting the user with anything new? I suppose the collaborative features in this are almost novel, but they seem misguided. It relies on other people using the same text editor as you, which is going to be quite difficult to organise.
How about a text editor which represents code as a syntax tree that is formatted as you type? Or one that has support for embedding multi-media content within source files? Or one with advanced program rewriting capabilities (in-lining functions, replacing struct members into getter methods, etc)? These things would all change the a user's experience much more than replacing the CPU rendering with GPU rendering. A text editor is the window through which we interact with code. It is an immensely rich domain for experimentation, yet the best most come up with is "what if there was a 10ms smaller latency on keyboard input?"
I think the issue here is one of perspective. As programmers, we see the code. We tend to put more focus on the features that took us the longest to implement. But often, these are not visible or relevant to the user. We like to show off the 80% of the effort that gets 20% of the outcome rather than the 20% that yields 80%. I think there's also a measurability bias at play. It's easy to make the case that a faster thing is better than a slower thing, but harder to make the case for an interesting feature. One is measurable but the other is not.
I've been using Emacs for ages. The performance is probably somewhat below average, but I just learned to ignore it. Having better editing features is worth more to me than responsive keyboard input. It would be nice to have both of course, but I don't think switching to a different editor would be worth it for me.
The problem is that while editors are super fast, the plugin/LSP integrations can really slow down the editing experience. While you can write the editor with GPU acceleration in Rust, the language servers will remain unchanged. Dealing with edge cases and concurrency is really difficult, even in Rust.
For example, if you activate auto complete, but there are multiple servers returning results with different response times. Do you wait for all of them to finish? If not, will you have results that jump around?
There were some new ideas a few (10+) years ago around how to visualize and navigate code, basically letting you edit through the program flow rather than by file. I was really keen on the idea but they only worked for Java, if I recall correctly. I'd love to see those ideas play out again with typescript, rust, etc.
Last time I tried zed it didn't have good git integration. I look at diffs and blame a lot and both vim and vscode have really great plugins.
Embedding media (the way a lot of markdown editors work) is one of the features I mentioned wanting on a new IDE wishlist. Preserving last seen arguments passed through a local debug session for future replays would also be handy.
The issue such things face is that they are very difficult to justify. If you say "I am going to improve the efficiency of the rendering process by 30%", no one will question what you're doing. The numbers are better than before, so it has clearly improved the software. But if you say "I'm going to implement images in comments", there are suddenly all sorts of questions. Will people use it? What if it degrades experience? What if it contributes to bloat? Etc. If you were to ask which of the features adds more value to the product, the answer is probably the second. But if you look at the feature on its own, it's much harder to justify doing work on the second than doing work on the first because there's no metric you are improving.
> How about a text editor which represents code as a syntax tree that is formatted as you type? Or one that has support for embedding multi-media content within source files? Or one with advanced program rewriting capabilities (in-lining functions, replacing struct members into getter methods, etc)
We have had these for decades, they are called IDEs
I've not seen many IDEs with the functionality I just listed. Most of the time it's just debugging support and code completion. The idea that most programmers have edited code in the way I just described for decades is patently absurd.
You mean one that formats code as you type, embeds multi-media within
source, rewrites class variables as getter methods? None of these could
be implemented in a way that even immature developers, those with 3-4
years of experience who go in for whizbangness, wouldn't immediately
deactivate.
Yes they totally could. I auto-format all my code and it works mostly without issue even in relatively complicated languages. Why would you turn of images in the source? A comment with a diagram would be useful. Rewriting class variables isn't something you can even turn off. It would just be an option in the right-click menu to refactor code. Everything I suggest is based to some extent on existing features. It is just a more complete implementation of them.
I’ve been trying to love Zed for months now and still run into constant snags. It’s frustrating to use with TypeScript. Support is very intermittent as basic features randomly break and come back during the same session. Want to jump to a declaration? Maybe it’ll work. Want information about this type? If you’re lucky. How about autocomplete for existing types, variables, and functions? This probably breaks most often.
I update the editor regularly, have tried heaps of suggested fixes and reset settings each time. It’s a mess.
It’s a beautiful, fast, powerful editor and I want to use it, but I’m pretty frustrated. I keep hoping an update will address the autocomplete at least, but as of last week it will still stop functioning while I’m working.
To be honest, I've had very similar results with TypeScript using neovim, helix and emacs. The tooling somehow never works correctly, or needs a lot of tinkering until the experience is decent.
As a comparison, I write Rust as my main language, and the tooling always _just works_. The experience with Zed is very good. Maybe the time for Zed in TypeScript development is not yet there, but if you write any Rust code, it's worth a try.
I've been curious on when AI was going to feel compelling for me to try. I might give this a try.
I've had a subscription to some LLM service for ages, but overall i just haven't found it useful at all for programming. Maybe with this Context workflow it'll be nice.
Though from the video it sounds like it might be difficult to get access to it?
You definitely should try a workflow with modern LLMs, but if you have trouble with Zed give cursor a try. No relation to the company, just was surprised at how good the product was for me for your bog-standard python and typescript work, but also surprisingly good in some side projects in embedded C++ and C.
A lot of it is polish over how good Claude sonnet 3.5 has gotten at code with enough context.
Zed's AI integration is good, Cursor's is great! I'm mostly using Zed and Aider right now, because I'm not doing a lot of coding currently and cancelled my Cursor subscription because I wasn't getting $20 of value out of it the last few months, but I plan to renew it when I'm doing more coding.
Zed has been on my shortlist as a natively fast text editor to replace Sublime, but I have very little interest in all the AI integration. I'm also not a fan of the prominent "sign in" button at the top right that's completely unhideable - it just serves to remind me that an off-line editor isn't necessarily the goal.
These are pretty minor criticisms, and for the most part I really like using it. Additionally, the fact that it's open source means that it's just a fork away from ripping out the sign in button manually.
Mmm, AI integration for coding is table stakes for any development tool right now IMHO. Even for things as simple as "I have an idea about how I'd check to see if the time is between midnight and 4:30am, but I don't have the python datetime module locked into memory, how would you do it" is extremely useful.
sad. software quality deteriorating sharply because of all this. To learn an API also helps to keep it small and focused instead of having thousands of methods on it. All software will now go the way of Java.
Wouldn't that would imply that Windows support is necessary for software to be good? Often it's easier to write good software when you target a specific platform (rather than spending time troubleshooting problems that occur across lots of different environments), and do it well.
I’ve never got its python LSP to work as well as Pylance in VSCode. Once you start using Pylance for large codebases, even if it is slow and sometimes crashes, you cannot go back to coding without it. Go to Definition, and automatic argument hints are too useful to code without
As far as I know Pylance (unrelated to pypi's pylance) is python LSP with microsoft's proprietary extensions that you can use only with official microsoft products.
btw, go to definition, argument hints can work without it just fine.
I very much applaud the effort in trying to push the boundaries, especially on the front of responsiveness and performance. We are typing on machines with mind-boggling resources and yet editors don't feel snappier(tm) at all, so I appreciate optimizing on that dimension.
However, I can't see myself moving away from Emacs. I've been using it for almost a quarter of a century and have seen many editors come and go in that timeframe: BBEdit, Textmate, Sublime Text, Atom and so on. The current hotness is VS Code, but I personally believe that will be abandoned at some point as well.
It would be great if some of the learnings of Zed can be backported to Emacs, however unlikely that is due to the amount of old cruft there.
I’ve been spending the weekend getting setup in NeoVim and have enjoyed the process so far. It’s definitely not for people who want a plug-and-play IDE, but if you want to see all the programming details that are involved in a text editor (and learn some Lua along the way), then I highly recommend it.
Fair warning, it is HIGHLY recommended you come in with a working knowledge of Vim first.
I'd recommend using one of the editor bundles like LazyVim or SpaceVim. I was using Lunarvim and very happy with it, but he's discontinued development on it so I'm planning on moving to LazyVim. After 30+ years of messing around with vi configuration, I'm glad to have someone else doing the bulk of the work.
Setting it up from scratch isn't, but if you just want something that works you can always go with one of the pre-made distributions, which is about as plug and play as you can get. I've had colleagues that were up and running after 10min with all the bells and whistles you expect from a modern IDE by just setting up LazyVim. Really the hardest part is the modal editing workflow, which is just inherent in how vim and nvim work - and I would recommend to set up regardless of which editor you use (e.g. by using the VSCode Neovim plugin)
Emacs can do that (there are a couple of add-ons that layer in inference). I believe Neovim can also.
On the commercial side IntelliJ and other JetBrains IDEs now have local-inference single-line completion model included. It won't build a project for you (incorrectly... that doesn't compile...), but will help you code faster.
I long for an editor like this to have very, very expansive support for all of the weird text editor choices. Ie the ability to effectively, not literally recreate Vim, Helix, etc in it. Sounds insane i know.. but i adore this editor and despite that, i just can't give up Helix for "vim bindings".
I don't know if i'm ever going to get out of the terminal at this rate :s
(EDIT: if his name sounds vaguely familiar, it might be because he is the author of https://interpreterbook.com/ and https://compilerbook.com/ )
reply