VC backed? Zed's dead.
Sequoia backs Zed
101–110 of 346 posts
Re: Sequoia backs Zed
#102I 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.
Yup, I was playing around with Zed and kind of liked it, and even debated switching over. But this kills it for me.
Re: Sequoia backs Zed
#103[flagged]
Does an anti-palestinian fund investing in the company really count as harassment of the community?
Re: Sequoia backs Zed
#104Earlier quoted context omitted.
Note to Zed: I prefer paid products to enshittened ones. Please please please, get paid rather than holding on too tightly to making things free forcing future enshittening.
We're working on it! :) You can pay for Zed today if you'd like - https://zed.dev/pricing - and also the editor itself is open-source under the GPLv3 license. So if at any point in the future Zed changes direction in a way you don't like, you are perpetually free to build the version you liked from source (or make a community fork and take it in a different direction).
With Shaun Maguire's recent behavior associating with Sequoia is gross
Re: Sequoia backs Zed
#105I love working in Zed. It really is a delight to use, and I think the Agentic coding integration is really well done. I'm excited to see them investing in this space more. I understand people's concerns about VC funding, but I think building quality products takes capital. The funding is still relatively small, especially when you compare it to players like Cursor, etc. And I think Zed is a much, much better product!…
> And as others have said, Nathan (CEO) is a delightful human.
Hate cancel culture as much as the next techbro, but since y'all point out they're "a delightful human", it'd be interesting to see how Nathan then responds to concerns raised in some quarters: https://github.com/zed-industries/zed/discussions/36604
Re: Sequoia backs Zed
#106Is IntelliJ "bad"? Aren't the reactions here overly negative?
This means the company is funded, development will continue, zed will continue to improve. An IntelliJ style license (for example) is an acceptable trade-off from my point-of-view
Re: Sequoia backs Zed
#107Re: Sequoia backs Zed
#108Earlier quoted context omitted.
You can try it out. I would say it’s aiming to be a more modern Sublime Text, which is a win to be considered in the same category imo.
I have tried it out and by default it was so slow as to be unusable. After discovering it required some customization in /etc (because it's the only GUI application that fails to recognize my GPU on a very popular distro with next to zero customization, because I game a lot on Linux - weird how that's a me problem and not a Zed problem) it got better, but still noticeably slower than VS Code. The modern Sublime Text…
Slower than VS Code?? I guess it's just poorly optimized for Linux. On MacOS, I find it to be significantly faster than VS Code, and the only alternative I've found that's in the ballpark of Sublime (from the performance aspect).
Re: Sequoia backs Zed
#109I 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.
The problem with accepting VC money is they will eventually demand a return on their investment, which means that the forces that drive enshitification will eventually come for Zed in some form. I suspect that we'll see more and more features locked behind a paid subscription and the open core of the editor will become neglected over time. Here I am on my free-as-in-freedom operating system, making commits with my fr…
Sure, but given the existence of vim/nvim, emails, visual studio code, cursor, etc the price for editors has largely been driven to zero, or at least capped by what JetBrains charges. My concerns are more this is a big bet on a different thing, not the editor (which is quite nice, even if using typescript regularly makes it balloon to 15gb of ram), making them a giant pile of money. With the editor as a free complement.
Re: Sequoia backs Zed
#110Earlier quoted context omitted.
It's apparently this but I can't really say that I get it: https://bablr.org He seems to be saying he spent $350k making this. I guess it's some tooling for writing parsers. He has this to say about Zed: > Zed: Founded by Atom’s dev team, Zed was the rewrite that Atom always wanted to be able to do but couldn’t when Microsoft bought Github and made the executive decision to kill a product it might otherwise have had…
IMO in the 12 months or so I've been aware of the BABLR work and observed the author's comment contributions, they've never really substantiated why BABLR would be preferable to tree-sitter, or how a JS-based implementation of parser tech can fulfill any of the same niches. Most consumers of tree-sitter leverage it via FFI or native code, not an embedded or external JS runtime. It's not clear to me how you could subs…
We have some meaningful advantages that help us gain a practical edge on Tree-sitter:
- Our core and grammars are relatively tiny and can easily be loaded into any web page as a syntax highlighter, except actually a bit more: more like being able to embed ASTExplorer directly into your docs page or blog post to help people understand code examples.
- We support runtime extensibility of languages, e.g. TS can extend from JS at runtime. Tree-sitter only supports static linking, so every shipped language extended from their JS grammar contains a complete copy of the JS grammar.
- Our grammars are much easier to debug. They're written as plain scripts, and they can be run and debugged in exactly the form they're written in.
- We can parse inputs with embedding gaps. An example of such an input would be the content of a template tag before interpolations have been applied. Parsing after interpolation opens the door to injection attacks, but parsing before interpolation allow safe composition of code fragments using template tags.
- We emit streaming parse results on the fly, and can parse infinitely long data streams with ease or syntax highlight. within large single-line files without freezing up
- Tree-sitter is half an IDE's state solution: "just add text buffer". Our solution is the whole thing. One stop shop. IDE in a box.
- CSTML lets us do round trip serialization of any tree and also gives our trees stable hashes. Tree-sitter could trivially represent its parse results as CSTML if it cared to, giving it competitive compatibility with BABLR. A rising tide lifts all boats.
- While they're setting out to make version control for the first time now, we're already basically as powerful as git thanks to the combination of hashed trees, immutable data, and btree amortization within nodes for maximum structural reuse of data.
- Did I mention you don't have to deal with this? https://github.com/tree-sitter/tree-sitter-typescript/blob/m...
- We can probably literally just run the Javascript source code for Tree-sitter grammars on our runtime. The only problem is the C lexers, but C lexers are one of the great annoyances of tree-sitter anyway since any context in the grammar requires you to hand-write the lexer