I was recommended by someone to learn Rust, but without reason. Does anyone have any reasons for why I should look into this, apparently, new language?
The biggest selling point of Rust is that it allows you to write low-level code with memory safety (so no use-after-free, buffer overruns, Heartbleeds, etc) and without runtime overhead. Right now this is a niche that Rust has to itself, as far as non-academic languages go. It's like having a C++ static analyzer with guaranteed no false negatives built into the language.
You also get nice high-level productivity features like type inference, lightweight closures, a module system, a modern take on interfaces, etc.
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.
They're for fairly different markets. Go is geared to be a much simpler language that attracts people from Python and Ruby. This results in things like a garbage collector, no pointer arithmetic, no generics, etc..
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).
strong focus on safety (with guarantees provided by the compiler)
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.
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.
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.
I agree with your points except to claify my point on compiler's correctness:
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.
One big advantage that Go currently has over Rust is much greater stability, in terms of language and standard library changes.
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.
They're for different applications. If you can't use a runtime or garbage collector, you can't use Go. If you don't want you or your team to have to be familiar with manual memory management, you shouldn't use Rust.
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?"
So, you're right, of course, that the language differences are major, however, I don't think it's unfair to say that Rust's instability is a source of concern if you're planning a long-running project. No one wants to get stuck on a pre-1.0 release for their production system. Go is post 1.0, and has a backwards compatible guarantee, which means the code you wrote last year under 1.0 is guaranteed to compile today under 1.3. That's pretty important. It's not an indictment of Rust... it's just a fact of the place in development where it exists right now. Go was in that place before it hit 1.0, too.
Go has an extremely well-developed library for writing networked clients and servers, and a concurrency model that prioritizes being performant for large numbers of mostly-non-interacting tasks that should yield on blocking (eg network requests, DB access, IO in general).
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.
Yeah, they're really different languages. They're not in competition at all, any more than C++ and Python are competing. They're different tools for different jobs. The only thing Go and Rust have in common is that they're compiled and produce native executables.
It's an inapt comparison and the comparison should not be made naively.
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. :-)
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]
If I was given a mandating hand to develop a reliable and efficient system for most applications to maintain (with funding) over the 5-10 year term, I would be OK with choosing Rust today, with the expectation that we'd have some porting and heavy lifting as things change, possibly even contributing development time to the Rust project.
[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.
Not sure how you come to the conclusion that Go doesn't have type safety.
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.
I was recommended by someone to learn Rust, but without reason. Does anyone have any reasons for why I should look into this, apparently, new language?
Great type system, memory safe, fast. It's like a wonderful mix of Haskell and Erlang to use when you'd otherwise reach for C++ or C.
Of course, I'm quite biased :)
The biggest selling point of Rust is that it allows you to write low-level code with memory safety (so no use-after-free, buffer overruns, Heartbleeds, etc) and without runtime overhead. Right now this is a niche that Rust has to itself, as far as non-academic languages go. It's like having a C++ static analyzer with guaranteed no false negatives built into the language.
You also get nice high-level productivity features like type inference, lightweight closures, a module system, a modern take on interfaces, etc.
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.
They're for fairly different markets. Go is geared to be a much simpler language that attracts people from Python and Ruby. This results in things like a garbage collector, no pointer arithmetic, no generics, etc..
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.)
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.
I agree with your points except to claify my point on compiler's correctness:
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.
One big advantage that Go currently has over Rust is much greater stability, in terms of language and standard library changes.
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.
They're for different applications. If you can't use a runtime or garbage collector, you can't use Go. If you don't want you or your team to have to be familiar with manual memory management, you shouldn't use Rust.
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?"
So, you're right, of course, that the language differences are major, however, I don't think it's unfair to say that Rust's instability is a source of concern if you're planning a long-running project. No one wants to get stuck on a pre-1.0 release for their production system. Go is post 1.0, and has a backwards compatible guarantee, which means the code you wrote last year under 1.0 is guaranteed to compile today under 1.3. That's pretty important. It's not an indictment of Rust... it's just a fact of the place in development where it exists right now. Go was in that place before it hit 1.0, too.
Go has an extremely well-developed library for writing networked clients and servers, and a concurrency model that prioritizes being performant for large numbers of mostly-non-interacting tasks that should yield on blocking (eg network requests, DB access, IO in general).
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.
Yeah, they're really different languages. They're not in competition at all, any more than C++ and Python are competing. They're different tools for different jobs. The only thing Go and Rust have in common is that they're compiled and produce native executables.
It's an inapt comparison and the comparison should not be made naively.
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:
Rust's chief disadvantages are:
If I was given a mandating hand to develop a reliable and efficient system for most applications to maintain (with funding) over the 5-10 year term, I would be OK with choosing Rust today, with the expectation that we'd have some porting and heavy lifting as things change, possibly even contributing development time to the Rust project.
[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.
There are references and then smart pointers, of which owned pointers (~) are one kind.
Not sure how you come to the conclusion that Go doesn't have type safety.
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.