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!
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.
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.
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.
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!
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.
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!
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?
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.