Hacker News Reader

Comment by simonerlic | Hacker News Reader

To be fair, this isn't just a random group of people - they're the people who made Atom, Electron, and Tree-sitter.

Oh undoubtedly they'll make a nice editor; I just think it's a tough thing to monetize when there's so many 'good enough' free editors around.

Their plan is to make really elegant team-based shared coding features baked right into the editor - think a mashup of VSCode + Slack, and then charge for that, likely as a monthly subscription. It's not a bad idea if it can increase team velocity but the requirement would be enough people on the team live within it to justify the cost.

I drove Zed for about a month, its very performant and a joy to use, but the lack of a remote development feature is massively prohibitive and I went back to VSCode as a result.

There are way too many other features missing as well to do anything serious to be fair. All the things you would like proper IDE to do to increase your productivity.

Let's see in couple years.

The biggest problem is to get those initial features decent so that you can extract the value from crowdsourcing the missing things like VSCode does.

> crowdsourcing the missing things like VSCode does.

Based on what I am seeing right now [1], they might well have enough inertia to seriously compete against VSCode. I've analyzed a lot of open source projects and their community engagement on GitHub is quite impressive. Their contributor and new contributor stats is still going up, even though the initial hype was 2 months ago, which is really impressive.

If they can get proper support for Linux and Windows and nail core features, I can see people wanting to contribute in the future and business leaders paying for it, if they can demonstrate improved productivity and collaboration.

Full disclosure: This is my tool

[1] https://devboard.gitsense.com/zed-industries?board=gitsense....

they could do it if they built a proper plugin system. right now if its ot compiled in, you can't add it.

What do you mean by "remote development feature"? Debugging remotely, a la gdbserver?

Not the OP, but what I assume they are referring to is the ability to work on a remote host. For example if I have a Mac but I am working on a remote Linux box, VSCode will allow me to easily work sync with a repo on the remote host. It will also seamlessly handle port-forwarding for web dev.

IMO this is the best feature of VSCode.

It installs and runs a server stub over SSH (or into docker, or WSL), which lets it act as if you're working on a local project. Stuff like the built-in terminal is remote, building, debugging, etc all work remote.

That's the problem with increasing fragmentation as an n+1 of the same thing and trying to do everything yourself rather than delegating and scaling effort and expertise via crowdsourcing and outsourcing through plugin maintainers.

An "opposite" of the Atom approach appears to be an extreme overreaction (rather than a sensible middle way) and fails to solve the problems it brought: a slow, wasteful platform and a tradition of abandoned, fragmented plugins (also a problem with Vim/neovim, emacs, VSCode, and JetBrains).

A balance would be a curated plugin marketplace requiring quality, continuing maintenance, and support. Atom, VSCode, and JetBrains have some curation, but not enough. I don't know how to solve this other than to charge end users subscription fees and pay people for their efforts.

Also, that brings up the problem of monetization. A number of plugin authors insist on trial, freemium, or paid-only plugins because it's not a spare time hobby for them. Lacking monetization, some plugins won't ever be created.

So I don't see how zed will solve any problem other that being art as wonderful technology applied to a tough, busy, competitive category without enough unique, competitive advantages to self-reinforce increased adoption. As such, it seems unlikely to ever morph into a complete and useful IDE to uniformly support every development niche. Even now, I have difficulty finding a usable Haskell IDE with commercial providers such as VSCode or JetBrains to wonder if zed will somehow manage to be better than any of them and/or vim.

TL;DR: I think Zed project leaders were overly ambitious, unrealistic, and failed to anticipate the endgame.

Additionally, it’s also not yet another “text editor”.

It’s very clear the differentiation of Zed will come in the form of the collaboration functionality it will have.

And speed. Startup time is instantaneous, in comparison to VS code say.

The same team that "erased" native editors is now selling us the solution to the problem they created.

Erased? On the contrary it seems, to me at least, like new editor development has really grown over the last few years. Editors like Kakoune, Helix, Micro are coming along nicely. I'm looking to switch, at least partially, to Helix soon myself.

How much are you going to pay for the 5 seconds per day you open up your editor? Most people dont even close it in the first place.

Presumably speed is an overall important factor for the creators — not just startup speed — and I'd imagine it translates into speed elsewhere, such as input latency and UI responsiveness.

I haven't tried this software, but I imagine it's more about having the UI keep up, so you can stay in the flow state.

Is raw code output so large that your editor can't "keep up" really something to optimize for? For me personally I write as little code as possible. you don't get bonus points for number of lines you write.

Yes, while at the same time having a responsive UI is important for editing, and we're not hanging less stuff in our editors than yesterday. Both emacs and neovim and vscode are essentially IDEs today.

Yes it is, especially when you work with lots of large files in big codebases. I can open files in Vim that would crash VSCode, which is essentially why I still use Vim for certain parts of development.

Straight up not true. Running my local copy it takes 5 seconds for the window to appear.

If this happens with Zed 0.129 or later, could you open an issue? We had a problem at one point where there was a delay in macOS verifying our app’s code signature because we weren’t attaching the code signature correctly.

5 seconds sounds extremely long for a macOS native application. Could be macOS security (XProtect), storage latency?, tons of compressed memory?...

Not all of us have those editors in high regard.

Reply on news.ycombinator.com