5 ms·

Zero experience with Rust beyond watching tutorials and talks, please please correct me if Im wrong. Rust has one killer feature that Go does not have: the typ

Zero experience with Rust beyond watching tutorials and talks, please please correct me if Im wrong. Rust has one killer feature that Go does not have: the typesystem has semantics for memory sharing. You can declare how a pointer can be used: is it accessed concurrently, is it local to me, &c. This helps the typesystem detect race conditions where two threads access a block of memory in an unsafe way. Go does not have this. In Go, you "share memory by communicating", instead of "communicating by sharing memory." But if you do want to share memory, you are back to using locks and your own conventions and mechanics to prevent concurrent access. The language doesn't help you. So it's a different programming paradigm. And if you use Go like you would use Rust (memory sharing), then Go is less safe. (...right?) EDIT: This sounds one-sided, but I'm only talking about sharing memory, here. If you don't do that, and stick to communicating, then Go can blow you away. I don't know how Rust deals with coroutines, but Go has super light threads (goroutines) that make concurrent behavior pure joy. All your threads can so easily talk to eachother, and wait for eachother, and it's all so light and native and good! E.g. you have a handler for a POST, but you only want to close the connection when another thread has finished doing something. And you don't want to tie up an entire OS thread, because it could take a while and that's just too expensive. In go: super easy, just do a blocking channel read. In another language? Wow, where would I start... (How does rust do that?)

slimsag 12y ago
Using a plain-old mutex in Go isn't encouraged. As you said, the memory model is _share by communicating_. Sometimes, yes, using a mutex makes more sense -- and that does introduce the possibility of a data race. If you follow effective Go code -- I imagine the code is on average about just as safe as Rust code is. It is partially comparable to using `unsafe` blocks in Rust -- don't do it, unless you know what you're doing. Stick with channels.
- nothrabannosir 12y ago
  Example from personal experience: I'm working on an audio app right now, and I have high bandwidth, low latency data. I'm CPU bound, allocations and the GC are my enemy. It's just not feasible to constantly copy those buffers around. :( Don't take this the wrong way, I'm not complaining about Go. Just know that sometimes, there are real reasons to share memory. And when you do: Rust has got your back, but in Go you're on your own.
  - giovannibajo1 12y ago
    Not sure what you mean; channels don't force you to copy buffers, you can simply pass the pointer/slice through the channel, but the point is that the paradigm encourages you to pass the ownership of that buffer through the channel.
    - Animats 12y ago
      "the paradigm encourages you to pass the ownership of that buffer through the channel." Rust transfers ownership when you send a single-owner reference over a channel. The sender can no longer access the referenced object; the compiler prevents that. That's the safe way to do it. This is a significant advance in multi-thread programming. The rules that make this work are strikingly simple. Somebody should have thought of this 20 or 30 years ago, but as far as I know, nobody did. Rust pushes the single-owner model hard, and it seems to work. The C++ crowd beat their head against the wall on this for decades, through three generations of auto_ptr, then unique_ptr. Really getting it right requires something like the Rust borrow checker, which C++ does not have. Go does not do anything to prevent sharing data between threads. It's very easy in Go to unwittingly create shared data, because slices are references. After you've sent a reference, the sender still has access to the shared data, as does the receiver, so there's a potential race condition. Go does nothing to prevent this. There's a lot of dancing around this issue in "(In)effective Go", and long discussions of "is this a race condition" in Go forums. Go is a useful language, but it's in spite of Go's concurrency system, not because of it.
    - rdtsc 12y ago
      Not sure there is a great advantage for that use case than from using C/C++ with threads and lockless queue of some sort.
  - slimsag 12y ago
    Why can't you transfer buffers as []byte or []float32 etc to another goroutine over a channel? Hint: that doesn't copy the buffer, it just transfers "ownership" of it.
    - 12y ago
- steveklabnik 12y ago
  While channels are awesome, and are a good pattern, what's important about Rust is that it lets you do channels, but if you need to share mutable memory for some reason, Rust still has your back in that use-case. We can guarantee no data races, even with shared mutable memory, at compile time. It's pretty huge. That said, channels in Rust are also nice to use, and you shouldn't not choose channels. Rust just enables other use-cases too.
- azth 12y ago
  > I imagine the code is on average about just as safe as Rust code is. The same claim can be made for C++ (with uniqe_ptr<T>), but we know how that faired. It is telling enough that there is a race detector tool for Go.
  - Veedrac 12y ago
    Not really; Go is GC'd. C++ isn't memory safe.
    - rdtsc 12y ago
      Using unique_ptr correctly is memory safe. For example: std::unique_ptr<int> p(new int(1)); std::unique_ptr<int> q = p; Should fail. You can strong arm it into break but you can also reuse a pointer locally in Go after it was sent over a channel.
      - Veedrac 12y ago
        C++ really isn't memory safe. It's trivial to think of an example: #include <iostream> auto f() { int x = 1; return [&] () { return x; }; } int main(int, char **) { std::cout << f()() << std::endl; } Of course "using <x> correctly" prevents bugs as long as - as C++ does - you define "correctly" as generously as possible. I agree Go isn't totally memory safe, but the level of memory safety is insanely less than in C++. If you want something particularly involving unique_ptr, consider that best practices are to give non-owning sharing as raw pointers: you could say they're safe as long as you use them correctly but again that misses the point. I can also give an example (stolen from a talk) directly involving shared_ptr even when used with traditional "best practices" although I'm sure the best practices will update themselves to include this. In some sense, Rust has been described as merely formalizing and automatically enforcing the best practices that people were already using in C++; it's the formality and automaticity that turns it from a dangerous language to a safe one.
