Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev.
We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting.
Please don't forget about accessibility. Getting this right from day 1 will make your life a lot easier in the long run. If I remember correctly, I was never able to use Atom with a screen reader. Hearing custom UI already makes me nervous and I'm pretty sure I won't be able to use Zed with a screen reader either.
Blind developers exist. Please don't forget about us. It's one of the few areas where we can actually make a meaningful difference together with our peers on an equal playing field.
Especially for a _collaborative_ editor, a11y seems like a must. Everyone can pick their own personal editor, but you don't want to shut out your (potential) peers from (potential) collaboration. Without accessibility, such an editor likely wouldn't stand a chance at Mozilla where I work; I certainly would lobby against it.
My favorite is VS Code by far. I use it daily. They recently also added a bunch of sound cues to help figure out if code is folded or a line contains an error. It's pretty great.
Auto completion reads well, the parameter hints read, even the built-in terminal works. So overall I'm really happy with it.
It probably played a pretty big role. Everything Atom could do, VsCode could do better. At some point it didn't make sense to put man-hours into two different editors with the exact same technology stack.
Not likely, GitHub is a separate business and makes their own decisions.
MS also competes with GitHub also; Azure Repos are a thing, as is Azure DevOps and those are just two examples. MS has plenty of products that compete with each other.
In some spaces this is a good strategy as you will capture more market share with two products than you will with one and you can avoid to an extent monopoly claims.
GitHub Codespaces is what killed Atom and while MS was probably involved in the decision to develop Codespaces, the decision to sunset Atom likely wasn't explicitly made at that time; its simply a side affect as other things have eclipsed Atom.
I don't have much experience with XCode, however the few things I did do seemed accessible. As accessible as XCode can be - I personally find a lot of the interface a bit confusing. Super long lists, nested options, but I assume those aren't things that are specifically confusing to people using assistive tech and I'm sure I'd be able to find my way around it well if I used it more. Mac seems to be a lot more consistent with their accessibility story than others, and we constantly get new features from them. With the new MacOS for example we got a VoiceOver feature that tells us when we have formatting problems in text, and we can finally get indentation announced (something which we had to do using custom scripting before).
Not to mention all the cool things that involve some form of (live) image recognition, like telling us where people are, where doors are, etc etc.
It was. I was in a particularly moody state and my filter was gone. It was meant in a way to be sympathetic to the challenges of that situation but is phrased badly. I'd delete it but I can't.
I've only ever heard good things about Visual Studio in this area, not sure if other IDEs are comparable. I do know Eclipse has a specialized build for this purpose as well. I wonder if XCode is also decent in this regard. I think Notepad++ might be only other one from memory that I know of.
You can turn on the various accessibility features and try them yourselves. While I was already aware of the 'voiceover' features, I was blown away by the braille keyboard and how quickly she could type with it.
Blind people use TTS set at ridiculous speeds that make my 1.5x podcast playback seem glacial. Even back in the late 80s I remember a blind classmate who had a portable electronic typewriter thing that read her entries back to her at rapid speed.
I commonly watch dev talks and walkthroughs on youtube at greater than 2x speed because the talkers make an effort to talk slowly for non native English speakers.
Just pop open the console with F12, enter the following and hit enter:
$('video').playbackRate = 2.5
Change `2.5` to whatever number you wish.
Press up in the console to bring back your last command faster with the cursor at the end so you just delete the number, type a new number and hit enter.
In the context of blind users: I wonder if it's common to have the display turned off, while still receiving touch input, I wonder how much it would improve the battery life.
It is normal to advocate for your needs but asking for it to be included from day 1 is weird. The same way you don't start a saas app with localization from day one.
I'm not blind so for sure I won't really care about accessibility but honest question why not use an ide developed for blind people instead of using the same as non blind people?
Please learn more about the needs of blind people before writing something like this.
Adding accessibility for screen readers is much more difficult to add later in the project lifecycle. Thinking about those design considerations early makes a big difference in how accessible it will later. If developers don't think about these things early, most likely the product will never be fully accessible, ever. Blind people have seen this played out before with other software products and know where this path leads.
(I'm not blind but have worked with blind developers. I'm not an expert in accessibility but I know enough to know how important it is to listen to accessibility needs)
This comment is honestly shocking to me. It’s not “weird” for people with different needs to ask to be included in the software we build. Accessibility is a baseline for any product in 2022 and needs to be included from the start otherwise it inevitably won’t work when it’s strapped on later.
Actually it's pretty good development practice to start an SaaS app with localization from day one. Why wouldn't you? The world doesn't revolve around English speakers (there are more non-English speakers than there are English speakers, at least what their first language is concerned), the same as it doesn't revolve around people with 100% vision.
You start an editor with extensibility from day one, as well as theming from day one, as well as multi-platform from day one, etc.
Why should it be different for Localization or Accessibility?
Please consider that implementing accessibility during the design phase is infinitely easier than post implementation. Additionally, accessibility benefits everyone and we should always be advocating for it regardless.
Imagine if you can code screenless. Headaches in response to light? Not a problem. Avoiding screens at night to wind down for sleep? Solved. Eyesight deteriorating (a totally normal thing that comes with age)? No new tech or ecosystem to need to adapt to, everything is already there.
> The same way you don't start a saas app with localization from day one.
Believe it or not, my native language isn't English, so this doesn't make sense to me.
> I'm not blind so for sure I won't really care about accessibility
You should. You're not blind yet. You're not deaf yet. You don't have motor control problems yet. It does not take much to get there. One small accident and your life is changed forever. It's terrifying.
> why not use an ide developed for blind people instead of using the same as non blind people?
Because not only do those not exist, but that seems just a bit silly to me. Most operating systems provide pretty good means to make apps accessible. They usually have API's that, if implemented, will make your app work with whatever assistive tech you may use on that platform. Most apps work on Mac, most apps work on Windows. Linux is sadly another story, but even there we can at least edit text.
What about tutorials? Courses? If we can't use the same software, should we also not be able to do any of them? Should we be locked out of great innovation because we need special software that nobody wants to update? Or worse, locked to one specific platform?
I believe I've said this before, but as sad as it is, every time I hear "Custom UI" I immediately think "Oh great, this won't work". In fact, I'm much more likely to give something a go if it's developed using web technologies. While not perfect, at least I know that there's a chance that it might work. It shouldn't be like that.
I have learnt from VERY painful experience that you cannot "bolt on" accessibility later (not without very painful refactoring and massive tech debt). It needs to be a core feature considered in the base design and a task added for every feature added on top.
OK you want motive. If you do accessibility with priority, you will get a whole new set of users who are always overlooked. A less competitive way to get easy money or user base depending on your product's model. ;)
I recently had a scare with my eyes. Freaked me out. I started looking at my developer tools completely differently. You are not out of the woods buddy. Anything can happen tomorrow. :)
I'm guessing that by "included day 1" they meant that if you do it this way it's much easier then having the product designed and then re-engeneering it to support accessibility later.
IMO the killer thing that VSCode has over all the other editors is the wealth of extensions and a certain degree of simplicity. What are your plans for Zed in terms of extensibility and are you aligning more towards making something beefy and full-featured like the IntelliJ offerings or something more "lightweight" like VSCode or Sublime?
We plan to make Zed extensible via WebAssembly, but we're taking a different approach than we did with Atom.
Our goal is to make Zed fast, stable, and collaborative first, extensible second. We'll be taking a more conservative approach with our APIs to ensure we can preserve our core values even as users add extensions.
Our goal is for Zed to have the lightweight and snappy vibe of Sublime with the power of a more full-featured IDE. These objectives are obviously in tension, but I think we can build something that balances them well. A collaborative IDE that feels fast and powerful.
Ooh, this is interesting. It sounds like you learned a lesson here. Could you say more about what prompted the change? I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices. Was it something like that for you as well?
Very much so. As the first Electron app we were so excited about people being able to do anything they imagined. It was cool but ended up really constraining us. This time we really want to drive our API based on the most important things people actually need to extend. We need to navigate the trade-offs more intelligently.
This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.
Design-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties... etc) embedded into a flexible language. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things.
Everything on top of the core is written in an open style, with Lispy features that make it easy to hook into or modify anything. Adding a small feature to Emacs doesn't feel like calling APIs from an existing application, it feels either like writing my own code with text editor stuff available as a library or, alternatively, like tapping into and fiddling directly with existing code in the system.
This way of seeing Emacs explains both why it's so flexible and why certain things (better performance on long lines, concurrency) are so difficult: you can express a lot using the core concepts and you can easily change other code that's expressed with these concepts, but making fundamental changes to the core itself is far more difficult. Partly it's more difficult because it's an old C codebase pretty separate from the Lisp world but, more importantly, it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict. It's the very flexibility on top of the core that makes the core itself hard to change, since the higher-level Lisp code is using the core concepts in all kinds of ways.
> it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict.
This is a sign that emacs has too much extensibility (or, to be more accurate: too little isolation). It's been observed before that emacs really is the antithesis of the alleged Unix philosophy of "doing one thing and doing it well". It is an inner platform.
Causally linking glaring deficiencies (long lines, concurrency) to overriding virtues (extensibility) is a weak but common snow job aimed at emacs's critics who know nothing of emacs's internals. For this emacs critic who knows quite a bit about emacs's internals, I call you out.
There's only one reason for emacs's many wtf frailties. No one's paying to fix them.
Emacs either doesn't have APIs or everything is an API, depending on how you look at it - since it's source is available at runtime plugins and modules can be first-class citizens performance-wise.
With Vim at least, and I think Emacs as well (although I don't use it), it seems like they have greater focus on providing the embedded scripting language, than deciding what to expose to the user via an API. In Vim's case at least, this seems to have resulted in multiple third party API-like projects (for things like installing plugins, linters, etc). It isn't clear to me the extent to which this is an artifact of the way the editor is structured, or to what extent it is just a result of having had time for these types of third party projects to grow.
There are pros and cons of course -- these weird shims can be troubling from a performance point of view, but on the other hand a plugin environment can grow, reach popularity, and then fall apart, and not take Vim down with them.
The web stack is abysmally slow, so you have to carefully pick the levels at which you offer extensibility. Emacs doesn’t have to worry about a DOM, CSS, etc. There’s just not that much between between grabbing input events, storing a character in a gap buffer, updating a glyph matrix, and painting the screen. And it’s all heavily optimized to be usable over ancient serial links: https://web.mit.edu/~yandros/doc/craft-text-editing/Chapter-.... So even making each of those steps heavily programmable in Elisp—every key press invokes a Lisp function that can be rebound, or adviced-around, still ends up performing reasonably well on a modern machine.
This is important, think about the whole Web. Too many ways of doing things and too much backwards compatibility needed for tools to develop further.
I always cringed at languages like Perl and also Groovy where the pride of the language designers seemed to be that there are so many ways to do the same thing.
>I once talked with a Firefox engineer who felt like an initial urge for openness left them with a lot of API surface area that locked them into a lot of design choices.
LOL, as if Firefox provided a stable API to extensions
I think that's the inherent catch-22 of having a big API. You end up in a situation where you can't change things for fear of breaking the API, but you end up also not being able to hold the API stable for fear of not being able to change things. So you end up stagnating and breaking things all at the same time.
IMO the leap from sublime to vscode was because the extensions made it so welcoming & bultin. I think the next leap from that is by-default sharing of those extensions and config. WASM might be able to do that coupled with security defining execution. We need a trusted mechanism to share what git-hooks promised without thinking about it. Like you said, collaborative.
If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.
I think WAPM and Wasmer could help a lot on the extensibility using Wasm plugins. I'd love to chat further, please feel free to reach me at syrus[at]wasmer[dot]io!
Hey there. I've been thinking about implementing an editor agnostic WASM based plugin framework and started prototyping with some promising results, although there are also a lot of of WASM related constraints to consider.
I think cross-platform plugins would be hugely beneficial for the whole ecosystem, and also generally for new editors since they can potentially benefit from a larger plugin developer community.
Is that something you can see your team collaborating on?
That's not my recollection, at least. I was more of an Atom fan than a Code fan in the middle of the last decade, mostly due to aesthetics, as shallow as that probably sounds -- but it felt like Code surpassed Atom in terms of community activity head-spinningly fast, like in its second year.
I also think the sibling comment is right; TextMate never had the huge collection of plugins later editors did, but you can very much see the seeds of Sublime Text's package system in it, and Sublime is a very obvious influence on Atom/Code. (Although they were smart to have package management fully integrated; Sublime's package management system is a bit clunky by comparison.)
Same, but if you're staring at an editor all day it has to look good. Atom did and still looks way better than VScode. VScode looks like a Microsoft product.
You can also customize Atom easier than VsCode. Why even build on web technologies if you don't let your users change things. For instance you have to have an extension to custom load CSS and it's kind of a hassle. Heck even Sublime has an easier interface to change the text editor in real time. You don't really need to do much as it already looks good though.
Funny how people are so different. I have never once thought that I needed my text editor to look good. Stare at anything long enough and your brain isn't even going to process it anymore!
fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.
While I am a Mac user, I've used Vim a lot, so I don't want to make it sound too much like I demand text editors be visually stunning works of art. :) Code initially looked just kind of clunky and toylike to me, in a way that Atom -- and Mac native editors like TextMate and BBEdit -- didn't. It's a little hard to explain. Code still isn't my favorite editor, but it's probably my favorite cross-platform editor.
For me, it’s the noise and clutter — every time I spin it up, it feels like VS Code is demanding my attention in multiple popups, and there’s a new tab or button I’ve never seen before with some mystical purpose, and the bottom bar is some jarring color that makes me feel like something is broken.
IntelliJ IDEs feel similar — sometimes I’ll open them up and after upgrading several plugins and dismissing a bunch of popups and “what’s new” dialogs, I don’t even remember what I was trying to do in the first place.
A month ago I switched back to Vim, from TextMate, but still on a Mac, and honestly: Vim is kinda pretty. I spend most of my day in fullscreen Vim, and with a good theme, Airline and a pleasing font it’s just as pretty as VSCode if not more.
I was under the impression that the "forced" upgrade to Sublime 4 caught quite a few out, and may have been a nail in the coffin.
I'm still rocking SLT 3, and it's my go-to for large file handling or just as a simple scratchpad, but development (of SLT) feels like it moves at a snails pace.
> This is how it's always been I think; their model.
I don't think ST needs to move fast. It's a good quality editor. It doesn't need a bunch of new features every couple of months. Just getting a major update once a year is fine imo.
I think that the learning curve might be in reference to installing plugins.
Installing an extension on vim (never done emacs) is something that does not just happen easily. There is no intuitive search for extensions built in, you likely have to install software that manages your plugins.
VSCode on the other hand rarely requires more than a single click through a built in interface.
The plugin ecosystem exists for command line editors, but it definitely has a learning curve
Emacs has a built in package manager as well as several alternative external package managers! Most of the time installing a package is as simple as running "package-install" or having a "use-package" expression somewhere in the init scripts!
I personally do not use any of these package managers and instead use my systems package manager on Gentoo to manage everything. Gentoo has most of the popular projects in the ::gentoo repo under app-emacs, and packaging your own is only a few lines of bash.
While I don't know about the plugin ecosystem of Vim/Emacs, I definitely agree with the learning curve part.
In Emacs/Vim I can't even escape the program if I don't know a keyboard shortcut.
In Vscode even if I forgot Cmd+W/Q I can simply click the close button. Not to mention that all the shortcuts are just globally used shortcuts in all the other software.
While I respect praising by the community of Vim/Emacs, I really don't think it's beginner-friendly.
So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific.
> In Vscode even if I forgot Cmd+W/Q I can simply click the close button
there is a close button in emacs. however unlike vscode, emacs can also run in the terminal
> So anyone starting a software career virtually picks Vscode, gets used to it, and almost has no reason to switch to something else for now unless they need something extremely specific
can be said about windows too. i started off on windows and jetbrains. today im on minimal linux, stumpwm as window manager, and emacs for everything except browsing. i find it very liberating having cut down my dependencies without having cut down functionality
When I run Emacs with a blank config, the default display has this:
Get help C-h (Hold down CTRL and press h)
Emacs manual C-h r Browse manuals C-h i
Emacs tutorial C-h t Undo changes C-x u
Buy manuals C-h RET Exit Emacs C-x C-c
Activate menubar M-`
GP's post was in response to the complaint that Emacs/Vim are hard to exit. They said that "Or, you know, you could just click on the File menu and click on Quit."
And I'm just saying you can't do that in the terminal.
The rare time I use vscode instead of neovim I always end up with a lot of random characters into the code and have to close it without saving for fear of having broken something. You call that user friendly?
User friendly is what most users find it easy to use.
Your argument is more on the lines that you are a legacy user who does't want to move.
The whole idea of using vim/emacs was when intellisense/autocomplete was in its infancy. And programming general required using typing skills as a autocomplete mechanism. The only real use of all that edit-commands-as-a-mini-language philosophy of vim is to write keyboard macros. Which again was needed because people lacked decent autocomplete features. Besides typing fast itself isn't connected to coding productivity these days.
See my previous comment. LSP/intellisense support is available on vim/neovim and many other editors. It is not like it is an exclusivity to vscode. Also many people actually configure their vscode to use vim-like keyboard bindings because they actually like the separation of the different modes.
Macros, substitutions and search commands are useful for many things and an editor like vim/neovim/emacs is not only used for code.
> Unlike VSCode, Emacs and Vim have a learning curve
have you seen the extent of available emacs packages? maybe it is a learning curve for a person who just learned how to power on a computer but i find emacs soo much more approachable
There is a fundamental difference between the kind of extensions that Atom has and the type Code has. It's something that people often miss when they compare the two.
Atom was made to be infinitely customizable by using web technology. You can dynamically change everything you want with custom HTML, CSS, and JavaScript. Nothing is off limits. Want to shrink the size of the tabs? Just throw in some CSS, everything is changeable.
Code on the other hand runs plug-ins in a separate isolated thread where they are left to communicate with the editor through an extension API. Every customization "hook" that a plugin has access to needs to be explicitly added in that extension API. The things that the devs didn't think (or want) to add are simply impossible. Want to shrink the size of the tabs? Tough luck (except for unsupported hacks).
Code is awesome, but I think Atom should get more credit for what it tried to do. It is arguably the most customizable text editor ever.
Thing is, the vast majority don’t care about infinite tweaking. I’d never want to change the tab size or anything else like that. It should be right to begin with. Also I don’t want to have to deal with extensions breaking every update.
What I, and almost everyone else wants is extensions which provide real utility like language packs, linters, git tools, etc. All of this works well on VS code.
I tried to use VS Code but just couldn't stand it. I don't want to say it's sluggish but it definitely isn't snappy, not even with a M1 laptop. It's fine, but it isn't good.
I ended up purchasing the upgrade to Sublime 4, definitely worth the price.
I love BBEdit, but its package ecosystem isn't well-developed compared to most other editors, and it doesn't have any kind of package manager -- it's more like Vim's native packages, e.g., "download the package and put it in this folder, and check occasionally for upgrades when you remember and re-install when appropriate."
wonder how much coffeecscript played a role in it. I happen to be writting coffescript at the time and noticed how it tended to hide its unnecessary wrapping when you use its syntax sugar. Still kinda wish we have a typed version of it.
IMO the killer thing is performance, VSCode starts fast and is smooth to write with. It blew away the older set of Electron-based editors. They work tirelessly on performance every release and it shows imo. Allowing extensions without destroying perf isn't easy either.
I said basically the same in a sibling comment but I can't agree with you. VS Code doesn't start fast enough and it's not smooth to write with. It's not exactly bad but you definitely feel the slight delays and slowness all the time.
I went back to Sublime exactly to get faster startup and smoother writing than what VS Code was offering. So I'm pretty excited to see how Zed turns out!
Sublime test starts faster and smoother than vscode, but it's plugins leave too much to be desired compared to a good vscode setup.
I was a massive sublime text 2 user with a living document I would share on how to set everything up just right, but now I only ever use it to open the odd 100+mb sql dump if I want to search for something and have it be syntax highlighted.
I don't percieve any of that but I also don't care if a game framerate is 30 or 60 or 120, it's probably the same type of brain difference! More choices is always a good thing.
Comparing it to Atom etc. It takes like 3 seconds to load a medium-sized Python project for me. And I was a long time vim user. The speed of vim is not worth the ridiculous gap in features.
Which gap? There are so many plugins. The only use I did of vscode this last year was to use the drawio integration and now I am doing diagram as code when I need to with mermaidjs or python diagrams and no longer uses it.
Even if it took 3 minutes to load it wouldn't matter because I plan to work on the project for days if not hours. OTOH, like you mentioned feature parity just puts VSCode in a different league altogether.
3 minutes(the imagined extreme scenario) pales in comparison the hours of time most people waste in meetings, or sipping coffee, or chatting with colleagues.
Just how much do you plan to achieve in 3 minutes?
This is why I continued to use sublime text all the way up to capitulating to TypeScript. Code was slower because of all the intellisense. I've had Code freeze on me a few times. Something that I don't have happen in Sublime or Vim. If you have a lot of RAM and work on a current mainstream OS it may seem smooth, but it's still using 400mb of RAM. May as well use Eclipse or WebStorm FWIW. That said I'm using VSCode now too, but things can always be better :).
Part of it may be just Windows. I use Windows a lot to move files and folders around and the File Explorer is something I constantly need to wait on to respond. The Windows as GUI is not very responsive in my experience.
Because all my ram is already consumed. I have a 16gb MacBook running only a browser, vscode, ms teams, and the docker containers for the app and I have no memory left so I see a spinning ball every time I change windows. Ms teams was the final straw. Slack was about 300mb but teams is now 700mb+
Once you exceed it some of the content will go to swap, which is going to slow down the system (and wear an ssd faster). 400MB is not that much though, for me Code usually takes at least 1.5GB RAM.
I pair it up with Alacritty on Mac and Linux for a nice performance boost. It will work in iTerm or one of the default Linux terminals, but much slower.
anyone can say vscode is bloated except atom. I gave it credit for being highly modular though. I remember being to disable the statusbar component (not just the UI) completely.
Interesting! I just wanted to let you know my perspective, which is probably quite unique.
I started using atom pre-1.0, a long, long time ago. I immediately jumped to vscode when I realised it existed.
The reason is a bit weird; it's the find-in-files/project (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. Compared to the Atom (and from what I can see in the youtube talk, zed has the same "problem") which opens c-s-F results in the main window, vscode opens them in the sidebar and doesn't clutter the main view with it.
The reason this is powerful to me is that I code mostly in domain-specific, esoteric, private languages that have no API documentation, no stdlib or docs, and no online resources to learn from. So the only way to learn is by example, or talk to someone who knows. Learning by example is usually much faster than talking.
So what I do is any new project is just a subfolder in a workspace that contains all known code in the language and the way I find out how to do something is c-s-F.
When the results cover the main view, or even parts of it (which is also possible with atom), it's just way too intrusive. The sidebar file list is useless to me at this point - where the result comes from is irrelevant. So why not use that space?
Also of course the fact that vscodes cross-file search was blazingly fast was an upside as well (I believe they used ripgrep for that since the start?)
Another thing I want to mention is (and you highlight the keyword search in that youtube talk around 18:54) the power of the command palette search method that is available in vscode: first-letter-matching. I don't know what the proper name of it is, but essentially "ps" matches "pub struct" for example. Obviously it matches it with a lower score than something that starts with "ps", but it's very powerful for matching in the command palette.
- Describing levels in video games, which are primarily data with code mixed in
- Describing transformations of different sorts (e.g. the types of languages used in compilers for specifying a programming language parser, and then optimizations)
- Defining hardware (analogues to Spice, Verilog, and VHDL). Hardware can also include mechanical objects, as well more broadly, wetware (e.g. custom bacteria, a la Ginko Bioworks)
- Run on custom hardware (e.g. SIMD and MIMD platforms, similar to GPGPU)
- Are primarily mathematical (e.g. for describing control systems, neural network architectures, etc.)
... and so on.
Not all of this is a DOD/medical mess. A lot of DSLs are REALLY REALLY FUN.
Coming from today's world, sure. But in 1966, a language with a built-in database was a godsend and there were no standard language conventions to adopt (C was still several years away and only COBOL and Fortran were in wide use).
I think this is powerful to everyone. I use that feature too and didn't even realize it was unique to VS Code. VS Code is really good in having a lot of features but not cluttering the main window.
wow I couldn't disagree more ... the search/replace interface of atom is the thing I missed the most from atom when I migrated to vscode ...
vscode _has_ added an non-sidebar find interface somewhat similar to the atom one -- but its not as good ... for one thing it doesn't support replace (find only)
Should development ever wind down, you already have the advantage of being able to announce it as "Zed's dead, baby" instead of clunky corporate euphemisms.
"Mission-critical tools should be hyper-responsive."
Did not seem to be important with the worlds slowest dev-tool ever, Atom. ;)
"Real-time collaboration produces better software."
At design level, ok. Programming is in most cases not a co-op operation. If it is, then you are probably creating solutions while writing code which is the best guarantee for bad solutions.
“Conversations should happen close to code.”
Agree to some degree, this is a big flaw with GIT. It is also a flaw with many programming langs and tools. Even if I use collaboration features in VS and VSC many langs are simply not designed for presenting code to people not highly familiar with the specific code base. So, an editor may not solve the problem here.
“Your editor should disappear.”
I mainly code in VS and what I can do in VS in 10 mins takes me a couple of hours in VSC. A tool should aim to be the default of a problem. The amount of time I have seen wasted over the years with people trying to master VIM or git from a prompt is just ridiculous.
One example could be scaffolding out a CRUD app and DB fairly quickly.
Even excluding scaffolding, VS can eliminate a lot of the boilerplate that takes time if you need to type it out yourself.
Not saying you can't setup VSC to do those kinds of things also, but VS is a tools included solution out of the box. (I say this as someone who hasn't touched VS in a few years now, but used it daily for a few years before that, and who generally enjoys using good/fast text editors.)
I would argue that boilerplates should be minimized in the first place. Regardless how fast it is to generate them, reading them over and over again together with the code human write is a huge waste of energy.
I would point out that there are places where having boilerplates is a significant time savings. I'm not disagreeing with you, just pointing out the practical application sometimes outweighs the cons.
So a generator tool is built in instead of installed via a package manager? Doesn’t sound like a big advantage, you still have to know that those tools are there and learn how to use them so you’re only saving the amount of time it takes to run npm i —global yo once. Same thing with snippets and emmet and a myriad of other shortcuts. Having a huge selection to choose from gives the advantage to VSCode in my book.
Just a single advantage, I should allow others that use VS more regularly than I. VS also has all of the same types of things you mention as advantages for VSCode as well.
I'm not advocating for people using it necessarily, just saying it is a really high quality IDE if you need or want to use an IDE.
Also with your custom UI framework, you will need to re-implement a text editor from scratch which is a pretty daunting task by the way [0]. Do you also have plans to open source the text editing / make text editing a part of the framework? Text editing (right there with accessibility) is the core reason why one would not go with a pure immediate mode GUI for any app. I guess you are baking immediate mode with some extras?
Rust on Mac with an open source UI - wow! If nothing else, you guys are ambitious as heck. Can't wait to see more. Also, loved the youtube video you linked to earlier in the comments - great to see an actual working demo instead of just an announcement.
It's been a few years since I used Flutter, but doesn't it still require you to use the related language Dart? I liked the idea of it, and I thought the tight integration between Flutter and Dart allowed them to do some cool things. But I wasn't a huge fan of the language itself. And I think it's a lot to ask prospective extension-writers to learn a new language.
Rust actually has a library with very good flutter integration, it does require using dart for the actual flutter part though, but it works well together.
"Native UI" can be interpreted to mean "UI written in native (i.e compiled to machine) code" or "UI written using the OS's native widgets". You are presuming that the only correct definition is the latter, but it's pretty clear from context that they mean the former.
Yes, you can argue for another plausible interpretation of those two words, but in actual usage "Native UI" has always meant the platform's native UI framework.
You're correct, although Qt attempts to do fake native widgets on Win / Mac, and given how relatively lightweight it is compared to Electron, it's understandable how it became a obviously point of contrast with the latter, which doesn't even pretend to be native. Given a choice between the two I will obviously take fake native widgets over nothing.
I feel like people are talking about different things when they say "native", to me it's more about being compiled to native binary, or being performant, than "native UI".
I've never been impressed with native UIs in any platform, web or mobile. The only context where I appreciate them is accessibility.
Nathan, I remember your passion for this project from its very early days. It has already borne fruit that has grown into a garden in the form of Electron, and I'm excited to see you are reimagining Atom in the form of Zed.
Will it be native Sublime Text fast? Not on electron?
I tried using VScode and Atom. Both were noticeably slow compared to sublime text. I can do silly, bad practice things like open a 50 meg log file in sublime and search for simple regex in the editor. Electron based editors stall and potentially crash.
50 Megabytes? That's tiny I would hope in 2022 that any text editor can handle a 50 megabyte file.
I routinely (like every day) open 500 megabyte files in SublimeText, and just checked to make sure that it can handle 1.5 Gigabyte files without much difficulty (it can).
Admittedly - once we get into the 5+ Gigabyte file size, startup times become annoying enough that I usually switch over to vim.
So, thank you for bringing this up as an important requirement for modern text editors - they should be able to open up multi-gigabyte text files without even breathing hard.
I may be biased, but at least sublime fast, hopefully much faster! Moving to Zed felt like going from a 30fps to 144fps.
You should be able to open stupidly big files and shouldn't experience much to any lag. Nathan has a demo he likes to give opening one one of those huge json files and searching, using multiple cursors, etc. It is pretty cool to watch.
I just wanted to say I really liked your product and despite multiple attempts to switch to VS Code (in anticipation of this day), I kept returning to Atom. I don't know why, I could never get VS Code to feel right to me, while Atom always felt right despite many of its quirks I've gotten used to over the years.
Since it's not mentioned on the website, what will be your roadmap regarding security?
I feel that all IDEs have security handled as an afterthought, VSCode made some progress but it's far from being there.
I just want to be able to use a code formatting / language extension without having to worry about it subverting my whole computer in a future update.
vscode is halfway there with containerized development, but apparently they didn't intend that to be security measure and they make it clear to only run trusted extensions. I'm guessing there are ways to access host files through the bridge.
It's obvious that we still have to trust extension authors, but an IDE with the correct security sandboxing can limit the blast zone if it gets compromised (leaking a source file vs getting a rootkit installed and ending up releasing compromised updates to production)
Also implementing undo for a big project is tricky. If the user switches to another file, collapses/expands things, runs a plugin, auto-formats some code, and then undoes things.
What will undo be like for a collaborative editor?
Well, unless it is paid, I don't know how would you continue to toil for years making great editor. And unless it is free, gain a good market share to continue to support.
I hope you would have some solution to this conundrum.
How often do developers want to edit the same file, at the same time, and have those updates occur in real-time?
I see this as a compelling feature for something targeting the use cases of, say Google Docs, where multiple people are contributing to an outline document or a business plan at the same time - but for code, I don't quite see the appeal.
> How often do developers want to edit the same file, at the same time, and have those updates occur in real-time?
That's a very specific example of collaboration. Remote work is exploding. What about, say, integrated, collaborative debugging or code review? Integrations with things like Slack?
I'm sure the folks at Zed know what they're doing, but this is already possible in multiple editors / IDEs. I'm excited to see how Zed innovates in this space.
I do this all the time. I use a tool that has 2 modes: turn-based and multicursor, the turn-based mode is signnificantly more annoying. Most of the time you just use it to highlight but it's also good to be able to help the other person with typos and comments, while they are focusing on the logic.
I don’t see why? Doing some refactoring you’ve decided to do and you can both go through the file at the same time refactoring different methods or whatever. What’s the issue?
In VS Code the collaborative editing (live share) seems like a dirty workaround put on top of an architecture not built with multiple users in mind.
I use live share all the time because it's the best thing we have for pair programming, but I often wish for a better solution. We often get disconnected for no reason, editors get out of sync, terminal sharing is near useless.
If you can produce something that doesn't feel like a hack, then I'm all in!
Features I would love to have:
- Terminal sharing should work like tmux with window size "smallest". It's the best solution I've found for having a shared terminal.
- Let us join a collaboration session from the terminal: `zed [URL]`. No annoying website that takes ages to open, or having to open the editor before joining the session.
- Let me start a server on a port and let others join that server. I can forward that port if I need to.
- Let me start a headless server on a shared dev env, and let me and others connect to collaborate
I have tried tuple, but for me it feels like a step back compared to live share. It has poor linux support, and sharing one screen is not as good as connecting to each other's editors. It just feels worse to watch a video feed compared to something that's getting rendered locally.
I do however believe that tuple can work very well if you are in an environment where everyone has mac computers and similar screen setups.
Does 'lightning-fast' mean that the application will be light on the system or does it mean that it's well optimised but still demanding enough that you require a modern computer?
I'm asking because I like to use my laptop Acer Aspire One most because of the size and because it the incredibly good feeling keyboard. BUT the system is 32-bit and running Intel Atom which means that before VSCode moved away from 32-bit I could use it, but it would take some time to open and I wouldn't really call it writing in real time, if you know what I mean~ :D
But I love the keyboard shortcuts and the multiple cursor functionality, which is why I stuck with it for as long as I could!
This time we're on our own in the marketplace with no big revenue-generating company supporting us. We'd like to be as open as humanly possible while being able to build a defensible business around the editor.
Atom was the first editor I wrote plugins to and contributed to core. I prefer it over VSCode, as it does less, and it's easy to customize for web devs. Sad to see it go, but it's for the best :(
I'm a huge fan of Text Editors, I've made a few basic ones myself. Thank you for creating Atom! For ages before Atom was a thing I grew fascination with using web servers for front-end UI and thereby using HTML / CSS for a local applications UI, I had seen this in SlickBeard and a few other usenet applications that used a web interface instead of a standard GUI interface to render a UI. I also remember a Google program that did this, though I can't recall the name. It might sound crazy to some to do it this way, but because the web server is localized to your system and your browser is usually responsive once open, every app I used that worked this way was always highly responsive and just worked.
I was dreaming of taking Vibe.d and CodeMirror and making something you could install as a daemon on any machine and code from anywhere. When Atom came out I was obsessed with it for a while, it was a whole other approach from what I was thinking of!
Did you ever do a write up on how you came to the thought of just taking a browser engine and turning it into your own sandbox and what that entailed in the earlier days? That seems like a fun story. Because of Atom we got great innovations that followed, for example Slack, Discord, VS Code, and the list goes on... and on... Heck POSTMAN! Which is probably used or has been used by every developer under the sun.
Why not collaborate with developers of existing code editors such as Xi Editor (https://xi-editor.io) or Lapce (https://lapce.dev) instead of making yet another one?
As for lightweight alternatives to Atom, there is also Lite-XL (https://lite-xl.com).
Speaking as someone involved in the Xi community, there's not that much to collaborate with. Work on Xi has completely stopped, and work on the Druid GUI framework is still in early stages.
I think it could be interesting to compare notes re GUI frameworks (especially since the Druid community is about to see some overhauls there) but I don't think it would have saved them that much work if they'd done that from the start.
Earlier this year Keith Simmons, the author of Neovide (https://github.com/neovide/neovide), joined our team. He's been working on Vim bindings and paying a lot of attention to getting it right. As you probably know there's a lot of surface area, so this will take time.
Please, please, please, make it infinitely pluggable from the start. That's the strength of Atom and similar editors. That anybody can create a plugin either for something very niche or just connect some huge amazing tooling directly to the editor.
If you can make editor in Rust pluggable or scriptable with JS, Lua, C#, Python and whatever someone knows and is comfortable with you got a winner.
Please make zed capable of running in a terminal. If I could have a modern editor that can run in the terminal and had a nice GUI, I would definitely pick it up. There's still many instances where I'm working on a remote dev machine, on my iPad, over a serial connection, inside of tmux, where a terminal based text editor is a necessity.
We have graphics, but I could see a mode where you `scp` a headless moon lander version of Zed up to a remote server to do remote development. VS Code has a feature like this but I hadn't used it much before switching to Zed full-time.
> VS Code has a feature like this but I hadn't used it much before switching to Zed full-time.
Please check it out — being able to edit / run / debug code on a linux server using a mac desktop over ssh, and having the whole experience be as seamless as edit / run / debug locally, is a huge win — it's pretty much _the_ reason that I’m currently using VSCode 90% of the time despite being a huge JetBrains fan (to the point of paying for their full enterprise pack out of my own pocket)
(JetBrains tools do kind-of support remote file editing, but it’s flaky and slow, and remote run / debug are a nightmare — compare to VSCode, where I sometimes mix up local and remote development because they’re identical except for the hostname in the titlebar when running remotely)
I'm not sure if this feedback is useful, but I have to say that a collaborative text editor doesn't feel like that big of a sell.
Pairing in VS Code over Zoom has gotten a lot better over the last year or two, to the point that I choose it for simplicity over more purpose-specific tools like VS Code Live Share (which is a bit slow/glitchy but fine, and overall "neat") or Tuple (which is great).
Would I pay money for "VSCode, but faster"? Absolutely. I'm waiting multiple seconds for keystrokes to apply sometimes and don't know why. But the extensions are what make it VS Code – if I just wanted "a faster text editor" I'd uninstall all my extensions and just keep using VS Code (it'd blaze), or switch to Sublime.
I'm excited to see more people working in this space, so I certainly wish you luck!
Sounds interesting. I've love to take part in the alpha and provide feedback. I've done software engineering professionally for 25 years in Javascript, C++, Rust, Java, Erlang, Elixir, Clojure and Python (mostly Java and C++). I've used Emacs, VS Code, Visual Studio, and other IDEs.
>Mission-critical tools should be hyper-responsive.
>When you move the cursor or type a character, you should see pixels on the next refresh of your display—every time. Even sub-perceptual pauses add up over the course of a day to create unnecessary stress.
I remember there were lots of research for this in Next-Generation Atom during the Atom era, before VSCode came along. Having a UI and text responsiveness within 16ms on a 60Hz Monitor is a tall order which I believe even Sublime is incapable of.
Considering 95% if not 99% of developers on HN thinks VSCode is very fast or fast enough, I am not sure this point is worth pursuing. Personally I really want to see it happen. As I hate latency.
Good luck! A clean slate code editor with Rust's memory safety guarantees sounds great. Just don't fall for the 2nd system fallacy. Keep things simple and pragmatic.
I tried Atom for a while, but it didn't cope well with other IDEs renaming files before overwriting them. I tried to fix it, but the response I got from the community was rather dismissive. It was quite irritating to present obviously wrong behavior and be told that it was correct.
My attempts to dive into the code myself lead me down a rabbit hole of dependencies of dependencies of dependencies, to the point that I just gave up. I switched to vscode and it has mostly stayed out of my way.
Best of luck with Zed, Nathan! I've always been impressed with your brilliance, vision, hope, and positivity. Hope we can catch up again soon, until then keep changing the world for the better!
"collaborative" "Rust" "code editor" "CRDTs" is very reminiscent of Xi Editor by @raphlinus which shared all of these traits. Xi was abandoned with the conclusion that CRDTs aren't suitable as a basis for text editing interactions, or at least that implementation wasn't.
Is Zed related to Xi in history or as inspiration? Why are you confident that Zed will be able to overcome the issues that blocked Xi's advancement?
I've been talking to Nathan and think he has a good handle on the issues. One of the biggest mistakes in xi was an over-reliance on async and a loose coupling between the main logic and the UI surface. Zed isn't making those mistakes. I'm eager to see what the come up with and look forward to friendly competition in the open source Rust UI space when they release their toolkit.
A new approach with native speed and incorporating LSP and easy extensibility at its core instead of bold-on – as in older editors – sounds interesting. LSP and across-file editing doesn't always fit nicely into the old tab-per-file or view-per-file paradigm. Is there going to be an open-source version with free license available for Zed, or will this be a commercially licensed project?
Funny, this doesn't sound like a spiritual successor to Atom at all. What made people excited about Atom (compared to Sublime Text, which people switched from and was ~always faster) was the extensibility.
Sounds like this won't have that. It's only a successor in the sense that it's built by the same people and tackles some of its challenges.
All these new generation text editors are cool and all, but I feel they are mostly rehashing the UI of VSCode. VSCode is fast enough, and the perceived speed of text editors / typing only needs to be so fast.
Looking forward to innovations in UI. Cause otherwise, VIM is comparable if not better in performance than modern text editors.
Interesting. I think a major reason for VS Code's success is their usage of web-stack, which is stable, powerful and well documented, enabling easy access to higher customizations for anyone. It will be interesting to see how much a custom UI can emulate this without html&css.
Are you using 32-core / 100GB RAM monster machine? I do everything on my rather powerful laptop, but Jetbrains IDEs are just too much. I can't have more than one project open at time, which is limiting. I didn't try CLion, only IntelliJ for Scala and Rider for C#/F#, all on smallish projects and it will still take 3-6GB of memory :|
I'd be interested in even lighter than VSCode IDE ;)
I can easily open 20ish projects, but the experience is often still sort of sluggish.
Like, change a file outside of the editor, open it again, and it’ll sit there stuttering for a bit while it realizes the file is updated and it has to re-index.
It’s not the end of the world, but the experience there could be more fluid. Because you do this often (e.g. every time you switch a git branch)
I often have several simultaneous PyCharm projects open with separate completely introspected and navigable virtualenv's with lots of installed libraries, and also ongoing DataGrip, and at times CLion or IntelliJ sessions ... all the Jetbrains IDEs are performing quite well. At times running Docker as well. 32GB Macbook Pro M1.
I feel CLion latencies even on a much smaller project. Sublime Text is faster, and I hope Zed is near. I guess people have different sensitivity for this. It’s not about time waste, it’s just affecting the flow.
I hope it will be much faster. I try JetBrains IDE every couple of years and the sheer latency and lack of text rendering quality is turning me away every time.
i hate vscode is written in electron, i always noticed the latency, it's good enough but it's annoying. atom was same but worse. what I also disliked about atom and sublimetext, is how you needed to install 20 extensions to get basic functionality and they weren't always compatible, with each other. Vscode approach of having most of basic functionality builtin but behind flags which can be disabled meant most people had good setup from the get go. Vscode to me was like jetbrains but faster and lighter. Although in some cases jetbrains was more robust.
If there is vscode that was written natively. I'd be so happy. Even if there is a new branch of vscode that is 6 months behind in features but is built in native it'd be huge for me.
zed sounds like a great project. What are your thoughts on the existing Rust GUI frameworks? Naturally the core editor widget will need to be custom no matter what, but for the rest of the UI, have you considered using one of the Rust GUI frameworks already being developed?
When we started on Zed the Rust UI framework space was much younger. In absence of a mature solution that met our exact needs, the simplest path for us was to build it ourselves. We're too far into things now to change at this point.
Fair enough. Hopefully when you're ready to work on accessibility in your UI framework, AccessKit [1] will be ready. I'm hoping to have usable Windows and Mac implementations by the end of this year.
When will the source repository going to be made public and what license do you plan to use? For the editor and the UI kit. Looking forward to seeing how that all works.
If you will directly write yourself everything to a GL canvas anyway, what do you gain by going through a whole WebGL dependency & context rather than just using a native OpenGL context?
Humble question, I don't mean to sound confrontational, I ask of genuine curiosity: Why not contribute to VS Code instead?
For Julia, Atom+Juno was excellent. It was the first time I could select+run on a proper IDE (I was coming from python+notebook). To me this was revolutionary. Then I discovered VS Code, so Atom+Juno stopped making sense. You seem to be a very competent developer, so why not just contribute to VS Code?
If nothing else, Atom was the birthplace of Electron.js and I know it is controversial, but Electron was a boon for the rapid development of cross-platform desktop applications. VS Code was built - in turn - on Electron.
We need people like nathansobo to try out new ideas and directions. I, personally, am very much looking forward to their WebAssembly-based extension system and Zed being the flagship UI application developed in Rust.
Despite VSCode being an Electron app, I've never had any performance issues with it - really, it's a great example of how Electron can be done right.
On collaboration, I'm not sure what they might add that isn't already covered by GitHub/GitLab/AzDo etc. Again being honest, "collaboration" sounds like a weak Open Source pitch to VCs. I'd be interested in some details though, incase there is something truly novel here.
I do. I don't have a powerful laptop though. Whenever I open a new project I hear the cpu fan and cpu usage close to 100%, (TypeScript and ESlint are also a bit heavy and switching the app may not help with that). It's totally bearable though and as the years go by it will be less of an issue when everyone has a faster machine though.
The biggest performance improvement would probably be RAM usage. You don't notice laptop specs get more RAM. The usual options are still 8GB or 16GB. Until 32GB / 64GB is the new default, having a non-electron app will always be an improvement.
Personally I don't think it matters that much in the end, whether it is CPU usage or RAM, but if the editor was just as capable but faster, I'd switch. Code will never be rewritten from scratch and it will always be tied to Electron, starting a new text editor built with faster technologies could give a long-term edge the existing competitors would not be able to use.
I think that's a worthy goal. I find it really bad that in this age of super-mega CPUs apps still feel not much faster than say 20 years ago. The reason I think is because like cities apps are built on top of other apps, like VSCode on top of Electron.
Secondly when you re-create from scratch you can keep the best features and drop the ones we've learned are not so useful.
I don't think VS code would ever accept a change to native UI or switch off of electron, so it seems like a nonstarter for someone who wants to experiment with native UI text editors.
VS code is written almost 100% in JS and typescript, it will always be a nodejs app through and through without a complete rewrite. And even if they wanted to rearchitect VS code all of the extension APIs, extensions themselves, etc. would demand the existing nodejs runtime.
So long story short... VS code is a good editor if you want to contribute to a nodejs and web tech based text editor, but not if you want to explore other architectures or ideas.
Not the person you're responding to, but it sounds like they're going in a different direction with Zed in terms of the tech stack, where VSCode is pretty similar to Atom.
Is Zed a company? I wish you luck, but I'm pretty skeptical that a whole company can survive on making a text editor, or even editing tools in general. Wouldn't it be safer for user if you open sourced this?
As someone that loved Atom, and have been screwed over by Facebook's Nuclide, and now Github's Atom, I have to think about my options.
why isn't emacs an option? It's the longest continuously maintained open source code editor there ever has been and still outperforms electron editors half a century after it first appeared
We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting.
Here's a talk I gave last month: https://youtu.be/wXT73bBr83s