31–40 of 201 posts
Overall it looks good. When I look at this : "Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money." I see a little bit of haste towards p…
Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs wi…
It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither…
GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management.
Compile times in Go are a fraction of Rust compile times, which is another productivity boost.
Go gives you one good way to do concurrency, Rust believes in tyranny of choice.
Without mentioning that you don't paint the whole picture, just the parts that are favorable to Rust.
> Rust should integrate easily with C++ code The day that Rust manages to have always up to date Qt bindings that do not force you to make compromises compared to the C++ API, I think the C++ support will be at a comfortable level. Right now there are fresh efforts in the Rust and Haskell camps to solve this cleanly in a modern way. It would certainly help if the consumption of C++ APIs via llvm (which is used a lot…
Earlier quoted context omitted.
It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither…
It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…
Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.
Earlier quoted context omitted.
It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither…
It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…
> Rust should integrate easily with C++ code The day that Rust manages to have always up to date Qt bindings that do not force you to make compromises compared to the C++ API, I think the C++ support will be at a comfortable level. Right now there are fresh efforts in the Rust and Haskell camps to solve this cleanly in a modern way. It would certainly help if the consumption of C++ APIs via llvm (which is used a lot…
I'm ignorant of Rusts ABI/requirements, but can the C ABI be used as a lingua franca, or are there necessary facilities that are unsupportable there?
Earlier quoted context omitted.
It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…
I would offer a counterpoint -- Rust's guarantees and strong typing offer a different kind of productivity to an intermediate or experienced user. One where a compiled program is much more likely to be "correct" than in any other mainstream-esque language I've used. The properties which combine to create this effect make refactoring much less scary, allow easier navigation in large codebases (IMO), and allow for othe…
Focus on high-performance servers, async I/O, C integration is very promising. These are Go's weak points, could become a good alternative and a direct competition for Go.
Care to elaborate on Go having weak async I/O support?
Overall it looks good. When I look at this : "Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money." I see a little bit of haste towards p…
I've updated the RFC to clarify this; thanks for the comment!
Earlier quoted context omitted.
It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither…
It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…
Here's where I would agree with you:
- Go makes it harder for someone to write overly abstract code (a common affliction!).
- Being able to occasionally do type assertions in an ergonomic way is surprisingly nice.
- I wish Rust had something in the stdlib like net/http.
- I like that go fmt is so unconfigurable and canonical.
Here's where I would disagree:
- I find ADTs (Rust's enums) super helpful for productivity.
- Removing nil pointer derefs is wonderful, particularly for refactoring.
- I spend too much time in Go rewriting bits of code that I would just use generics for in Rust or C++. Rust's iterators are wonderful and I end up using them over and over again.
- Maybe it's my C background, but I like being able to occasionally use macros. Even for tests it makes things much more readable.
- The borrow checker ends up moving many concurrency issues from runtime debugging to compile time debugging.
- I think cargo is more pleasant to use to manage code than using go + godeps/glide/etc.