5 ms·

How illuminating. From CloudFlare posts, I had been under the impression that Go's gc was incredibly unintrusive, near-real time performance for applications op

How illuminating. From CloudFlare posts, I had been under the impression that Go's gc was incredibly unintrusive, near-real time performance for applications operating in increments of a few hundred milliseconds. For example, CloudFlare uses Go to analyze network traffic. Yes, Rust provides a more predictable, faster memory management model than Go. At the expense of unpredictable, expensive memory leaks triggering application termination. Curious how much time and effort was dedicated to improving gc, which is a useful endeavor in its own right.

whoisburbansky 5y ago
Where do you get that sense that Rust results in memory leaks? Is that just an assumption you’re making about languages without garbage collection, or are there examples you’re aware of Rust applications having to deal with runaway memory consumption?
- Xylakant 5y ago
  Rust as a language does not protect against memory leaks - std::mem::forget even explicitly does so. Generally garbage collected languages do, so trading go for rust increases the risk of having memory leaks.
  - bsder 5y ago
    You are invoking std::mem::forget which is explicitly for circumventing destructor execution and then complaining about leaks. Okay. The documentation page for std::mem::forget goes through all the alternatives you should try before resorting to std::mem::forget. Now, perhaps std::mem::forget should be marked unsafe. However, you don't just "accidentally" run std::mem::forget. BTW, one of the problems with GC languages is the fact that you never know when your destructor might get run (ie. object gets reclaimed) so your GC thinks life is just fine but ... oops ... you just ran out of file descriptors because they are all waiting to be reclaimed.
    - lillecarl 5y ago
      C# has disposable objects (an interface), they require you to call dispose manually, though the "using" syntax makes this automatic once the variable goes out of scope so unless you're passing the object with an FD around you don't really notice it. Though if you miss the using on a disposable object you're leaking, so you need tooling to help you remember. That's how they solve it, C# is my fav language, but it's probably because I've only really spent time in C++ and C#, the rest is just "scripting". So the syntax is familiar.
    - robotnaoborot 5y ago
      Depends on gc implementation. With reference counting it's pretty predictable.
    - afdbcreid 5y ago
      > perhaps std::mem::forget should be marked unsafe It was in the past IIRC. The problem is that there are multiple ways to leak resources in safe Rust (e.g. creating `Rc` cycles), and the compiler cannot prevent them all. So leaking is safe, and because it's also useful sometimes, `std::mem::forget()` and friends (e.g. `Box::leak()`) are also safe. That being said, it is pretty hard to accidentally leak memory.
    - etra0 5y ago
      Doing std::mem::forget is not unsafe as you cannot get any sort of undefined behavior which is what Rust protects you from [0]. Leaking is pretty safe, not always desired but definitely not dangerous like random pointers derefs. But as OP says, leaking accidentally is uncommon. [0] https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
    - Xylakant 5y ago
      I'm not complaining - I'm pointing out that leaking memory is considered "safe" in the rust memory model to the point where there is a safe method in the stdlib to do so.
  - pornel 5y ago
    Rust is precise with what it guarantees, but don’t take “not an absolute guarantee in every case” as “no guarantee at all”. Leaking in Rust requires either explicit leaking function call, leaking in C/FFI code, or a type that is 1. recursive 2. refcounted 3. with interior mutability, and 4. a programming error in use of such type. If any of these four conditions aren’t met, it can’t leak.
