321–330 of 346 posts
I love the spirit of Zed. From the principles to the low-level implementation details, it all screams "good taste". It's immensely interesting as an object of study (the code is great, from GPUI all the way up). Having said that, I don't think an editor should be VC backed. It's the obvious pragmatic choice to get a team together to support a thing, but I'm concerned by it.
Earlier quoted context omitted.
not OP but I am not thrilled by "x months/years of updates" because you pay upfront for updates that you're not really sure that will happen. Will I get bug fixes? Will I get new features or at least significant improvements? Will the two person team work on the other project? I have had experience with quite a few projects switching to recurring billing, occasionally justifying it with "to support development of gre…
> not OP but I am not thrilled by "x months/years of updates" because you pay upfront for updates that you're not really sure that will happen. Will I get bug fixes? Will I get new features or at least significant improvements? Will the two person team work on the other project? Thanks. I guess I'm just not really seeing how that is any different to what we did before? You'd buy a ST3 license with no knowledge of wha…
You got everything in the current Major Release and every minor and patch update to it. If it took more than three years to release a new Major it was not a big problem, because you were still covered.
The new model might leave you without bugfixes before a new major version is out.
Earlier quoted context omitted.
They have some house cleaning to do in their leadership before I am willing to use a product they back. https://github.com/zed-industries/zed/discussions/36604
I have never seen so much virtue signaling and moral superiority in a GitHub issue. What a joke.
Earlier quoted context omitted.
Basically yes, vscode was free, almost as fast and had more features, like out of the box intellisense.
People refer to it as VSCode, but do people really use VSCode or VSCodium? I personally use VSCodium. I think that is the most de-telemetry'd version of it, I think?
As for people in general, safe bet in almost any topic is that most people won’t care. :) So yes most people use VSCode.
Earlier quoted context omitted.
They also don’t bother to announce a Vim or Emacs one either. VS Code provides good default and most people don’t care about editor fluency. Which is why they keep using it.
>>They also don’t bother to announce a Vim or Emacs one either. vim has a universal and in many ways a eternal use case. You have to edit a file at some point on a server, be it a self hosted or even on ec2. Thats kind of the only real use case for vim. In these days of AI assisted coding, no one really 'edits' code. A lot of editor short cuts and fluency related concepts kind of in many ways are not relevant in this…
The "distraction" framing assumes everyone has the same preferences and working style, I for one find VSCode (and IDEs in general) massively distracting from productively solving many tasks. No, it's not "a skill" issue - I have used InteliJ every single day for almost a decade, diving into some profoundly advanced and non-documented features, and I do open VSCode from time to time.
I feel your argument conflates initial learning curve with ongoing productivity, and assumes VSCode's approach is universally optimal rather than just different.
While i am sure this sounds insane i had to drop zed due to lack of the “last file dif” button gitlens vscode plugin provides. It is a godsend on quickly debugging the why of things. If anyone knows how to replicate the same functionality with the same number of clicks in zed, id happily switch back to it.
// ${XDG_CONFIG_HOME}/zed/tasks.json
[
{
"command": "git --paginate log --follow -p -m -1 ${ZED_FILE}",
"label": "last-file-diff:${ZED_FILE}",
"shell": { "program": "sh" }
}
]
// ${XDG_CONFIG_HOME}/zed/keymap.json
[
{
"context": "Editor && mode == full",
"bindings": {
"ctrl-shift-g d": [
"task::Spawn",
{ "task_name": "last-file-diff:${ZED_FILE}" }
]
}
}
]
Earlier quoted context omitted.
Plugins were kind of it's selling point, yet it was pretty easy to mess it up with Plugins to the point of it being unusable - and not knowing what plug-in caused that.
The same curse emacs suffers from. What is the best sweet spot an editor/IDE has achieved to date? I remember the extremes of the utter unconstrained chaos of Emacs and the rigid ultra-high-boilerplate approach of the Eclipse IDE. Emacs was fun to hack on, but impractical to use as an IDE, because if you installed enough plugins to make it useful as an IDE, it was broken half the time (my experience, many years ago.)…
I have completely opposite experience with [modern] Emacs. Of course, it wasn't smooth from the day one, but neither was my ride with different IDEs. Somehow, I keep coming back to Emacs because no IDE ever provided all the machinery I need to be productive. For me (and I suppose for many other people), Emacs is far more sweeter spot of an IDE than any other alternative.
DeltaDB sounds of being a >git innovation for coding itself, and would fulfill Zed's promises in Nathan Sobo's debate/discussion with Steve Yegge recently. Seems to solve a real problem which is growing rapidly, both in the old way and in the new way ... if it can overcome _slop_ in LLM chats, and the sheer enormity of code/data ahead. Trying to picture how coherence will survive. With claims/hype/concern floating ar…
Earlier quoted context omitted.
> not OP but I am not thrilled by "x months/years of updates" because you pay upfront for updates that you're not really sure that will happen. Will I get bug fixes? Will I get new features or at least significant improvements? Will the two person team work on the other project? Thanks. I guess I'm just not really seeing how that is any different to what we did before? You'd buy a ST3 license with no knowledge of wha…
the difference is subtle, and comes mainly from the fact that at the time the concept of Major Release still existed. You got everything in the current Major Release and every minor and patch update to it. If it took more than three years to release a new Major it was not a big problem, because you were still covered. The new model might leave you without bugfixes before a new major version is out.
Earlier quoted context omitted.
I doubt anyone will follow this. 1. Everyone else is building on Electron. 2. People still sleep on or dunk on Rust. There's a great deal of negativity here on HN for the language. 3. There's only so much Rust talent out there.
Whilst rust is a big part of this it is not the core of their innovation. Pushing everything to the GPU is. Stating that everyone else is building on Electron belies your lack of exposure to any editors other than vscode \ atom spin offs. Realistically all the editors including those based on Electron could easily shift to leveraging the GPU more and that would be big leap forward for performance.
Enlighten me.