having jumped from go to rust, I still really appreciate go.
Everything is rust is way harder and more complicated than in go. However, with that added complexity you build rock solid software. Many times over i've ran into issues in go where something deep down in a library returns a nil on a pointer and my crap blows up in unexpected ways.
I got flagged in another post for having an opposite opinion from you. But I'll state it again. I think there's a yet to be invented language that has go's simplicity and rusts speed and safety. It's only a trade off right now because no alternative exists.
You might (rightly!) respond that you can exclude dependencies that use `unsafe`, but then you've just displaced the problem to "now I need to find new libraries". Point being, it's going to be a schlep either way. There will always be a schlep.
Which schleps you want to deal with, and how you want to deal them is the trade-off space that different programming languages position themselves within.
As I said in another comment, Rust is great, but there's a reason it's not universal. That reason is not that people are ignorant, stupid or lack the incentive to avoid schlep. It is instead that sometimes, dealing with Rust is harder than dealing with the rest of the damn problem.
In my case, I have noticed that Go is a good solution when Rust is not. I now have two arrows in my quiver. Neither is my favorite. I think this is the right attitude, personally.
I'm a relative newcomer to Rust, and yes, this tracks with my experience. I know the "Go is simple" meme is overused, but it really is a remarkably small language. For all the amazing engineering that has gone into Rust, the price you pay is that you have to think and track a lot of stuff.
> Many times over i've ran into issues in go where something deep down in a library returns a nil on a pointer and my crap blows up in unexpected ways.
Doesn't that mean precisely that Rust is easier than Go? Finding those bugs must be a nightmare, not to mention the impact of them happening in the first place, in prod...
Usually people say X is easier than rust because writing a program in X is easier than writing a program in Rust. When in fact they should be comparing (writing a program + debugging) in X vs (writing a program + debugging) in Rust
>Doesn't that mean precisely that Rust is easier than Go?
I suppose that boils down to whether you find it easier to wrangle Rust-isms or track down runtime bugs/panics. In many cases, I'd rather wrangle Rust-isms. In some cases (and they're not rare), I'd rather wrangle Go's runtime errors.
What makes some Rust people insufferable (not you, friend!) is that they think everything is about the language and toolchain, and they lose sight of the tremendous relevance of the application.
There's a reason not everybody is switching to Rust, and it's not because they're ignorant or stupid.
From an anecdotal standpoint, having used both. Go is easier then rust in aggregate. This of course is just based off of feeling as there's no quantitative metric able to aggregate each dimension into a single number.
This is 100% accounting for program + debugging.
The anecdotal reason for this is because the human brain finds it easier to debug golang bugs then it does to write and completely understand all the semantics of rust. This is the same thing as why python is easier then C++ EVEN though counter-intuitively C++ has strict type checking and python doesn't.
Rust in my mind is ultimately better than C++ but it unfortunately, like C++, it retains a level a complexity past a certain reasonable level that prevents it from hitting ubiquity. Thus it's not the answer. There will be in the future some language out there that will be just as flexible/safe and less complex.
Or maybe… certain problems lend themselves better to some languages than others, even when accounting for debugging, and Rust just isn’t the winner every time?
>What I would give for a preemptive green-thread scheduler in Rust.
They tried this in early versions of Rust and ended up removing it.
Rust has lower-level constraints than Go that they didn't want to compromise on.
E.g. performance constraints of FFI C-interopt with predictable fixed stack space. Those reasons mentioned in various subthreads:
As counterpoint, Rust's original designer, Graydon Hoare, prefers "green threads". In a recent blog post (2023-June), he mentioned
that he understands why the Rust team got rid of it for performance reasons but he's not fully convinced of the ultimate tradeoff:
-> Async/await. I wanted a standard green-thread runtime with growable stacks -- essentially just "coroutines that escape, when you need them too". Possibly with a somewhat-embeddable outer event loop / IO manager library, but that's always going to be a little tricky. Go started and stayed here, but they had to do a bunch of gory compromises to make the FFI work and it leaves a lot of performance on the table and torpedoes a bunch of embedding opportunities. Rust started here too, and it got rewritten a couple times and eventually thrown out because of a lot of reasons but none which completely obviated the need (as evidenced by the regrowth of Async/Await and Tokio). I've softened my position on this and have a grudging respect for where Rust wound up (especially in enabling heterogeneous selects, which I think puts it in a similar and enviable expressivity class as Concurrent ML). But if I'm being honest I never would have agreed to go in this direction "if I was BDFL" -- I never would have imagined it could even work -- and still don't know that I think the result quite pays for itself.
Firstly, thank you for the collection of links. Believe it or not, I've been researching this on the side, and there are a few interesting discussions in there I had missed!
>I've softened my position on this and have a grudging respect for where Rust wound up
>I never would have imagined it could even work -- and still don't know that I think the result quite pays for itself.
I concur. There are at least two big reasons to love Rust: type-checking and low overhead. I happen to work in a field where I don't need the latter, but would probably benefit from the former.
(And, I am critically dependent on preemptive concurrency, which not only means that it has to work well, but also that I'm sensitive to ergonomics in this domain.)
