Hacker News Reader

Comment by Alupis | Hacker News Reader

Zed looks and feels amazing to use. I test-drove it for a bit on my linux system, and the feel of it is difficult to convey to those who have not tried it yet. It's easy to overlook the significance of gpu accelerated editor - but I promise you, use it for a bit and you'll be sold.

The only feature that is preventing me from switching to Zed is the current lack of DevContainer support[1]. After investing a significant amount of time perfecting a devcontainer (custom fat image with all tools/libs + config), it would be a large step backwards to go back to installing everything locally.

There's a lot of eyes on this feature, so I'm hopeful it will be implemented in the future.

[1] https://github.com/zed-industries/zed/issues/11473

View on HN

One of the reasons why I'm not fully switching yet is a Zed's inability to update the currently open file with changes made elsewhere [1].

All the other editors I use are aware of outside changes, but not Zed. And I'm just not willing to close and reopen the file to get fresh contents. Eventually, I'll forget to do it and lose some work.

[1] https://github.com/zed-industries/zed/issues/15791

How do other editors handle this in your experience? I’m pretty sure VSCode behaves exactly the same, with the addition of a manual “merge” editor when you try to save, but never shows changes live for a modified file.

Changes to open files without any modifications in the buffer are always shown. Are you using any kind of containers or virtual fs that might be interfering?

Other editors, at least, display a pop-up indicating that the file has changed on disk in the meantime and ask me if I want to reload the file or overwrite it with my current buffer, or do nothing (geany editor does that, for example). And it happens immediately as soon as I hover over the editor's window.

Interestingly, Zed displays the change right away for the first time, but any other edits are not picked up. I'm using Zed's installer, Zed updated to the latest version, no containers or virtual fs, my partitions are ext4.

I write C++ and Typescript and just tried Zed on Windows, it didn't feel significantly faster for me (maybe a bit).

What's worse is C++ autocomplete - both on the same project with clang and CMake - it might be that I need some more setup, but I felt like Zed understood much less of tricky modern C++ (tbf, VS Code isn't perfect either) and the autocomplete was kinda broken. I fully admit this might be due to my own inexperience, so I won't hold it against Zed, but so far I haven't seen anything significantly better to justify making the switch.

I tried it for a while. It's okay, I guess. Typing latency is neither an issue nor a bottleneck for me, so personally, I don't see the appeal. Apart from that, it feels lacking and offers nothing else that I don't already get from VS Code. If I really cared about performance, I would use Neovim.

I find Neovim to be surprisingly sluggish. That's of course after installing extensions, but I don't find it particularly performant. Zed feels way snappier.

Any chance you'd be willing to share more about your custom dev container?

I also really like dev containers in vscode. Wondering if you've looked into using something like fedora silver blue and it's "toolbox" system to do the dev container business at that level.

I agree from a company perspective using dev containers gets all devs on the same page

What does having a DevContainer get you?

I’m all for documenting every bit of my setup, but beyond that…

I use a devcontainer to run Claude Code on a sandbox with all tools and services installed. That way I can run YOLO mode with some safety.

That's quite unnecessary. You could just mount "all tools and services" from your base system without the complicated Dockerfile: https://blog.gpkb.org/posts/ai-agent-sandbox/

Why would I do something that’s more work, less secure, and not cross platform?

It's less work and just as secure, but you do you.

I sometimes work on old PHP applications, some of which require versions as ancient as 5.4 and refuse to run on anything beyond that. They're not only difficult/impossible to install on modern systems, but also make it hard to onboard other people — you have to write a detailed setup document and then waste a couple of hours time for each new system. And then repeat that a few more years down the line.

Why not write that document as a bunch of build instructions instead of free-form text, while also isolating the result from the rest of the system.

Are you talking about the same thing? This sounds like your typical docker/compose dev setup for running the software under development. The "dev container" stuff is more about running your editor stack in a container, like static analysis tools, language servers etc.

In our case, instant on-boarding of devs with no host setup needed. It's a large, complicated repo with a lot of unusual system dependencies. We build a multi-arch base image for all this and then the devcontainer is built on-top. Devcontainer hooks then let us do all the env setup in a consistent, version controlled way. It's been a god send for us and we'll never go back.

Not the OP, but it's pretty useful in my team, we all work on the same environment, with the same system dependencies, with no setup required on development machine (except the need for docker).

In the devcontainer you can run code snippets, use the system shell and access an execution environment close to production if well made.

It also allows to avoid (system) dependency conflicts between different projects you may work on.

It's ideal for open source projects, no need to install a toolchain locally for small changes. I've used it for a POC in Go where nobody has Go installed in my organization. Not that Go is complicated to install, but I wouldn't ask anyone to install a toolchain for a one-off POC.

There's other toolchains that are more involved or conflict with an operating system's pre-installed stuff, like (iirc) Ruby on MacOS.

I guess I wasn’t clear in my question.

What are you getting beyond what normal docker-compose gets you was the question I should have asked.

There were like a dozen answers all referring to things I think you can just use docker compose for.

Did I miss something?

I am a big fan of using it when working with somewhat complicated toolchains, especially if they need to be compiled. Cleaning up the file system is as simple as deleting the container and starting a new one. OCaml on windows comes to mind.

What I do is run Zed in the dev container. But a custom one with bubblewrap.

It works with devpods

Reply on news.ycombinator.com