20 ms·

Zed: lightning-fast, collaborative code editor written in Rust (Atom team)

151 points by mattrighetti 5y ago

decebalus1 5y ago
This has all the characteristics of announcing vaporware. But "in Rust"!
foldr 5y ago
This seems really interesting from a technical point of view. However, they seem to be assuming that developers will place a very high value on low input lag. This seems especially doubtful in the context of a collaborative editing tool, where network delays are likely to dwarf any input lag deriving from the event handling and rendering architecture of the editor. This leaves me wondering what the key advantage of this product will be over VSCode Live Share.
- samuell 5y ago
  I guess not everything would need to lag. As long as you and your peers are working on not the exact same row, a slight network delay might not matter too much, especially if your own typing etc doesn't lag?
  - dilap 5y ago
    Yes, exactly. You should be able to show your own input immediately. For others input, you can't tell the difference between human lag and network lag, provided the network lag is reasonably low (which it will be unless you have a very bad or super-high-latency network).
- dilap 5y ago
  As looooong time user(/addict) of emacs, probably my two biggest complaints are slowness and bugginess. 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.)
  - foldr 5y ago
    Input lag has been imperceptible for me with all text editors that I've ever seriously used for coding (Vim, Emacs and VSCode). 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. It doesn't seem like the first thing to mention on a marketing page. >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.
    - dilap 5y ago
      > 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.
      - foldr 5y ago
        Network lag in a collaborative editing environment definitely is perceptible in practice. Though in theory you can't be 100% sure that the other person isn't just pausing randomly in the middle of typing a word, the statistical signature of lagged typing is quite distinctly perceptible. (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?)
desireco42 5y ago
Seriously : waitlist :) 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.
- mattrighetti 5y ago
  This is pretty new and not mine, would love to be that smart to write something this complicated in Rust. This is the Atom team, which is why almost certainly it’s going to be something good
conaclos 5y ago
Remind me of Xi editor [1] that internally uses a CRDT [2] to enable concurrent editing. I'm wondering which CRDT Zed uses. [1] https://xi-editor.io https://xi-editor.io [2] https://xi-editor.io/docs/crdt-details.html https://xi-editor.io/docs/crdt-details.html
- mattrighetti 5y ago
  Also, Xi is not very satisfied with CRDT [1] > 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#issuecomment-491473599 https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...
thom 5y ago
I did initially wonder what could justify such ugly font rendering and a complete lack of screenshots, but this is a serious team with serious ideas so it'll be intriguing to see what they come up with.
IshKebab 5y ago
> We call it GPUI. Ha, that's nice. Surprising nobody has thought of that before! Presumably this is not going to be free.
- kubb 5y ago
  Electron is free, so why not?
  - IshKebab 5y ago
    Electron was developed as a side-project by Github. Zed seems to be a dedicated company just making an editor. Of course it's possible they have some idea of how to monetise it that Jetbrains and Sublime didn't think of.
    - eitland 5y ago
      I'm ready to pay for my tools or get $dayjob to pay for them (I already pay for some things and have them pay for Jetbrains Toolbox bundle) and there are many of us. 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.
tormeh 5y ago
Why not use egui (https://github.com/emilk/egui https://github.com/emilk/egui) instead of making your own?
- wongarsu 5y ago
  If they did they wouldn't be on the HN homepage. "We are planning to write a text editor based on an existing GUI toolkit, stay tuned" doesn't sound all that exciting, even if the result would be identical.
kubb 5y ago
I agree that everything written there makes sense but I can't get hyped for trailers anymore. No release date, no screenshots, let me know when it's ready :)
- underdeserver 5y ago
  Yup. They're introducing an idea and a sketch of a high level design. Show me something I can see.
- dang 5y ago
  Yes, this more or less fits into the 'announcement of an announcement' category which is off topic here. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=%22announcement%20of%20an%20announcement%22 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&sort=byDate&type=comment&query=%22no%20harm%20in%20waiting%22%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
mhitza 5y ago
I'm going to be curious to see how they are going to make their UI library accessible.
- wongarsu 5y ago
  Probably the same as every other (good) UI library, by implementing each platform's accessibility API. 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. 1: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit
