True. But it's a pretty small space to be in. And there are good reasons for that:
a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.
b) Rust can only give these guarantees because it is ALOT more complex than C. That means harder to read, harder to write, harder to learn. And developer time matters. Alot. If I can already ship features, while my competition is still stuck in onboarding, it won't matter if my code has the odd memory bugs...those can be fixed...I will already have the market to myself.
> a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.
A powerful type system helps quite a lot with logic bugs actually.
Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that?
> and it has null pointers
Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. Go made the choice to have null pointers (which do exist in silica), and avoid the complexity of languages who pretend that null pointers don't exist.
> what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that?
This is a good illustration of how to model data using Rust's type system in a way that gives you compile-time guarantees of correct behavior:
> Because we are enforcing our design constraints entirely at compile time, this incurs no runtime cost. It is impossible to set an output mode when you have a pin in an input mode. Instead, you must walk through the states by converting it to an output pin, and then setting the output mode. Because of this, there is no runtime penalty due to checking the current state before executing a function.
> Also, because these states are enforced by the type system, there is no longer room for errors by consumers of this interface. If they try to perform an illegal state transition, the code will not compile!
You're getting into the Turing tar-pit. There's nothing you can do in Rust you can't also do in Go, technically. Hell, you can do it all in Brainfuck too, if you so desire.
The big thing, though, is ADTs. Being able to say "the value is one of 3 possible values" is a lot easier than saying "here are three values, you should use the non-zero one".
> Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that?
> Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious.
At runtime. i.e. production. You think that is just as good as solving the problem at compile time? I certainly don't.
I think they're a strong contender... it's somehow simpler than Rust
then again the correctness guarantee may be weaker??