How do people who have experience with both think about Go vs Rust? I'm not even sure if that's an apt comparison but people seem to be pitting them against each other these days.
On the other hand, Rust is geared to be a true systems language where you can implement a kernel and do stuff where you'd traditionally do them in C and C++. Rust provides a really strong type system, strong focus on safety (with guarantees provided by the compiler), better pointer semantics (unique, borrowed, etc...), optional task-local GC where the GC is implemented as a library and not in the language itself (i.e., not implemented in the compiler and no associated syntax).
Two things comes to my mind immediately. Are there any known undefined behavior in the Rust language? Since UB is one of the most notable item that makes safety by compiler not a guarantee.
Also, how can we guarantee the compiler doing the check properly? Is it hard? My interpretation is that safety relies on the correctness of the compiler from that quote.
There are bugs in the implementation, but the language is specified to have no undefined behavior. (Note that some things are left unspecified, such as the memory layout of enums and vtables and the sorting algorithm that `sort` uses, but there is no undefined behavior in the C sense.)
> Also, how can we guarantee the compiler doing the check properly? Is it hard? My interpretation is that safety relies on the correctness of the compiler from that quote.
We can't guarantee that the implementation is correct without writing a full-on certified compiler, but we're working on a theoretical proof of correctness of the type system.
Issues relating to compiler correctness do come up in the real world, and occasionally they lead to vulnerabilities. However, such issues are much rarer than issues stemming from undefined behavior documented as such in the C/C++ standards. So we're more focused on eliminating undefined behavior from the Rust language at the moment than proving the Rust implementation correct.
> issues stemming from undefined behavior documented as such in the C/C++ standards. So we're more focused on eliminating undefined behavior from the Rust language at the moment than proving the Rust implementation correct.
That's exactly the problem. Since C and C++ specifications have UB, compiler writers could anything they feel right.
When I say spec I mean the language specification itself. If we are on the same page on this, then yes, I agree that the spec should be proven correct. If not, please excuse my lack of knowledge in compiler and language construction.
If I spent the next 6-12 months writing libraries in Rust targeted towards Python-level code, we could spend time comparing Rust + those libraries vs. Go and have a productive discussion.
Personally, I think that Go is a clumsy language, a chimera of C plus Python, having neither type safety nor significant abstraction nuance. More sophisticated minds than I have flamed Go in depth, I won't bother parroting them. :-)
Go's primary advantages are:
1. Google.
2. Targeting the Python/Ruby developers & needs.
3. Compiled & statically linked
4. Relatively stable.
1. Still < 1.0.
2. Semi-manual memory management. Gc'd pointers are kind of a pain.
3. How many pointer types again? >.<
4. Strongly typed. [1]
[1] Probably should expand this. You have to spend serious time understanding how the type system works after you get into the more advanced type systems. Haskell, ML. It's a disadvantage for quick learning and the quick hack to get the system working. Changes simple in a less typed language (e.g., Perl) can have non-local type ramifications in a project. /me handwaves. It's double-edged.
Well, that's exactly what makes Rust so useful for many domains. Rust is useful for systems code because it doesn't use GC for everything.
> 3. How many pointer types again? >.<
There are references and then smart pointers, of which owned pointers (~) are one kind.
In the end, the languages are quite different. Rust is ML/Haskelly, Go is C-ish. It's a matter of whether you like the advanced type systems, options, matching, etc in Rust, or if you want something that is capable, but a lot more straightforward and easier to come up to speed on, like Go.
It has not-very-good support for things like custom data structures, type-based programming, and high-performance math, and prioritizes using its own idioms in code to the detriment of any other model of programming. Rust has better support for all of these.
I've only toyed with Rust, although I've written a fair amount of Go, but honestly, I don't think they're trying to do the same thing at all. It's not C++ vs. D, it's more akin to Scala vs. Haskell.
This means that Go is far more predictable than Rust currently is for anyone who wants to use it seriously, especially for larger systems that will take some time to develop.
There has been talk that Rust 1.0 will be released later this year. Hopefully that is the case, as it'll allow for the stability that'll then allow more users to seriously consider using it. But until that happens, Go is a much more viable choice in many cases.
There are some applications for which you might conceivably use both, but I think the differences in design really outweigh stability issues right now in terms of "which language should I choose?"