I've lost faith in their editor and GPUI - you were the one, Zed! They are full-steam AI on things like this. I expected this article to be about a general alternative to git, but it is about LLM-focused coding in a way that doesn't make sense to me, as it slices a line between human-written and LLM-written code which does not exist in a meaningful way.
Their primary product, the Zed editor, is unusable for me and others due to it mismanaging file syncs on disk - when external edits happen, the editor retains stale state unless you close and re-open the specific file (Not even an editor reopen syncs it). There is a significant risk of your changes being silently overwritten or conflicted. Amusingly, the risk of this is increased when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
It begs questions like: "If coding has changed so that we should use an LLM-focused source control tool, why can't the LLM fix a severe bug in our software that has a closed-form solution?"
No. Still heavy as hell. (AKA uses loads of ram and CPU, slow, sometimes unresponsive). It is the price we pay - the tradeoff is IMO the unmatched editing and introspection/refactoring capabilities. I'm surprised there hasn't been a real competitor in this space.
Yeah, JetBrains IDEs are Java-based, so rather heavyweight. Then again, VS Code (and Cursor) have a browser engine running in the background, so not really better in my book. Sublime and Zed are more efficient of course. OTOH, JetBrains IDEs might be memory intensive, but don't actually feel sluggish on my 5 year old Core i7 laptop with 16 GB RAM.
I've been running a latest-1 version of a few of their products on silicon Macs since M1 w/ 8GB RAM without issue. I use minimal plugins and work on medium-sized codebases and their IDEs are some of the most reliable software I use.
the__alchemist · · focus · HN ↗
Their primary product, the Zed editor, is unusable for me and others due to it mismanaging file syncs on disk - when external edits happen, the editor retains stale state unless you close and re-open the specific file (Not even an editor reopen syncs it). There is a significant risk of your changes being silently overwritten or conflicted. Amusingly, the risk of this is increased when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
It begs questions like: "If coding has changed so that we should use an LLM-focused source control tool, why can't the LLM fix a severe bug in our software that has a closed-form solution?"
tarr11 · · focus · HN ↗
the__alchemist · · focus · HN ↗
Hamuko · · focus · HN ↗
the__alchemist · · focus · HN ↗
rob74 · · focus · HN ↗
za3faran · · focus · HN ↗
njovin · · focus · HN ↗