_pmf_ 5y ago
> Mission-critical tools should be hyper-responsive. Pathetic drivel. Yes, the field sets the bar extremely low with VSCode, but come on!
- rectang 5y ago
  https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
simonw 5y ago
Reading this description - a fast native code editor with collaborative editing as a key feature - reminded me of Hydra/SubEthaEdit, which first came out in 2003! Talk about being ahead of your time.
- exikyut 5y ago
  Aww, it's macOS-only. https://subethaedit.net/ https://subethaedit.net/ https://github.com/subethaedit/SubEthaEdit https://github.com/subethaedit/SubEthaEdit
the__alchemist 5y ago
I love the mentality. Minimizing latency is important for user experience, and is evidently not a project requirement for most modern software. That said, the page is a content-light advertisement, and competing with Jetbrains on code-introspection and refactoring will be tough.
- senko 5y ago
  > Minimizing latency is important for user experience, and is evidently not a project requirement for most modern software. Yeah. Considering this comes from the team behind the world's most pre-eminent example of such software, I'm a bit skeptical.
  - danielvaughn 5y ago
    One thing that has me interested is that they seem to be working with the person/people behind tree-sitter. Tree-sitter is pretty amazing tech and vastly outperforms traditional text parsing. There are a couple of impressive YT videos demonstrating it.
    - b3morales 5y ago
      The Tree-sitter team are mostly, or possibly all, also GitHub/Microsoft employees.
soggybutter 5y ago
> The key insight was that modern graphics hardware can render complex 3D graphics at high frame rates, so why not use it to render relatively simple 2D user interfaces with an immediate mode architecture? 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
- deleted 5y ago
  [deleted]
- eyelidlessness 5y ago
  I agree it seems like a strangely ho hum realization. And I’m definitely not attacking the project, I just signed up for the waitlist. 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.
  - eggy 5y ago
    Yes, I use Raylib for toy games, and for toy apps. Raygui, the Raylib gui library, is an immediate-mode-gui. It doesn't seem to hog any resources for the frame updates, but I lower it for apps where I don't need very high refresh rates on state changes such as moving stuff around or changing an input in a dialog or text box. I've been playing with immediate-mode-guis for years (nuklear, imgui, etc.), so I wasn't sure what was novel about this. There are tricks to store scenegraphs and only update what changes, which pushes you away from true immediate mode anyway. I am more curious about how you render fonts at scale. Do they implement sub-pixel rendering or SDFs to achieve variable resolution clarity?
  - mistersys 5y ago
lbhdc 5y ago
I haven't been sold on the reality of using collaborative editors. I have tried the jetbrains offerings, and for me it didn't make pairing easier (the primary use case I think of). However I am interested in being sold on the idea. For those who have found collaborative editing to be a killer feature I would love to hear about your experiences.
- xedrac 5y ago
  I find it very useful when mentoring, especially when working remotely. I think one of the best ways to train someone to program in Rust (or any language really) is to sit side-by-side and write code while answering questions and explaining why one approach was chosen over another. Having the less experienced developer sometimes take the wheel and drive is also important.
  - rectang 5y ago
    I vigorously agree that remote mentoring and training is a prime scenario for a collaborative editor, and I've used VSCode for it (in both roles). 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.
bionhoward 5y ago
Love me some Atom, but I had to switch to VSCode for various reasons. I will definitely test Zed! Cool to see them combine lots of interesting innovations to make a new thing
jarcane 5y ago
> Real-time collaboration produces better software. 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.
- deleted 5y ago
  [deleted]
- exikyut 5y ago
  > Why does every commercial editor seem to desperately believe we all want this? 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...
hiptobecubic 5y ago
A text editor. A website dedicated to introducing a text editor that hasn't even been written yet. .... with a "waitlist." This is peak HN.
- whalesalad 5y ago
  We are all just children playing house. Let them have their fun.