bcrl 5y ago
Personally, I prefer the choice of simply using a language that doesn't have GC. No GC, no GC tuning problem. Seems ideal! That said, I've worked on several embedded systems, and the never allocate memory rule that most of them had for runtime was critical to maintaining real-time-like performance. One was written in C++, which meant that we basically couldn't make use of most of the stl and boost. We had to roll our own implementations of plenty of data structures used on the performance critical threads as a result. I couldn't imagine using a language with GC baked in for such a system. But the results spoke for themselves: microsecond level latencies and performance that scaled well with increased CPU core counts.
steveklabnik 5y ago
Cloudflare also uses a significant amount of Rust, in many business-critical places.
abeltensor 5y ago
Hmm, well Go itself has gone through a ton of revisions where the GC saw large improvements. And other languages coming up are experimenting with various types of GCs. Its really up to the use case though. With discord, I imagine a big reason why Rust was considered as an alternative to Go is because they already have a substantial Elixir codebase. Rust and Elixir have a very easy time communicating with one another via Erlang NIFs (native function interfaces). You can embed languages like C/C++/Rust into elixir without much overhead. While I've never personally tried do to such a thing with go, I can't imagine its a smooth experience. You'd probably need to use Ports or CNodes for Go simply for this reason. I love go myself, but one of the biggest turn offs for the language is its FFI support for C and other C connected languages. CGo is a relatively expensive investment when compared to many other comparable alternatives and it should be avoided if possible.
- jhgg 5y ago
  We use Elixir + Rust in a few select places. But the majority of our Rust code is services that are purely written in Rust. We use Rust over Go, not only because of the garbage collection issues, but because it's truly a better language in almost every way (once you learn it!) I will say, Go is much easier to pick up, but in exchange you pay in the long term having a language that actively works against you when you start working on more advanced programs, and a mountain of code that's accumulated over the years that you have to maintain. We work on high concurrency systems here, and I very much enjoy not ever having to think about "is this thing thread safe" because the compiler is checking that for you. I love being able to use the type system to offer my co-workers powerful, but difficult to misuse libraries. I like having sensible abstractions around concurrent execution. Like, for example, if you create a channel in go, and for whatever reason, don't try to read from the channel, or give up (because you're racing a timeout), then the goroutine that tries to write to that channel will block forever and leak. In Rust, if you try to write to a channel where there is no longer a receiver, the write to channel will return an error, which you can then choose to handle, or simply ignore depending on your use-case. Of course, you can be wise and allocate your channels with a capacity of 1, but you can also just completely forget that, and start a steady leak of goroutines for the lifetime of your program that the garbage collector won't save you from! Want to execute many futures with bounded concurrency in Rust and collect the results back into a Vec, but give up if any of the futures fail, or if a timeout is elapsed, and also make sure that all allocated resources are properly dropped and closed in the event that any errors happen? Just combine a futures::stream::StreamExt::{buffer_unordered, collect}, and a tokio::time::timeout, and in a few lines of code you've done it. Want to do the same in Go? Spawn a pool of goroutines I guess, distribute two channels, one for sending them work, one for receiving work, and don't forget to throw in a WaitGroup, pass a context along to all the goroutines, make sure you don't forget any defers, if you are using a shared resource, make sure it's thread safe, or make sure you're locking/unlocking the appropriate mutex, make sure you size your result channel appropriately or you might leak goroutines and any allocations they hold if your main goroutine that's spawned all that work timed out waiting for the results to come in. Is there a library that does all this for you in Go? I googled "golang run many goroutines and collect their results" and looked at the first page of results, and it's basically the above... It is no surprise then that we've picked to use Rust pretty seriously. When you're looking to build reliable systems with serious speeds and massive concurrency, you pick the best tool for the job. That for us is Rust, not Go. And for our real time Distributed systems, we pick Elixir, because BEAM/OTP is just so dang good.
kaba0 5y ago
> At the expense of unpredictable, expensive memory leaks triggering application termination. Rust’s borrow checker does defend against it as well for safe rust, unless you are doing something very stupid, this is just false.

whoisburbansky 5y ago

Where do you get that sense that Rust results in memory leaks? Is that just an assumption you’re making about languages without garbage collection, or are there examples you’re aware of Rust applications having to deal with runaway memory consumption?

Xylakant 5y ago
Rust as a language does not protect against memory leaks - std::mem::forget even explicitly does so. Generally garbage collected languages do, so trading go for rust increases the risk of having memory leaks.
- bsder 5y ago
  You are invoking std::mem::forget which is explicitly for circumventing destructor execution and then complaining about leaks. Okay. The documentation page for std::mem::forget goes through all the alternatives you should try before resorting to std::mem::forget. Now, perhaps std::mem::forget should be marked unsafe. However, you don't just "accidentally" run std::mem::forget. BTW, one of the problems with GC languages is the fact that you never know when your destructor might get run (ie. object gets reclaimed) so your GC thinks life is just fine but ... oops ... you just ran out of file descriptors because they are all waiting to be reclaimed.
  - lillecarl 5y ago
    C# has disposable objects (an interface), they require you to call dispose manually, though the "using" syntax makes this automatic once the variable goes out of scope so unless you're passing the object with an FD around you don't really notice it. Though if you miss the using on a disposable object you're leaking, so you need tooling to help you remember. That's how they solve it, C# is my fav language, but it's probably because I've only really spent time in C++ and C#, the rest is just "scripting". So the syntax is familiar.
  - robotnaoborot 5y ago
    Depends on gc implementation. With reference counting it's pretty predictable.
  - afdbcreid 5y ago
    > perhaps std::mem::forget should be marked unsafe It was in the past IIRC. The problem is that there are multiple ways to leak resources in safe Rust (e.g. creating `Rc` cycles), and the compiler cannot prevent them all. So leaking is safe, and because it's also useful sometimes, `std::mem::forget()` and friends (e.g. `Box::leak()`) are also safe. That being said, it is pretty hard to accidentally leak memory.
  - etra0 5y ago
    Doing std::mem::forget is not unsafe as you cannot get any sort of undefined behavior which is what Rust protects you from [0]. Leaking is pretty safe, not always desired but definitely not dangerous like random pointers derefs. But as OP says, leaking accidentally is uncommon. [0] https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
  - Xylakant 5y ago
    I'm not complaining - I'm pointing out that leaking memory is considered "safe" in the rust memory model to the point where there is a safe method in the stdlib to do so.
