>However, as already implied in my article, you can get most of the guarantees without losing your sanity.
Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust? I'll use "safety" in a loose term to say "you really infrequently encounter odd memory safety issues". Go for example still has the occasional memory corruption issues with maps in particular although these don't show up too often and the race detector exists.
C# is probably the closest I can think of for AOT? I don't really know what the deployment story for a .NET application looks like these days though.
Go has some language design things that turn people off.
>but they are not the sole source of bugs in applications — as developers of Zed found out.
You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part? As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.
I used to write a lot of C#. I used to write a lot of Go. I now write either and basically exclusively write Rust these days and a bit of C/C++ at work. The only time I've really felt the pain of `Rc<RefCell<...>>` gross types was recently when trying to port a game engine's data loader to Rust. It makes heavy use of OOP patterns and trying to emulate that in Rust is asking for a bad time, but I did it out of just out of trying to one-shot the migration and keep logic similar. Not fun, but I knew what I was getting myself into.
A lot of things that people wanted in Golang (or in a C alternative), are in the newer language, Vlang[1][2]. Sum types, option/result types, enums, no variable shadowing, flexible memory management (GC can be turned off and stdlib does not rely on), generics (way before Golang's handlers relented to the masses), more safety features, goodies like filter, map, etc... As Vlang is 75% similar, it's also easy to learn and retains the high readability.
>Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust?
I've already answered it in the original article — Rust is already here, and better language is not. Still, it will not make me say "it's the best option we have by now" — because it's not nearly the best option.
Performance? Lots of code is cold and not impacting performance much. You just don't need everything written in Rust or C++.
>You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part?
I'm kinda saying if I was a Zed dev I would have my pillow wet with tears at night. I know this because I participated in IDE development in C long time ago, and I was drowning in this whole low-level stuff all the time, I just could not do a single feature because I have to handle hundred of those other small things before the feature can work.
>As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.
I have no idea what those applications were and how complex they were, so I cannot comment on it.
Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust? I'll use "safety" in a loose term to say "you really infrequently encounter odd memory safety issues". Go for example still has the occasional memory corruption issues with maps in particular although these don't show up too often and the race detector exists.
C# is probably the closest I can think of for AOT? I don't really know what the deployment story for a .NET application looks like these days though.
Go has some language design things that turn people off.
>but they are not the sole source of bugs in applications — as developers of Zed found out.
You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part? As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.
I used to write a lot of C#. I used to write a lot of Go. I now write either and basically exclusively write Rust these days and a bit of C/C++ at work. The only time I've really felt the pain of `Rc<RefCell<...>>` gross types was recently when trying to port a game engine's data loader to Rust. It makes heavy use of OOP patterns and trying to emulate that in Rust is asking for a bad time, but I did it out of just out of trying to one-shot the migration and keep logic similar. Not fun, but I knew what I was getting myself into.