- Rapzid 12y ago
  It's not discouraged.. It's right there in the sync package. You can use channels where it makes sense, you can use RWMutex where it makes sense.
jamii 12y ago
> (How does rust do that?) My first thought would be to attach the connection object to the data the other thread is working on. When it is done it processing your message it drops the whole thing, closing the connection. If you want to hold it open for multiple workers you could make it an Arc<Connection> so it doesn't close until they all drop it.

slimsag 12y ago

Using a plain-old mutex in Go isn't encouraged. As you said, the memory model is _share by communicating_. Sometimes, yes, using a mutex makes more sense -- and that does introduce the possibility of a data race. If you follow effective Go code -- I imagine the code is on average about just as safe as Rust code is. It is partially comparable to using `unsafe` blocks in Rust -- don't do it, unless you know what you're doing. Stick with channels.

nothrabannosir 12y ago
Example from personal experience: I'm working on an audio app right now, and I have high bandwidth, low latency data. I'm CPU bound, allocations and the GC are my enemy. It's just not feasible to constantly copy those buffers around. :( Don't take this the wrong way, I'm not complaining about Go. Just know that sometimes, there are real reasons to share memory. And when you do: Rust has got your back, but in Go you're on your own.
- giovannibajo1 12y ago
  Not sure what you mean; channels don't force you to copy buffers, you can simply pass the pointer/slice through the channel, but the point is that the paradigm encourages you to pass the ownership of that buffer through the channel.
  - Animats 12y ago
    "the paradigm encourages you to pass the ownership of that buffer through the channel." Rust transfers ownership when you send a single-owner reference over a channel. The sender can no longer access the referenced object; the compiler prevents that. That's the safe way to do it. This is a significant advance in multi-thread programming. The rules that make this work are strikingly simple. Somebody should have thought of this 20 or 30 years ago, but as far as I know, nobody did. Rust pushes the single-owner model hard, and it seems to work. The C++ crowd beat their head against the wall on this for decades, through three generations of auto_ptr, then unique_ptr. Really getting it right requires something like the Rust borrow checker, which C++ does not have. Go does not do anything to prevent sharing data between threads. It's very easy in Go to unwittingly create shared data, because slices are references. After you've sent a reference, the sender still has access to the shared data, as does the receiver, so there's a potential race condition. Go does nothing to prevent this. There's a lot of dancing around this issue in "(In)effective Go", and long discussions of "is this a race condition" in Go forums. Go is a useful language, but it's in spite of Go's concurrency system, not because of it.
  - rdtsc 12y ago
    Not sure there is a great advantage for that use case than from using C/C++ with threads and lockless queue of some sort.
- slimsag 12y ago
  Why can't you transfer buffers as []byte or []float32 etc to another goroutine over a channel? Hint: that doesn't copy the buffer, it just transfers "ownership" of it.
  - 12y ago
steveklabnik 12y ago
While channels are awesome, and are a good pattern, what's important about Rust is that it lets you do channels, but if you need to share mutable memory for some reason, Rust still has your back in that use-case. We can guarantee no data races, even with shared mutable memory, at compile time. It's pretty huge. That said, channels in Rust are also nice to use, and you shouldn't not choose channels. Rust just enables other use-cases too.
azth 12y ago
> I imagine the code is on average about just as safe as Rust code is. The same claim can be made for C++ (with uniqe_ptr<T>), but we know how that faired. It is telling enough that there is a race detector tool for Go.
- Veedrac 12y ago
  Not really; Go is GC'd. C++ isn't memory safe.
  - rdtsc 12y ago
    Using unique_ptr correctly is memory safe. For example: std::unique_ptr<int> p(new int(1)); std::unique_ptr<int> q = p; Should fail. You can strong arm it into break but you can also reuse a pointer locally in Go after it was sent over a channel.
    - Veedrac 12y ago
      C++ really isn't memory safe. It's trivial to think of an example: #include <iostream> auto f() { int x = 1; return [&] () { return x; }; } int main(int, char **) { std::cout << f()() << std::endl; } Of course "using <x> correctly" prevents bugs as long as - as C++ does - you define "correctly" as generously as possible. I agree Go isn't totally memory safe, but the level of memory safety is insanely less than in C++. If you want something particularly involving unique_ptr, consider that best practices are to give non-owning sharing as raw pointers: you could say they're safe as long as you use them correctly but again that misses the point. I can also give an example (stolen from a talk) directly involving shared_ptr even when used with traditional "best practices" although I'm sure the best practices will update themselves to include this. In some sense, Rust has been described as merely formalizing and automatically enforcing the best practices that people were already using in C++; it's the formality and automaticity that turns it from a dangerous language to a safe one.
Rapzid 12y ago
It's not discouraged.. It's right there in the sync package. You can use channels where it makes sense, you can use RWMutex where it makes sense.

jamii 12y ago

> (How does rust do that?) My first thought would be to attach the connection object to the data the other thread is working on. When it is done it processing your message it drops the whole thing, closing the connection. If you want to hold it open for multiple workers you could make it an Arc<Connection> so it doesn't close until they all drop it.