- pornel 5y ago
  Rust is precise with what it guarantees, but don’t take “not an absolute guarantee in every case” as “no guarantee at all”. Leaking in Rust requires either explicit leaking function call, leaking in C/FFI code, or a type that is 1. recursive 2. refcounted 3. with interior mutability, and 4. a programming error in use of such type. If any of these four conditions aren’t met, it can’t leak.

bcrl 5y ago

Personally, I prefer the choice of simply using a language that doesn't have GC. No GC, no GC tuning problem. Seems ideal! That said, I've worked on several embedded systems, and the never allocate memory rule that most of them had for runtime was critical to maintaining real-time-like performance. One was written in C++, which meant that we basically couldn't make use of most of the stl and boost. We had to roll our own implementations of plenty of data structures used on the performance critical threads as a result. I couldn't imagine using a language with GC baked in for such a system. But the results spoke for themselves: microsecond level latencies and performance that scaled well with increased CPU core counts.

steveklabnik 5y ago

Cloudflare also uses a significant amount of Rust, in many business-critical places.

abeltensor 5y ago

Hmm, well Go itself has gone through a ton of revisions where the GC saw large improvements. And other languages coming up are experimenting with various types of GCs. Its really up to the use case though. With discord, I imagine a big reason why Rust was considered as an alternative to Go is because they already have a substantial Elixir codebase. Rust and Elixir have a very easy time communicating with one another via Erlang NIFs (native function interfaces). You can embed languages like C/C++/Rust into elixir without much overhead. While I've never personally tried do to such a thing with go, I can't imagine its a smooth experience. You'd probably need to use Ports or CNodes for Go simply for this reason. I love go myself, but one of the biggest turn offs for the language is its FFI support for C and other C connected languages. CGo is a relatively expensive investment when compared to many other comparable alternatives and it should be avoided if possible.

jhgg 5y ago
We use Elixir + Rust in a few select places. But the majority of our Rust code is services that are purely written in Rust. We use Rust over Go, not only because of the garbage collection issues, but because it's truly a better language in almost every way (once you learn it!) I will say, Go is much easier to pick up, but in exchange you pay in the long term having a language that actively works against you when you start working on more advanced programs, and a mountain of code that's accumulated over the years that you have to maintain. We work on high concurrency systems here, and I very much enjoy not ever having to think about "is this thing thread safe" because the compiler is checking that for you. I love being able to use the type system to offer my co-workers powerful, but difficult to misuse libraries. I like having sensible abstractions around concurrent execution. Like, for example, if you create a channel in go, and for whatever reason, don't try to read from the channel, or give up (because you're racing a timeout), then the goroutine that tries to write to that channel will block forever and leak. In Rust, if you try to write to a channel where there is no longer a receiver, the write to channel will return an error, which you can then choose to handle, or simply ignore depending on your use-case. Of course, you can be wise and allocate your channels with a capacity of 1, but you can also just completely forget that, and start a steady leak of goroutines for the lifetime of your program that the garbage collector won't save you from! Want to execute many futures with bounded concurrency in Rust and collect the results back into a Vec, but give up if any of the futures fail, or if a timeout is elapsed, and also make sure that all allocated resources are properly dropped and closed in the event that any errors happen? Just combine a futures::stream::StreamExt::{buffer_unordered, collect}, and a tokio::time::timeout, and in a few lines of code you've done it. Want to do the same in Go? Spawn a pool of goroutines I guess, distribute two channels, one for sending them work, one for receiving work, and don't forget to throw in a WaitGroup, pass a context along to all the goroutines, make sure you don't forget any defers, if you are using a shared resource, make sure it's thread safe, or make sure you're locking/unlocking the appropriate mutex, make sure you size your result channel appropriately or you might leak goroutines and any allocations they hold if your main goroutine that's spawned all that work timed out waiting for the results to come in. Is there a library that does all this for you in Go? I googled "golang run many goroutines and collect their results" and looked at the first page of results, and it's basically the above... It is no surprise then that we've picked to use Rust pretty seriously. When you're looking to build reliable systems with serious speeds and massive concurrency, you pick the best tool for the job. That for us is Rust, not Go. And for our real time Distributed systems, we pick Elixir, because BEAM/OTP is just so dang good.

kaba0 5y ago

> At the expense of unpredictable, expensive memory leaks triggering application termination. Rust’s borrow checker does defend against it as well for safe rust, unless you are doing something very stupid, this is just false.