It become open source just last week. Currently don’t have Linux version but soon it will have. Linux Roadmap issue
I’d love to have a vscodium alternative written in a faster and more efficient language. Most editors and IDEs don’t quite fit my workflow, while vscodium does.
Yep, I also want a good alternative to codium which run fastly on Potato. That’s why I am trying different Editor now days like Lite-Xl and other more.
Can confirm that’s it’s very fast. Just lacking plugins at the moment.
I will watch it with great interest
I hope it gets there. I was a sublime user until vs code’s integrations got so far ahead that the productivity gains outweighed the slowness, but I really want it to be faster.
Do zed plugins have to be written in rust? If they do then that will slow community contributions since it’s not as popular as JavaScript for vs code.
Vs code is slow? Literally the entire reason I switched to it years ago is because it’s very fast.
Yep, VSCode is slow because it is built on Electron which is just a another browser.
extensions tend to be the slow part in my experience. after a couple heavy extensions on an already struggling work laptop I’ll frequently outpace it’s input handling and have to wait for it to catch up
Depends on what you’re used before I guess. I came from sublime text which was written in C++ and was blazing fast. You could throw any size file at it, I still use it when I need to edit a large file. I can notice the input lag in vs code even in small files with a vanilla setup. After adding plugins the lag can become even more noticable and in certain use cases it straight up slows you down. It’s not so slow that it’s unusable, but it’s noticably slower, and leaves me desiring more speed. But speed alone isn’t enough, it needs really good plugins which is why I traded speedy sublime text for vs code in the first place.
Maybe for you. I personally am quite picky about tools I use all day every day.
Yeah, it’s fine, I said I use it didn’t I? But it’s just fine, so I’d prefer something even better.
Exactly.
Atom being open source was why I switched to it from Sublime.
Atom’s shitty performance was why I switched away to VS Code.
I’ll try it once Linux support kinda works
Don’t understand why they made it mac only, I don’t think mac users are even aware of other apps than what Apple tells them… :)
It seems that a lot of their responses have been along the lines of: “Well, it’s because I have a Mac. Good luck if you don’t!”
I understand that, sure, but they would have had a lot more support for this editor if it was for Linux. Now I barely ever hear about it at all in the news.
How does it compare against Lapce?
Maybe it will be more stable and have more features than Lapce. I think so because I tried Lapce yesterday, and it was so buggy on my machine. But no doubt Lapce is a solid alternative to VSCodium and it has all the features that I want but it lacks customization and is buggy for me. I am still not sure for Zed though because I didn’t tried it yet and waiting for Linux support.
Lapse is going the extensions-for-features route, cross platform from the start, is more buggy atm, slower progress (doesn’t have 3 dedicated experienced devs) but is more accepting of community support.
Zed, similar goals and rust backend, probably has some monetization goals (eventual offering of live sharing code service), and Zed isn’t afraid to hardcode features. Like… very hard hardcoded features, to the point that I’m kinda concerned about it. This 5min clip of Theo looking over the source code shows it pretty well https://www.youtube.com/watch?v=ZOYp6-k9HhE&t=1533
The Atom/Zed devs write the most well-documented code I’ve ever read. Clear variable names, perfect comment-explainations when needed, etc. I wish they would join up with Lapse.
If you’re asking about specific names of features, its just the ones seen in that video clip. It seems like a pattern of very not-modular-ness.
If you’re asking why that pattern is concerning as an end user: Zed claims to be “a lightweight text editor”. But hardcoded support for a particular javascript library, as well as hardcoded support for a particular formatter, feels a lot more like a opinionated IDE packed with features designed for the specific workflows of the creators. Even if there’s no runtime cost, there is a technical cost for open source contributors. These little not-modular things can really bloat the codebase and make it hard to contribute.
More importantly, if Zed does add plugin support in the future, its going to require a major code refactor. Which makes forks and outside contributions especially hard.
From a lock-in perspetive: if something better than tailwind comes out, and we were daily driving Sublime 3 with no extensions, its no big deal to switch to the new thing. There wasn’t any hidden favoritism to begin with. But in Zed, not only will it feel bad to use the unsupported new thing, but also the team behind the-new-thing can’t realistically fork and add support either. They just have to hope the Zed devs decide to support it.
If their website said it was a fast low-overhead opinionated IDE I’d be fine because I’d know the kind of lock-in I was getting into.
