Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Discord is switching from Go to Rust (2020)

discord.com

Post reply on HN
Print view View original

21–30 of 60 posts

Re: Why Discord is switching from Go to Rust (2020)

#21

Post by Xylakant »

whoisburbansky wrote: post #16
mc4ndr3 wrote: post #13

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 a…

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?

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.

Re: Why Discord is switching from Go to Rust (2020)

#22

Post by verdagon »

jatone wrote: post #20
verdagon wrote: post #18

I suspect that GC'd languages could mitigate this problem by introducing regions; separate areas of memory that cannot point at each other. Pony actors [0] have them, and Cone [1] and Vale [2] are trying new things with them. If golang had this, then it might not ever need to run its GC because it could just fire up a new region for every request. The request will likely end and blast away its memory before it needs…

or you know; just pace the GC mark and sweep algorithm. which is what go is doing now.

Correct me if I'm wrong, but IIRC pacing would still cause a latency spike, it would just be a more strategically-timed latency spike.

Re: Why Discord is switching from Go to Rust (2020)

#24

Post by jholman »

ceeplusplus wrote: post #19
jholman wrote: post #17

Earlier quoted context omitted.

I don't understand.... isn't this idea (triggering GC more often) explicitly discussed in the article?

My understanding is they tried to tune the GC percent to make the automatic heuristic do GC sooner, but they didn't allocate enough to have that make a difference. However, Go has a way to manually trigger a GC which they could've set on a timer on a goroutine. If they weren't actually generating that much garbage then pause times should theoretically be pretty short if you're doing a GC every 5 seconds or something…

Okay, I see what you're saying about the timer. That isn't in TFA, agreed.

But I still don't understand, because....

(NB: I'm not a GC expert, just a curious amateur, so my apologies if there are errors in the following, and the opportunity to be corrected in these errors is part of why I'm posting this.)

Regarding the "not much garbage => theoretically times would be shorter", my understanding is that this is actually not how GC works. The GC time is a function of the size of the GC pool, because GC works by walking ("tracing") the tree of live references. So the only way to make GC faster is to have not less garbage, but less stuff allocated at all.

Multi-generational GC works by dividing the whole pool into smaller pools, so that most GC passes only visit the high-churn nursery, but even then some GC passes need to read the

TFA mentions this, where they say "the spikes were huge not because of a massive amount of ready-to-free memory, but because the garbage collector needed to scan the entire [thing we were keeping track of]".

That is, they had virtually no garbage to collect, and that wasn't speeding up the GC. Which is consistent with how all tracing GC works, as far as I know.

Comments/corrections/clarifications are requested!!

Re: Why Discord is switching from Go to Rust (2020)

#26

Post by bcrl »

mc4ndr3 wrote: post #13

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 a…

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.

Re: Why Discord is switching from Go to Rust (2020)

#27

Post by bsder »

Xylakant wrote: post #21
whoisburbansky wrote: post #16

Earlier quoted context omitted.

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?

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.

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.

Re: Why Discord is switching from Go to Rust (2020)

#28

Post by lillecarl »

bsder wrote: post #27
Xylakant wrote: post #21

Earlier quoted context omitted.

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.

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 languag…

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.

Re: Why Discord is switching from Go to Rust (2020)

#30

Post by steveklabnik »

mc4ndr3 wrote: post #13

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 a…

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