I've always been conflicted on them. I like that they allow me to be more explicit about things which are read from input or parsed out as strings vs internal parts of my program (I rarely call .to_sym), but I've also lost time to being careless and indexing hash maps with the wrong type.
I've had to fix so many errors over the years due to string/symbol mismatch in function calls and/or hash access, and never once have I benefited from the extra optimizations that the guaranteed singular allocation of symbols have given me where I wasn't able to get the same benefit from a frozen string literal.
If it was up to me I'd get rid of them, but I know I have an unpopular opinion and it's really only a thought experiment.
Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already.
If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.
At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.
The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation, because the compiler will reject most random changes to the code. Which is the point of course, but C++ will compile programs which then crash, giving you a very misguided feeling that you’re making progress, but this is very important in the process of gaining new skills.
I don’t see a way around it, programming without garbage collection is hard, Rust makes it very clear very quickly, which is also the point, but this is at odds with making the learning curve accessible.
> The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation
Yes, this is the biggest issue with Rust that I've seen; most language will let you do something wrong and then as you learn you get better. Rust will refuse to compile if you're not doing things correctly (and normally I would put 'correctly' in quotes but correctness in Rust is well defined).
The first time I tried to experiment with learning Rust was a disaster. I just wanted to decode some JSON and filter it, but -- oops! -- I don't own that variable. Okay, well I can pass it somewhere else mutably, right? But then that function does the work and returns something that... what's a lifetime? What's a 'a mean? How do I... screw it, I'll go back to Python.
Eventually, after the tooling and the tutorials got better I came back to it and really enjoyed what I've seen so far and even rewrote one of my own personal tools in Rust[1] to experiment with. It's nothing impressive, but it was fun to do.
The logic in my comment wasn't that you need to have written considerably amounts of code to be expecting this, just that to not be expecting this would make me think you hadn't. If that makes sense.
On your second point, I think IDE integration for C++ is similar as it is for Rust. Just Rust errors and tooling are a million times better regardless of IDE.
Oh, the more junior the developers, the quicker they will get any benefit. That's common for any language that enforces correctness, but the C++ vs. Rust comparison isn't even fair; C++ is an incredibly hard language to use.
Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever.
Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default!
Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.
While the C calling convention continues to rule operating systems and FFIs, I think it’ll continue to limp along. Hopefully one day that can be fixed, it’s annoying that C is what I have to reach for to call SomeLib no matter what language I’m using
Pair programming can be really great. Or horrible. Depends entirely on the people.
This would be good for code-walks too though. Instead of having to share your screen and hope the video comes through well. Everyone can follow along in the comfort of their own editor.
it's probably subjective, but I find these collaboration features can be overused for this kind of thing.
If someone is walking me through something, I just want to see what they see so I can focus entirely on what they're saying and no part of me is distracted by having to follow along or seeing other code.
I know typically these collab modes have an auto follow feature, but it's not as simple as just read only video being streamed to you, there's loads more ways it can go wrong and add noise / distraction that provides no benefit.
re: pair programming, the lion's share is moving to be with agents, not humans.
I think the fundamental flaw that dooms this feature is non-developers. Do teams and orgs want more than one chat system? I suspect not. It will be very hard (impossible) to convince people who can pay back the VCs to switch zed as the basis for their chat for all employees.
> video comes through well
I cannot recall the last time resolution or latency was an issue (zoom/meet)
> Everyone can follow along in the comfort of their own editor.
With different screen resolutions, you cannot be sure everyone sees the same code. Video guarantees this
Zed is the only modern IDE-like editor which is fast enough to replace (n)vim for me. I plan to use it for more and more projects, but I've had minor issues with it's Vi-mode.
I'll always remain someone plugged into vim because I need it sometimes when shelled over a terminal. Editing files over SSH can work with editor support, but is often less reliable or fast than jumping through whatever hoops I need to to get an SSH connection once and then doing everything from there.
I just have a few plugins which help. Mainly the LSP for gotodef and popovers for type info, etc. This was what finally made me transition to neovim. Also a tree viewer, Startify, and :Rg for ripgrep integration. Those are my big ones.
Sadly my workflow of using `!` to get back to my terminal and things like `!make` or `!cargo build` is fucked in neovim. So I do a lot of ctrl-z and the a lot of killing stopped processes I forgot I suspended. I've complained about this in various threads and chats, but the developers aren't interested in letting us use the old vim `!` which is super lame.
> Sadly my workflow of using `!` to get back to my terminal and things like `!make` or `!cargo build` is fucked in neovim. So I do a lot of ctrl-z and the a lot of killing stopped processes I forgot I suspended. I've complained about this in various threads and chats, but the developers aren't interested in letting us use the old vim `!` which is super lame.
I'm sorry... what?? I still use vim as I haven't found a reason to jump to neovim, but you're telling me external commands don't work properly? That's wild.
They "work"... but instead of switching back from the alt screen and giving you your terminal back, they open a gimped little window within vim which makes it hard to navigate, copy, and search for things in the output.
I would love to see collab servers take the same path as LSPs in being standarized and integrated across various editors and IDEs. I would love to work more closely with my VSCode peers, for example. Of course some features may be outside the standard and only supported with likewise editors, e.g. voice chat perhaps, but having shared cursors and a text chat would be a good start.
This is what I'd like to see as well. These collaboration tools are really good, but I barely use them because they always assume that you and your team are using the same editor. Most of the time that's just not the case, so I've used them a handful of times but beyond that there's little opportunity.
It's probably not an issue the Zed team will experience as they're all naturally using their own editor. Hopefully it's on their radar though.
> because they always assume that you and your team are using the same editor.
Network effects are probably a strength for a company, not a drawback (which it is for the user of course). Even VSCode has some notion of network effects, such as their proprietary extension store.
And there were an Emacs minor mode and a Vim plugin too that did this too, both for the SubEthaEdit protocol and for the one of the Gobby editor (https://gobby.github.io/).
We’ve been growing and have had to scale authentication beyond what our original collab server could handle. Not many people are using collab yet, we’re prioritizing non-collaborative features (like our recent Windows release), and we’re planning on rebuilding all of this on top of DeltaDB. Fundamentally, it just fell through the cracks.
Self hosting will be a vital feature for users and enterprises though, we’re planning on revisiting it once we have a few more features settled :D
Looks great. I use some CRDTs like Loro and Automerge, are there any learnings or collaboration you're taking from them to improve DeltaDB?
Also the name, I thought it was a database with CRDTs due to the "DB" at the end of DeltaDB, but it's a version control system, I thought that was somewhat misleading, any reason why it's named so?
Is this / will this be open source? I have a direct immediate need for this and was about to break ground on greenfield implementation. Had no idea Zed was working on something similar. I would of course much rather collaborate than maintain a competing VCS.
I mean, I hate that our lives are becoming consistently more and more surveilled, but this doesn't shock me. I've assumed my Google search history is accessible, despite not even being logged in. Of course they are saving conversation. Even if they said they weren't I wouldn't believe it. It's fucking sad, but that's the reality.
I wish I had a solution, so we could all feel a sense of freedom and pressure lifted from our thoughts and actions. But I only see this getting worse.
So am I upset that the NYT's lawyers want access to the records... a little. It's an invasion of privacy. But I'm more upset that they have anything to dig through to begin with.
If only we could see how things within all these companies we are forced to trust actually work. If only OpenAI was actually open. When will we all learn to demand open source, open platform services. Capitalize the development, and capitalize the infrastructure, but leave the process and operations out in the open so users can make informed decisions again. Normalize it like how homes are normally inspected before being purchased.
Overall, I think I'm glad they exist.
reply