Aissen 5y ago
I can't wait for a Microsoft team to take the best ideas of Zed (Atom), its GPUI framework (Electron), and beat them on their own field, by adding a twist (LSP) and having better performance(VSCode). Note: this is a joke, I wish all the best to Zed and its team !
- eggy 5y ago
  Andrew Kelley should re-write it and call it ZiggEd!
dijit 5y ago
Is it this? https://github.com/zedapp/zed https://github.com/zedapp/zed Looks positively ancient and dead.
- dcchambers 5y ago
  Looks entirely unrelated other than sharing a name.
  - dijit 5y ago
    And also being a code editor, and sharing a collaborator with Atom
- rectang 5y ago
  It looks like it's not — that's not in Rust, and it's from zedapp.org as opposed to zed.dev. Naming is hard.
slowmovintarget 5y ago
The meta on this is interesting to me. Coding is speaking. Writing code is communicating with the next developer about what you are trying to get the machine to do. In the case of collaborative editing, it is immediately speaking to one or more developers about what you are trying to get the machine to do. Tools that facilitate this communication are welcome.
mumphster 5y ago
Cool, yet another created in a vacuum CRDT, GUI, and text editor implementation written in rust. 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
RunOutOfMemory 5y ago
A lot more hackers on this field… something is happening?
- RunOutOfMemory 5y ago
  Collaborative Vim
- ac130kz 5y ago
  VSCode, LSP, Tree-sitter happened
ac130kz 5y ago
Why do they want to use relatively expensive immediate mode rendering instead of simple retained? It's not like a code editor requires a lot of interaction.
lijogdfljk 5y ago
Man, i really hope one of these fancy UI editors fully embraces different editing... modalities (pun?).. aka Vim-like, Kakoune-like, Emacs-like. I'd pay heaps to have a full Kakoune experience (my personal favorite) with a good UI.
dexterlagan 5y ago
We already have Sublime. Enough editors already.
- selfer564 5y ago
  We already have Intel 4004. Enough CPUs already.
  - dralley 5y ago
    SublimeText is hardly comparable to an Intel 4004
onelovetwo 5y ago
Gives me hope since its some of the people that made Atom and Electron and the motivation seems good but, 1 there's nothing to show, and 2 its being built in the dark.
albingroen 5y ago
Or just rewrite vscode in Rust?
- eyelidlessness 5y ago
  For better or worse, Microsoft is all in on the JS ecosystem. I could sooner see TypeScript being rewritten in Rust: at least from a performance perspective, there’s a lot more room to improve there. But I think it’s safe to say that’s not gonna happen. VSCode is much larger, and much more complex. I just can’t imagine it happening ever.
  - albingroen 5y ago
    No I can't see it happening either. But why spend a lot of time reinventing a wheel when everything about VSCode is actually pretty good, except its performance. But I'm a Vim user anyways so what do I care...
brundolf 5y ago
3/4 team members are Atom veterans (which is to say GitHub, which is to say Microsoft) 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!
avsteele 5y ago
What's the meaning of "immediate mode" in their description? The only context (no pun intended) in which I know this phrase is the old, deprecated way of writing OpenGL vertices. https://stackoverflow.com/questions/6733934/what-does-immediate-mode-mean-in-opengl https://stackoverflow.com/questions/6733934/what-does-immedi...
- ykl 5y ago
  Likely they mean an immediate mode UI [1], as opposed to a traditional retained mode UI. Immediate mode UIs have gained a lot of popularity in the games/graphics world over the past few years. [1] https://en.wikipedia.org/wiki/Immediate_mode_GUI https://en.wikipedia.org/wiki/Immediate_mode_GUI
crad 5y ago
So my take-away from browsing the site: 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.
febstar 5y ago
Zed seems to be the successor of Github/Atom's abandoned Xray project [0]. "Responsive", Rust, CRDTs. [0] https://github.com/atom-archive/xray https://github.com/atom-archive/xray
FpUser 5y ago
Sure I am totally going to sign for waiting list for yet another standalone programming editor. Not.
benreesman 5y ago
If you don’t want to wait for this to “drop”, do what my colleagues and I do and attach to the same tmux (screen, …) session. 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.
akagusu 5y ago
No code, no hope.
rirze 5y ago
Looking for an Emacs killer, but from what I can see, this probably isn't it.
capiet 5y ago
Really impressive!

