←back to thread

120 points misternugget | 2 comments | | HN request time: 0s | source
Show context
rgrmrts ◴[] No.42198090[source]
I really like all the blog posts and videos the Zed team has put out, thank you if you’re reading this!

Unrelated to this specific post I’m such a fan of Zed. It’s the first feature complete text editor in recent memory that I’ve truly enjoyed using (i.e. it stays out of the way, is really fast, feels well engineered). I’m coming to Zed after years of Emacs which I still have love for but no longer feels like a competitive piece of software (it does not take full advantage of how good computers are today, e.g. gpu rendering or multicore). I really hope Zed stays a fast and lightweight text editor instead of becoming some bloated growth-at-all-cost VC ware (not that they’ve exhibited any signs of that happening). I’d also happily pay for Zed without a subscription based thing for access to LLM features (which I do not use).

replies(1): >>42198366 #
seanw444 ◴[] No.42198366[source]
> it does not take full advantage of how good computers are today, e.g. gpu rendering or multicore

Why does Emacs need that though? I hear people say this all the time and I don't get it. Multicore kind of works against the structure that Emacs touts as a feature. And GPU rendering? In many applications, I totally agree with these complaints. But it's a text editor.

I tried Zed myself, and it's good. But it doesn't dethrone Emacs (for me personally).

replies(4): >>42198660 #>>42198929 #>>42199042 #>>42201176 #
PittleyDunkin ◴[] No.42198660[source]
> Multicore kind of works against the structure that Emacs touts as a feature.

I have consistent issues with emacs locking up when executing network requests. I'm sure there's a specific bug that could be hunted down and addressed, but this sort of thing shouldn't happen much in an editor that's multicore by default.

I'm not trying to dismiss emacs' reasoning, of course, but I can understand being disgruntled with it.

The actual rendering I've been quite please by, though!

replies(1): >>42198822 #
rgrmrts ◴[] No.42198822[source]
Yeah this is one reason, or Emacs freezing for up to a minute when updating packages. Also when using an LSP I notice latency.

I use Emacs GUI (outside of the terminal) and comparing performance for rending to something like Zed or Sublime is definitely noticeable. It’s great that Emacs is so resource efficient but sometimes I wish it used more of my beefy computer(s).

Like I said I still love Emacs and it’s okay for it to make a different set of trade-offs. I honestly didn’t think I’d ever switch editors but here we are!

replies(2): >>42198923 #>>42199061 #
1. seanw444 ◴[] No.42198923[source]
That's fair I guess. In the case of IO that can be an issue. When I hear multicore, I assume we're talking about parallelism, not concurrency.

As for LSP, other than the Nim langserver, I've been quite satisfied with Eglot's performance. I'm curious what your setup is like. To be fair, I'm running a highly customized Doom Emacs config, so it's possible I inherited some non-vanilla optimizations I'm not aware of.

replies(1): >>42200161 #
2. PittleyDunkin ◴[] No.42200161[source]
> When I hear multicore, I assume we're talking about parallelism, not concurrency.

Parallelism trivially enables concurrency. The lack of parallelism magnifies the issues emacs has with concurrency.