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.
EDIT Nvm, I see this is our best option for now: https://zed.dev/waitlist
For now, people pairing/collaboratively writing Rust is our focus, and we are pulling people in that fit that criteria!
VSCode/Codium is amazing but it feels the same - sluggish but a feature/extensions-packed behemoth.
I hope Zed is able to establish a nice extension ecosystem as that is priceless!
Thank you!
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.
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.
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.
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.
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.
LOL, as if Firefox provided a stable API to extensions
I think companies make brand new products whenever that happens. No legacy baggage. If it gets popular enough then the old software gets killed off.
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!
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?
Man that felt a bit like extortion, but I mean well.
If extensions lock down the files they will touch and the urls that can be visited I think sharing them becomes more palatable.
Perf became the biggest problem however, which VSCode took over.
I actually use VS Code as well, but more like an IDE with tons of extensions, and Sublime is my 'basic' text editor.
I ended up purchasing the upgrade to Sublime 4, definitely worth the price.
While Vscode is my IDE now, I definitely love the instant-opening of Sublime.
Ironically, it's even launching faster than TextEdit.
Let me introduce you to Emacs, vim, Sublime, TextMate, ...
Unlike VSCode, Emacs and Vim have a learning curve. And turning them into full blown IDEs makes their usage even more complex.
> Sublime
Sadly, Sublime is sort of dead.
> TextMate
TextMate: Text editor for macOS
That's not the point, we were talking about 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
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.
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
Sublime has ongoing development on https://www.sublimetext.com/dev and the last major release (4) was just about a year ago.
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.
Everything works just the same, and I don't get the purchase pop-ups.
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.
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.
Macros, substitutions and search commands are useful for many things and an editor like vim/neovim/emacs is not only used for code.
Nobody ever talked about typing fast.
Or, you know, you could just click on the File menu and click on Quit.
I'm not making that comparison.
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.
Not sure what you're going on about.
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-`and in Vim, there is no such display.
With emacs this is a feature, not a bug ;)
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
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.)
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.
fwiw I use Linux and suspect that's a big part of why Macs never appealed to me.
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.
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.
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.
Why does this matter? What is the point of saving RAM instead of using it?
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!
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.
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?
Thanks for the tips! I love HN.
P.S. Any other plugins, tips/tricks you recommend for a vim user jumping into NeoVim/LunarVim?