151 points by mattrighetti 5y ago

This has all the characteristics of announcing vaporware. But "in Rust"!

This seems really interesting from a technical point of view. However, they seem to be assuming that developers will place a very high value on low input lag. This seems especially doubtful in the context of a collaborative editing tool, where network delays are likely to dwarf any input lag deriving from the event handling and rendering architecture of the editor. This leaves me wondering what the key advantage of this product will be over VSCode Live Share.

samuell 5y ago
I guess not everything would need to lag. As long as you and your peers are working on not the exact same row, a slight network delay might not matter too much, especially if your own typing etc doesn't lag?
- dilap 5y ago
  Yes, exactly. You should be able to show your own input immediately. For others input, you can't tell the difference between human lag and network lag, provided the network lag is reasonably low (which it will be unless you have a very bad or super-high-latency network).
dilap 5y ago
As looooong time user(/addict) of emacs, probably my two biggest complaints are slowness and bugginess. 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.)
- foldr 5y ago
  Input lag has been imperceptible for me with all text editors that I've ever seriously used for coding (Vim, Emacs and VSCode). 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. It doesn't seem like the first thing to mention on a marketing page. >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.
  - dilap 5y ago
    > 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.
    - foldr 5y ago
      Network lag in a collaborative editing environment definitely is perceptible in practice. Though in theory you can't be 100% sure that the other person isn't just pausing randomly in the middle of typing a word, the statistical signature of lagged typing is quite distinctly perceptible. (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?)

desireco42 5y ago

Seriously : waitlist :) 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.

mattrighetti 5y ago
This is pretty new and not mine, would love to be that smart to write something this complicated in Rust. This is the Atom team, which is why almost certainly it’s going to be something good

conaclos 5y ago

Remind me of Xi editor [1] that internally uses a CRDT [2] to enable concurrent editing. I'm wondering which CRDT Zed uses. [1] https://xi-editor.io https://xi-editor.io [2] https://xi-editor.io/docs/crdt-details.html https://xi-editor.io/docs/crdt-details.html

mattrighetti 5y ago
Also, Xi is not very satisfied with CRDT [1] > 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#issuecomment-491473599 https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...

thom 5y ago

I did initially wonder what could justify such ugly font rendering and a complete lack of screenshots, but this is a serious team with serious ideas so it'll be intriguing to see what they come up with.

IshKebab 5y ago

> We call it GPUI. Ha, that's nice. Surprising nobody has thought of that before! Presumably this is not going to be free.

kubb 5y ago
Electron is free, so why not?
- IshKebab 5y ago
  Electron was developed as a side-project by Github. Zed seems to be a dedicated company just making an editor. Of course it's possible they have some idea of how to monetise it that Jetbrains and Sublime didn't think of.
  - eitland 5y ago
    I'm ready to pay for my tools or get $dayjob to pay for them (I already pay for some things and have them pay for Jetbrains Toolbox bundle) and there are many of us. 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.

tormeh 5y ago

Why not use egui (https://github.com/emilk/egui https://github.com/emilk/egui) instead of making your own?

wongarsu 5y ago
If they did they wouldn't be on the HN homepage. "We are planning to write a text editor based on an existing GUI toolkit, stay tuned" doesn't sound all that exciting, even if the result would be identical.

kubb 5y ago

I agree that everything written there makes sense but I can't get hyped for trailers anymore. No release date, no screenshots, let me know when it's ready :)

underdeserver 5y ago
Yup. They're introducing an idea and a sketch of a high level design. Show me something I can see.
dang 5y ago
Yes, this more or less fits into the 'announcement of an announcement' category which is off topic here. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=%22announcement%20of%20an%20announcement%22 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&sort=byDate&type=comment&query=%22no%20harm%20in%20waiting%22%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

mhitza 5y ago

I'm going to be curious to see how they are going to make their UI library accessible.

wongarsu 5y ago
Probably the same as every other (good) UI library, by implementing each platform's accessibility API. 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. 1: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit

_pmf_ 5y ago

> Mission-critical tools should be hyper-responsive. Pathetic drivel. Yes, the field sets the bar extremely low with VSCode, but come on!

rectang 5y ago
https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html > Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community. > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

simonw 5y ago

Reading this description - a fast native code editor with collaborative editing as a key feature - reminded me of Hydra/SubEthaEdit, which first came out in 2003! Talk about being ahead of your time.

exikyut 5y ago
Aww, it's macOS-only. https://subethaedit.net/ https://subethaedit.net/ https://github.com/subethaedit/SubEthaEdit https://github.com/subethaedit/SubEthaEdit

the__alchemist 5y ago

I love the mentality. Minimizing latency is important for user experience, and is evidently not a project requirement for most modern software. That said, the page is a content-light advertisement, and competing with Jetbrains on code-introspection and refactoring will be tough.

senko 5y ago
> Minimizing latency is important for user experience, and is evidently not a project requirement for most modern software. Yeah. Considering this comes from the team behind the world's most pre-eminent example of such software, I'm a bit skeptical.
- danielvaughn 5y ago
  One thing that has me interested is that they seem to be working with the person/people behind tree-sitter. Tree-sitter is pretty amazing tech and vastly outperforms traditional text parsing. There are a couple of impressive YT videos demonstrating it.
  - b3morales 5y ago
    The Tree-sitter team are mostly, or possibly all, also GitHub/Microsoft employees.

soggybutter 5y ago

> The key insight was that modern graphics hardware can render complex 3D graphics at high frame rates, so why not use it to render relatively simple 2D user interfaces with an immediate mode architecture? 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

deleted 5y ago
[deleted]
eyelidlessness 5y ago
I agree it seems like a strangely ho hum realization. And I’m definitely not attacking the project, I just signed up for the waitlist. 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.
- eggy 5y ago
  Yes, I use Raylib for toy games, and for toy apps. Raygui, the Raylib gui library, is an immediate-mode-gui. It doesn't seem to hog any resources for the frame updates, but I lower it for apps where I don't need very high refresh rates on state changes such as moving stuff around or changing an input in a dialog or text box. I've been playing with immediate-mode-guis for years (nuklear, imgui, etc.), so I wasn't sure what was novel about this. There are tricks to store scenegraphs and only update what changes, which pushes you away from true immediate mode anyway. I am more curious about how you render fonts at scale. Do they implement sub-pixel rendering or SDFs to achieve variable resolution clarity?
- mistersys 5y ago

lbhdc 5y ago

I haven't been sold on the reality of using collaborative editors. I have tried the jetbrains offerings, and for me it didn't make pairing easier (the primary use case I think of). However I am interested in being sold on the idea. For those who have found collaborative editing to be a killer feature I would love to hear about your experiences.

xedrac 5y ago
I find it very useful when mentoring, especially when working remotely. I think one of the best ways to train someone to program in Rust (or any language really) is to sit side-by-side and write code while answering questions and explaining why one approach was chosen over another. Having the less experienced developer sometimes take the wheel and drive is also important.
- rectang 5y ago
  I vigorously agree that remote mentoring and training is a prime scenario for a collaborative editor, and I've used VSCode for it (in both roles). 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.

bionhoward 5y ago

Love me some Atom, but I had to switch to VSCode for various reasons. I will definitely test Zed! Cool to see them combine lots of interesting innovations to make a new thing

jarcane 5y ago

> Real-time collaboration produces better software. 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.

deleted 5y ago
[deleted]
exikyut 5y ago
> Why does every commercial editor seem to desperately believe we all want this? 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...

hiptobecubic 5y ago

A text editor. A website dedicated to introducing a text editor that hasn't even been written yet. .... with a "waitlist." This is peak HN.

whalesalad 5y ago
We are all just children playing house. Let them have their fun.

Aissen 5y ago

I can't wait for a Microsoft team to take the best ideas of Zed (Atom), its GPUI framework (Electron), and beat them on their own field, by adding a twist (LSP) and having better performance(VSCode). Note: this is a joke, I wish all the best to Zed and its team !

