3 ms·
A really important (I think) point with regards to all the comparisons to Go and other similar languages that pop up in every Rust post: Many seem to think tha
by parley 12y ago
A really important (I think) point with regards to all the comparisons to Go and other similar languages that pop up in every Rust post:
Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI.
Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C.
Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher".
My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.
- steveklabnik 12y ago> (I think!) You are correct. The third production deployment of Rust is a Ruby gem written in Rust.
- pcwalton 12y agoBrad Fitzpatrick has suggested in one of his talks that Go is interested in being embeddable as well, so I'm excited to see that. I have no doubt they'll do an awesome job. It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.
- enneff 12y agoNow that "embedded" is being redefined to include ARM processors, we have already seen Go in such contexts. This is a great talk: https://www.youtube.com/watch?v=a4BQRUpQoe8 https://www.youtube.com/watch?v=a4BQRUpQoe8 We'll never see Go on 16-bit architectures or smaller, though.
- cmrx64 12y agoEmbedded and embeddable are different things. Embeddable refers to the ability to call code written in your library from any other environment (and these days, over a C FFI).
- enneff 12y agoProviding Go code as a shared library that is linkable from other languages is not technically infeasible, it is merely difficult. In 1.4 we aim to be able to load Go programs into a host process (on Android this will enable a Go process to live in the same memory space as a Java process), and also have a more general plan for Go shared libraries.
- pjmlp 12y ago> Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. I do bash Go a lot, but it would be possible if the designers took the same approach as Cedar, Oberon and Modula-3. A few GC enabled system programming languages. - Expand the capabilities offered by the unsafe package - Offer more control over the GC behavior - Add a kind of untraced pointer or a GC API for allocating them