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

11–20 of 60 posts

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

#11

Post by jhgg »

phendrenad2 wrote: post #2

(2020) (Anyone know if they're still using Rust?)

Yes we are using rust in a big way. We have multiple teams now full time working on Rust. It is being used on both the client and server, as native modules, web assembly, and also native rust services and NIFs that embed themselves in our elixir services.

It has been an incredible success. I plan to blog more about it in the coming months. Our usage of Rust is continuing to grow, and if you check out our jobs page, you might notice all backend / infra jobs list Rust in them now :)

I think probably 40% of requests are handled directly by rust services now, with the rest involving one or more rust service called from our Python API layer.

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

#12

Post by tedunangst »

eatonphil wrote: post #5
phendrenad2 wrote: post #2

(2020) (Anyone know if they're still using Rust?)

Their blog doesn't list all articles on a single page (so you could ctrl-f) and doesn't have its own search and doesn't have it's own domain (so googleing `site:discord.com rust` returns a mix of Discord communities and blog posts). Makes it pretty hard to find stuff!

HN site listing is also useless because they host the blog on the same domain as everything else.

https://news.ycombinator.com/from?site=discord.com

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

#13

Post by mc4ndr3 »

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.

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

#14

Post by ceeplusplus »

erikbye wrote: post #9

Not discrediting Rust, but I've noticed you rarely hear "we improved performance" by rewriting our implementation using the same language... Although this, too, can yield similar performance improvements.

It does look like with some GC tuning (e.g. manually triggering GC's at a smaller interval than the Go automatic GC threshold) they might've mitigated the spikes, although I don't think they would have gotten the level of perf improvement they did. Golang assembly code IME is not very optimized compared to Rust/C++.

edit: reading comprehension skills are lacking, please see comment below for why I'm wrong

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

#16

Post by whoisburbansky »

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?

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

#17

Post by jholman »

ceeplusplus wrote: post #14
erikbye wrote: post #9

Not discrediting Rust, but I've noticed you rarely hear "we improved performance" by rewriting our implementation using the same language... Although this, too, can yield similar performance improvements.

It does look like with some GC tuning (e.g. manually triggering GC's at a smaller interval than the Go automatic GC threshold) they might've mitigated the spikes, although I don't think they would have gotten the level of perf improvement they did. Golang assembly code IME is not very optimized compared to Rust/C++. edit: reading comprehension skills are lacking, please see comment below for why I'm wrong

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

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

#18

Post by verdagon »

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 to collect, or it could choose to collect only when that particular goroutine/region is blocked.

Extra benefit: if there's an error in one region, we can blast it away and the rest of the program continues!

[0] https://tutorial.ponylang.io/types/actors.html#concurrent

[1] https://cone.jondgoodwin.com/fast.html

[2] https://verdagon.dev/blog/seamless-fearless-structured-concu...

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

#19

Post by ceeplusplus »

jholman wrote: post #17
ceeplusplus wrote: post #14

Earlier quoted context omitted.

It does look like with some GC tuning (e.g. manually triggering GC's at a smaller interval than the Go automatic GC threshold) they might've mitigated the spikes, although I don't think they would have gotten the level of perf improvement they did. Golang assembly code IME is not very optimized compared to Rust/C++. edit: reading comprehension skills are lacking, please see comment below for why I'm wrong

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 like that.

That being said it's not something that 100% is guaranteed to fix the issue so maybe they did test this and just didn't mention it in the blog.

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

#20

Post by jatone »

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.
Post reply on HN