Re:Rust vs. Go
by staticassertion on Wednesday January 18, 2017 @06:23PM
(#13431471)
I think we like to say things like "C has no GC so it's good for kernels, Python has a GC so it's good for blah blah". In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust.
Re:Rust vs. Go
by JoshTriplett on Wednesday January 18, 2017 @07:19PM
(#13431821)
> In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust.
Oh, absolutely; you can certainly write higher-level code in Rust, and it makes for a far more comfortable experience than writing higher-level code in C. I didn't intend to suggest otherwise. And the ongoing futures work helps Rust address several additional areas that Go does well.
However, I don't think it makes sense to group Go and C together, syntax aside. Go cannot replace every use of C, because of its runtime and related expectations. (You can push it into some low-level environments if you make accommodations for its runtime, but you can do the same for languages like Python. You wouldn't necessarily want to do so in production, though.)
Go isn't a replacement for C; you can't use it for many forms of low-level systems programming, because it has a runtime. Go provides a high-performance replacement for things you might otherwise write in Python or similar, and in that capacity it works quite well.
Rust can do anything C can; its capabilities build upwards from bare metal, not downwards from higher-level languages. It intentionally doesn't have a runtime, and its approach to avoiding garbage collection (namely borrow checking) provides safe memory handling without a runtime at the expense of being a novel language feature without analogue in other languages. Much of the learning curve in Rust comes from that.