I haven't used Go or Rust but when I compare them I have a gut feeling that I'd be better off with Rust primarily because Go's build tools are not adequate. What do you think about this?
FWIW: I've been coding in Go for a few years now, for me and (perhaps more importantly) the kind of projects I choose to use it for, the build tools have been more than adequate.
As with many things: it ultimately depends on what you're wanting to do, and what your expectations are.
These are the areas I think Go is most suited to, currently — and they've all been a breeze to implement/test/deploy/maintain.
I've been learning Rust over the past months and I don't think the borrow checker stuff is as scary as people make it sound, match is amazing, so are traits, enums, cargo....
But, I can't, for the life of me, wrap my head around Rust's "concurrency" story. Yet.
Go concurrency is as close to trivial as one can get - channels, goroutines, select. That's it. And they compose nicely. I was doing concurrent networking stuff in a matter of days.
Rust has channels, select (kind-of?), but then I discovered it has futures, and something called "mio", and now something called "tokio", also read something about generators and coroutines, saw that C#-like "async/await" stuff is also being worked on, and I'm not sure how these things interact with each other.
I get the .NET async/await story, and always felt it was (good) syntactic sugar on top of "raw" JS-style futures, but how do all of them play with the CSP-style stuff like channels that's in the std. lib already? Is one being deprecated?
I feel in general Go's CSP model is more "powerful" and more "generic" than futures - you can even emulate futures/promises with Go's primitives, but I don't see how you can do what I do in Go with bare futures - "streaming" type stuff is especially hard with the futures' "all-or-nothing" approach.
I think Rust really nailed down the "one-thing-at-a-time" story - the docs, tutorials - all great. But for me it broke down quickly on the "easy concurrency" end - and maybe it's just a question of better tutorials/docs?
Yeah, so this is basically the result of two things:
1. Rust-the-language focused on making concurrency safe, and getting primtives right
2. The higher-level aspects of the story are still shaking out.
The core primitives are very simple: Sync and Send, two traits which let you declare invariants. But most people don't want to be programming with primitives. So there's been a lot of iteration on what a higher-level story looks like. There are a ton of options, and we've been iterating through them to figure it out. The stuff you're seeing is the result of that process, so you're seeing how the sausage is made, which can definitely be confusing. It's all under active work, and then, once the pieces are in place, getting the right docs/tutorials there.
So, yes. Thanks. It's a good reminder. We'll get there :)
One last thing, as a small amount of food for thought:
> I feel in general Go's CSP model is more "powerful" and more "generic" than futures
In some senses, yes, but they also come with tradeoffs, like any technical choice. Specifically, in order to do concurrency this way, you must go with green threads. And green threads lead to smaller stacks, which leads to non-zero cost of calling into C code, which is a drawback that Rust can't sustain. It works great for Go, but can't really work in Rust, generally. I mean, you can do it, yes, but that drawback doesn't work for the majority of our audience.
It's these kinds of tricky, in-the-weeds stuff that makes designs hard and take time.
- Benchmark / profiling are much better ( https://blog.golang.org/profiling-go-programs )
- go fmt / go vet
- go doc
All of that that is supported by default by the Go team on all platforms, meaning it works well and I don't have to worry of using a 3rd party Cargo package.
Compile speed is certainly a thing go is excellent at. Cross-compiling, Rust is almost as good, but not quite yet, working on it!
Benchmark stuff is not yet stable, but for profiling, you don't need a special tool for Rust; all the C and C++ tooling works.
fmt/vet is rustfmt and clippy, which work today, and soon will be distributed with Rust tool.
rustdoc already ships with Rust.
So, my takeaway is mostly, needs some polish and shipping with the compiler. Thanks!
rustfmt (will be coming with rustc soon)
> - go doc
rustdoc (comes with rustc)
It should be distributed along with the rest of the tooling in the coming months!