eggy 5y ago
Andrew Kelley should re-write it and call it ZiggEd!

dijit 5y ago

Is it this? https://github.com/zedapp/zed https://github.com/zedapp/zed Looks positively ancient and dead.

dcchambers 5y ago
Looks entirely unrelated other than sharing a name.
- dijit 5y ago
  And also being a code editor, and sharing a collaborator with Atom
rectang 5y ago
It looks like it's not — that's not in Rust, and it's from zedapp.org as opposed to zed.dev. Naming is hard.

slowmovintarget 5y ago

The meta on this is interesting to me. Coding is speaking. Writing code is communicating with the next developer about what you are trying to get the machine to do. In the case of collaborative editing, it is immediately speaking to one or more developers about what you are trying to get the machine to do. Tools that facilitate this communication are welcome.

mumphster 5y ago

Cool, yet another created in a vacuum CRDT, GUI, and text editor implementation written in rust. 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

RunOutOfMemory 5y ago

A lot more hackers on this field… something is happening?

RunOutOfMemory 5y ago
Collaborative Vim
ac130kz 5y ago
VSCode, LSP, Tree-sitter happened

ac130kz 5y ago

Why do they want to use relatively expensive immediate mode rendering instead of simple retained? It's not like a code editor requires a lot of interaction.

lijogdfljk 5y ago

Man, i really hope one of these fancy UI editors fully embraces different editing... modalities (pun?).. aka Vim-like, Kakoune-like, Emacs-like. I'd pay heaps to have a full Kakoune experience (my personal favorite) with a good UI.

dexterlagan 5y ago

We already have Sublime. Enough editors already.

selfer564 5y ago
We already have Intel 4004. Enough CPUs already.
- dralley 5y ago
  SublimeText is hardly comparable to an Intel 4004

onelovetwo 5y ago

Gives me hope since its some of the people that made Atom and Electron and the motivation seems good but, 1 there's nothing to show, and 2 its being built in the dark.

albingroen 5y ago

Or just rewrite vscode in Rust?

eyelidlessness 5y ago
For better or worse, Microsoft is all in on the JS ecosystem. I could sooner see TypeScript being rewritten in Rust: at least from a performance perspective, there’s a lot more room to improve there. But I think it’s safe to say that’s not gonna happen. VSCode is much larger, and much more complex. I just can’t imagine it happening ever.
- albingroen 5y ago
  No I can't see it happening either. But why spend a lot of time reinventing a wheel when everything about VSCode is actually pretty good, except its performance. But I'm a Vim user anyways so what do I care...

brundolf 5y ago

3/4 team members are Atom veterans (which is to say GitHub, which is to say Microsoft) 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!

avsteele 5y ago

What's the meaning of "immediate mode" in their description? The only context (no pun intended) in which I know this phrase is the old, deprecated way of writing OpenGL vertices. https://stackoverflow.com/questions/6733934/what-does-immediate-mode-mean-in-opengl https://stackoverflow.com/questions/6733934/what-does-immedi...

ykl 5y ago
Likely they mean an immediate mode UI [1], as opposed to a traditional retained mode UI. Immediate mode UIs have gained a lot of popularity in the games/graphics world over the past few years. [1] https://en.wikipedia.org/wiki/Immediate_mode_GUI https://en.wikipedia.org/wiki/Immediate_mode_GUI

crad 5y ago

So my take-away from browsing the site: 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.

febstar 5y ago

Zed seems to be the successor of Github/Atom's abandoned Xray project [0]. "Responsive", Rust, CRDTs. [0] https://github.com/atom-archive/xray https://github.com/atom-archive/xray

FpUser 5y ago

Sure I am totally going to sign for waiting list for yet another standalone programming editor. Not.

benreesman 5y ago

If you don’t want to wait for this to “drop”, do what my colleagues and I do and attach to the same tmux (screen, …) session. 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.

akagusu 5y ago

No code, no hope.

rirze 5y ago

Looking for an Emacs killer, but from what I can see, this probably isn't it.

capiet 5y ago

Really impressive!