Zed: lightning-fast, collaborative code editor written in Rust (Atom team)
zed.dev
zed.dev
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
On HN, there's no harm in waiting.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
While I appreciate this approach and think it's a great idea over using something like Electron, this almost comes off as some kind of obvious discovery they've made. Nothing about this is new or even interesting, as this has basically been the status quo in games for ages now.
Edit: I realized this comes off as attacking the project itself. The project _is_ interesting because it seems like most "advancements" in text editing recently have been locked up in web technologies. I only mean their approach to rendering is not that interesting or exciting, which honestly might be a good thing
Just wanted to add that it’s an especially odd framing, given that this appears to be Atom’s successor, and VSCode—the editor which many Atom users adopted—is both Electron and heavily reliant on GPU rendering.
Basically, they're getting rid of the middleman: the web. Think about most modern web frameworks (React, Angular, etc.), they're basically immediate mode GUI frameworks, but we do "virtual diffing" in order to translate our immediate-mode-like code into DOM (a retained mode UI framework), then the web renderers the DOM via immediate-mode-like patterns again. Pretty strange if you think about it.
Our stacks of technology are getting in the way of creating good software. So yeah, it's on old idea, but in light of the state of the art in IDEs and Text Editors today, this is an interesting approach.
Note, this is a problem in the first place because of how good the web is. The web has so much tooling, cross-platform support, and documentation / learning resources that it's being overused in places where it's very inefficient, simply due to momentum and mindshare. When you have a hammer...
Now, one of the biggest reasons for the success of the web is cross-platform support, but it's not just cross-platform support. It's the only write once run anywhere platform, truly. Most other cross-platform frameworks require you to think about the native environment at some point, but it's very rare on the web because of the robust standard library including Media access, Networking and even more rarely used APIs like WebMIDI. Not to mention that web design culture allows you to ignore the ui patterns of the native OS you're targeting, allowing more cross-platform savings.
If we can somehow manage to throw away the DOM + CSS (except, perhaps, for decoration) and replace them with immediate mode frameworks, combine that with WebAPIs for interfacing with hardware, and decouple those from JS (maybe via WebAssembly), then we have a competitor to the web for complex cross-platform software that is actually interesting. Perhaps Zed and their Rust-based GUI framework could help push us in that direction.
Edit:
Another aside, the performance of immediate mode GUI. You could argue that retained mode UI can be made to have better performance than immediate mode, but I think the right combination of caching and framework-level optimizations to allow for partial updates are the solution.
You might say "that's not immediate mode though?", and sure, but what we care about here is fast applications that are easy to build. We've discovered that writing code via declarative patterns has huge benefits over "object-soup", so our goal should be to make those patterns as fast as possible. I think the DOM and retained-mode GUI is a just a result of the Java style of Object Oriented obsession.
That it's been the status quo in games is not really relevant.
What is probably more so is this is not the first project to go in that direction (e.g. alacritty is a GPU-accelerated terminal), and while the isolation from the platform and handling of everything tends to be a bonus point for a game which is rather isolated from the system it can be more problematic for other programs, especially heavily text-based ones (like... an editor).
Unless you count web apps running in Firefox! WebRender is built around exactly this concept.
Except that it's not?
We are currently in a weird path-dependent state for GUIs. Because GUI toolkits are such a pile of detailed work, it takes a lot of effort to create good general ones. The ones we currently have were all designed prior to ubiquitous 3D performance, have a strong dependency on object orientedness, and were often designed around constrained CPU and memory.
None of this holds today. However, we still use the same toolkits.
The immediate-mode GUI stuff is interesting, but throws away all OS integration which means accessibility is right out the window. Responsive GUIs (see: every DAW (digital audio workstation)) all throw away GUI toolkits and implement their own.
Not to mention that 2D rendering with 3D hardware is NOT a solved problem. The NV_path_rendering extension is not available in Vulkan or DirectX, as far as I know. Text shaping is decidedly video card unfriendly. The number of "vector" renderers can be counted on one hand--and you don't need any hands at all to count the 3D native ones.
I welcome all the experimentation in this space. I just really hope we get some convergence to something interesting soon.
A website dedicated to introducing a text editor that hasn't even been written yet.
.... with a "waitlist."
This is peak HN.
That said, the page is a content-light advertisement, and competing with Jetbrains on code-introspection and refactoring will be tough.
Yeah. Considering this comes from the team behind the world's most pre-eminent example of such software, I'm a bit skeptical.
What’s unclear to me is whether this is an internal project backed by those deep pockets, or a new and independent company? I hate to say it but that makes a big difference in the likelihood that this project will be around in five years, vs the (many, many) other new editors we’ve seen crop up in recent years
They look like they’ve got a great game-plan, but from the outside it seems like a tough business to get into. Best of luck to them either way!
It's the team who built an open-source editor at GitHub and they are building a new editor. Cool... I want to check it out.
Signup for a waitlist? Login? Seems like they're building a business around an editor... Cool, we have a number of those. I'll wait to see when they have a product I can evaluate instead of when they're talking about what they're going to do.
For those who have found collaborative editing to be a killer feature I would love to hear about your experiences.
OT... but I would go a little further than you and say that in my experience, I prefer to have the learner drive almost all the time, and to have the mentor step in and type only when necessary.
[1] https://xi-editor.io [2] https://xi-editor.io/docs/crdt-details.html
> The main thing CRDT buys you is the ability to propagate edits through a mesh-like network, exploiting local connections, as opposed to requiring a central server. I think that's appealing if you're actually editing in such an environment. For large scale organizations, I think it does make sense to treat the set of analysis and review tools as a form of collaborative editing, but those are also cases where a centralized server is completely viable.
> The flip side of the tradeoff is that you have to express your application logic in CRDT-compatible form. How do you represent the merge rules for soft spans as a monotonic semi-lattice?
> So I come to the conclusion that the CRDT is not pulling its (considerable) weight. When I think about a future evolution of xi-editor, I see a much brighter future with a simpler, largely synchronous model, that still of course has enough revision tracking to get good results with asynchronous peers like the language server. The basic editing commands, including indentation and paren matching, are more simply done as synchronous operations, and I think avoiding that complexity is key.
[1] https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...
Why does every commercial editor seem to desperately believe we all want this?
Why would I, as an actual developer, want "pair programming but now there's lag"?
I didn't even like the pairing fad in the first place, I found it awkward, anxiety-inducing, and slow. Adding an additional software dependency just seems worse.
It's one of those implementational-catnip ideas that steadily converges toward collective bikeshedding whenever it comes up, but which is really tricky to scale/sell/market in practice.
So, it hasn't caught on and been soundly disproven.
Or maybe it's that it hasn't caught on and then done the whole "oh look at all these other companies that were so head of their time" thing...
Otherwise, really look forward to see when you have something to show. A video of prototype would go a long way.
I wouldn't discount value of collaboration, if you get that well, this might take off.
This is the Atom team, which is why almost certainly it’s going to be something good
This leaves me wondering what the key advantage of this product will be over VSCode Live Share.
So I find an absolute focus on speed to be quite appealing.
I 100% agree with their philosophical positions: An editor should always be able to reflect input in the next screen refresh.
This might seem like a trivial thing to care about, but things that are more responsive just feel better to use. For something that I use all the time (too much, really), that's very significant.
(And w/r/t the network case, you still show your local input immediately; of course, input from other players is necessarily lagged, but you don't care about that.)
>of course, input from other players is necessarily lagged, but you don't care about that
But I do care about network lag. It's a much greater source of inconvenience (to me) than an imperceptible (to me) lag in registering my key presses.
With a clever implementation, you should see your local input reflected instantly, and other people's input will arrive with some delay. However, since you don't actually know when other people started the input, as long as you have a reasonably fast network, it should be "imperceptible" to you. (There's nothing to perceive!)
> Input lag has been imperceptible for me with all text editors that I've ever seriously used for coding
Here's a very specific example: try using emacs to edit the the c++ source file for the c# thrift generator. For extra agony, try using the iedit emacs extension to change a symbol throughout the file. It's extremely laggy.
Emacs in fundamental mode without any extensions is responsive.
> I appreciate that some people are genuinely more sensitive to input lag than others. However, I have to suspect that it's a minority concern.
Different strokes for different folks! I for one am happy to see an editor with that focus. (We'll see if it lives up to it!)
I also have a theory that even people that think they aren't sensitive to input lag actually might be -- I'd love to do some sort of study where people are divided into two groups to do some editing task for 8 hours, one group with an editor that deliberately has say a 100ms delay in input processing vs one group that doesn't, and afterwords survey each group about emotional state, fatigue, etc.
(By the way, I am fully aware that there need not be any delay in showing one's own input locally. That does not mean that network lag ceases to be an issue when editing collaboratively. It just means that you can speculatively display the probable result of your own edits before you've synced with the other person's edits.)
Apart from that, of course you are right that it is just a question of how many people find input lag to be a significant problem in their current text editor of choice. The issues with Emacs, as you note, have to do with the low performance of various language modes rather than the rendering architecture of the editor. (Though I guess maybe there is some missed opportunity for parallelism imposed by Emacs's architecture?)
If we imagine all possible network conditions, this is definitely true for some of them. But if you have a good network, I don't think you're going to be able to tell. Consider that you can even do something like Stadia which does round-trip input lag to render a full-frame of a video game, and it often works pretty darn well. Something like the one-way lag between when another person starts typing (an event you can't know the start of) and when it arrives on your display just isn't going to be noticeable if you're both on at all reasonable network connections, imo.
> The issues with Emacs, as you note, have to do with the low performance of various language modes rather than the rendering architecture of the editor. (Though I guess maybe there is some missed opportunity for parallelism imposed by Emacs's architecture?)
Yes and yes. (Also, it's a contributor to the bugginess of emacs -- dynamically typed and (often) dynamically scoped(!) lisp code is not conducive correctness. It does, however, lend itself amazingly well to extensibility/flexibility.)
So but anyway, plain emacs w/ no language modes is indeed fast and fairly bug free, but...what's the point?
The goal is to be able to have a full-featured editor that remains fast and bug-free. :-)
The buffer data structure that Emacs uses -- a gap buffer -- has a fundamental incompatibility with making multiple "simultaneous" edits. Any attempt to do it in Elisp is going to be hacking (in a good way) around that. Performance will definitely degrade for a large buffer, because it has copy around most of the buffer contents for each edit. Full explanation here if you're curious: https://nullprogram.com/blog/2017/09/07/
Tangential, but I definitely disagree w/ the blog post about the value of multiple cursors vs just macros and rectangle edits, tho. Multiple cursors are just so much easier to work with and get right. You're editing blind when recording a macro, which is tricky, and if you mess up, you have to start over again from zero.
Tools that facilitate this communication are welcome.
This one is even worse because theres no actual examples or code
Hope the devs have fun writing this though! Rust is very enjoyable to work in
Ha, that's nice. Surprising nobody has thought of that before!
Presumably this is not going to be free.
Of course it's possible they have some idea of how to monetise it that Jetbrains and Sublime didn't think of.
If a product is significantly better and not significantly more expensive I'm in.
In fact I actively want someone to pay someone to take the newest Firefox and start publishing builds that fix the things Mozilla broke.
Note: this is a joke, I wish all the best to Zed and its team !
I'd pay heaps to have a full Kakoune experience (my personal favorite) with a good UI.
https://stackoverflow.com/questions/6733934/what-does-immedi...
If you want be hip and Rustic and GPU accelerated, launch ssh from Alacritty or WezTerm.
Bonus: tmux/screen/Zellithing have tabs/windows/panes, so it’s easy to bounce between editors/shells/etc.
Downside: someone has to su as someone, and identity theft is a serious crime Michael.
but, 1 there's nothing to show, and 2 its being built in the dark.
There is AccessKit [1] that tries to create a cross-platform API to make this less tedious, but I'm not sure how far along that effort is.
VSCode is much larger, and much more complex. I just can’t imagine it happening ever.
Looks positively ancient and dead.
Naming is hard.