IIUC, the fundamental difference between Go and Rust is that both make multi-threading a core feature of the language, but Go threads are shared-everything and Rust threads are shared-nothing. (Or very roughly in C terms, Go threads act like pthreads, and Rust threads act like fork.) Go encourages you not to program in a style where your threads stomp on each other's data-structures willy-nilly, but there's no protection built into the language itself. OTOH, AFAICT Rust doesn't even *have* mutexes, because it has safer ways to share state.
Personally this difference is enough to pretty much rule out Go as an option so long as Rust ends up being viable at all, no matter what other clever syntax and type systems and stuff they have... but of course YMMV.
> Rust also disallows null pointers, which I personally do not agree with. Maybe it's my background as a C programmer, but I like having a special value to represent "none." I always find myself using clunky workarounds to emulate NULL
I don't remember the details, but I'm pretty sure it's easy and idiomatic in Rust to define a "maybe<X>" type: a value which is either "none" or else has a real pointer-to-X in it. The trick is that unlike C, now you *can't* dereference such a pointer without checking for NULL-ness when "unpacking" it. This might seem like a burden, but of course it only applies to those pointers which *might* be NULL, which are exactly the ones that you have to check. So they're not trying to make this clunky; basically it's just like C, except now the compiler will keep track of when you need to check for NULL and when you don't. Boom, no more segfaults.
> Rust has this concept of "typestate," which is kind of like the Linux kernel's BUILD_BUG_ON or Boost's static_assert
Typestates are *substantially* more powerful than BUILD_BUG_ON, because typestates make compile-time assertions about program flow. A simple example of a typestate assertion would be "strings which come from the network and then later end up being passed to the filesystem *must* go through the utf8 sanitizer at some point in between". If you accidentally add a code path that violates this invariant, the compiler will tell you.
Generally a lot of things in Rust are designed around the idea a good language should help you write correct code.
(Disclaimer: Graydon's a friend, and I reviewed an early version of the Rust spec, but I haven't been involved or followed the project much since.)
Posted Mar 20, 2012 19:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
To be fair, shared-everything concurrency can be much more efficient than shared-nothing message passing in certain tasks (just look at those RCU articles!).
So I'd certainly like at least some controllable amount of sharing with explicit locking. But message-passing seems to be much easier to write for.
Van Rossum: Python is not too slow (InfoWorld)
Posted Mar 20, 2012 20:10 UTC (Tue) by njs (guest, #40338)
[Link]
RCU doesn't imply shared-everything, just shared-a-few-things-under-very-carefully-controlled-conditions :-). There's nothing stopping them from adding an experts-only, carefully-bounded escape hatch in the standard library. Or from using RCU under the covers to implement something with those semantics -- Rust doesn't literally use 'fork', language runtimes can be very tricky about how they implement things. OTOH you can't add memory isolation in a library :-).
But yeah, it's possible that in some situations, code in Rust will be slower than the best possible concurrent implementation that exploits details of the CPU's cache coherency model etc. For me this is a totally acceptable trade-off, but again YMMV.
(Anyway, it doesn't look like Go has any primitive memory barrier operations, so your only safe concurrency options there are mutexes and channel sends. No RCU.)
Van Rossum: Python is not too slow (InfoWorld)
Posted Mar 21, 2012 16:36 UTC (Wed) by cmccabe (guest, #60281)
[Link]
Golang has atomic operations, which imply memory barriers, and also pointers. See http://golang.org/pkg/sync/atomic/ This is something that actually exists now, not just in theory.
As far as I can see, you should be able to use the CompareAndSwapUintptr operation to get the update-side memory barrier you need for RCU. Then you should be able to have reader threads read the pointer value normally, without a memory barrier, and get whatever they get.
In Go, you have garbage collection, so you can forget all about fooling with grace periods and so forth. Just update the pointer.
Van Rossum: Python is not too slow (InfoWorld)
Posted Mar 21, 2012 16:53 UTC (Wed) by khim (subscriber, #9252)
[Link]
In Go, you have garbage collection, so you can forget all about fooling with grace periods and so forth. Just update the pointer.
Not exactly. Quite often things like RCU are used for performance-critical tasks. The fact that language is built around GC means that now you not only need to worry about grace periods but you must convince GC to [roughly] obey them.
YMMV: in some cases it may all “just work”, in some other cases you'll spend huge amount of time taming GC (and then everything will break once GC will be changed in your implementation).
In fact non-optional GC is my biggest gripe with go.
Van Rossum: Python is not too slow (InfoWorld)
Posted Mar 21, 2012 17:05 UTC (Wed) by njs (guest, #40338)
[Link]