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

Why Discord is switching from Go to Rust

blog.discordapp.com

Post reply on HN
Print view View original

191–200 of 670 posts

Re: Why Discord is switching from Go to Rust

#191

Post by firethief »

mrpotato wrote: post #88
Nyra wrote: post #50

Earlier quoted context omitted.

Funnily enough, something similar happened at Twitch regarding their API front end written in Go: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

Interesting, they went a totally different route. > The ballast in our application is a large allocation of memory that provides stability to the heap. > As noted earlier, the GC will trigger every time the heap size doubles. The heap size is the total size of allocations on the heap. Therefore, if a ballast of 10 GiB is allocated, the next GC will only trigger when the heap size grows to 20 GiB. At that point, there…

Wow, that puts Discord's "absurd hack" into perspective! I feel like the moral here is a corollary to that law where people will depend on any observable behavior of the implementation: people will use any available means to tune important performance parameters; so you might as well expose an API directly, because doing so actually results in less dependence on your implementation details than if people resort to ceremonial magic.

Re: Why Discord is switching from Go to Rust

#192

Post by Thaxll »

Really interesting post, however they're using a 2+years old runtime, Go 1.9.2 was released 2017/10/25 why did they not even try Go 1.13?

For me the interesting part is that their new implementation in Rust with a new data structure is less than 2x faster than an implementation in Go using a 2+years old runtime.

It shows how fast Go is vs an very optimized language + new data structure with no GC.

Overall I'm pretty sure there was a way to make the spikes go away.

Still great post.

Re: Why Discord is switching from Go to Rust

#193

Post by kllrnohj »

erik_seaberg wrote: post #39
ericflo wrote: post #34

Earlier quoted context omitted.

It comes from a desire to run in the exact opposite direction as the JVM, which has options for every conceivable parameter. Go has gone through a lot of effort to keep the number of configurable GC parameters to 1.

Anyone who pushes the limits of a machine needs tuning options. If you can't turn knobs you have to keep rewriting code until you happen to get the same effect.

Tuning options don't work well with diverse libraries, though. If you use 2 libraries and they both are designed to run with radically different tuning options what do you do? Some bad compromise? Make one the winner and one the loser? The best you can do is do an extensive monitoring & tuning experiment, but that's quite involved as well and still won't get you the maximum performance of each library, either.

At least with code hacking around the GC's behavior that code ends up being portable across the ecosystem.

There doesn't seem to really be a good option here either way. This amount of tuning-by-brute-force (either by knobs or by code re-writes) seems to just be the cost of using a GC.

Re: Why Discord is switching from Go to Rust

#194

Post by afranchuk »

cesarb wrote: post #156
afranchuk wrote: post #35

Earlier quoted context omitted.

A BTreeMap should typically have O(n) memory usage, whereas a HashMap (depending on load factor) will usually have O(kn) memory usage, where k > 1. This is because a HashMap allocates the table into which it will store hashed values upfront (and when the load is too great), so it can't anticipate how many values may be added nor what sorts of collisions may occur at this time. Yes, collisions are typically stored as…

> collisions are typically stored as some allocate-per-item collection Rust's HashMap stores the collisions in the same table as the non-collisions (open addressing), not in a separate collection.

This is true, thanks for the specifics. I was answering the question from a more generic perspective, but failed to mention that many implementations rehash on collision...

Re: Why Discord is switching from Go to Rust

#195

Post by dilyevsky »

kerkeslager wrote: post #169
dilyevsky wrote: post #105

Earlier quoted context omitted.

LOL that should’ve been at the top. The improvement in gc between 1.9 and 1.12 is absolutely massive. They could’ve just upgraded go toolchain.

The GC changes in 1.12 supposedly target large heaps, which is not Discord's situation.

This post needed a lot more depth to really understand what was going on. Statements like

> During garbage collection, Go has to do a lot of work to determine what memory is free, which can slow the program down.

read like blogospam to me (which it is).

For comparison sake - similar post from Twitch has a lot more technical detail and generally makes me view their team in a lot better light than Dicord’s after reading both.

Re: Why Discord is switching from Go to Rust

#196

Post by crystaldev »

jhgg wrote: post #67
mangatmodi wrote: post #52

Why would they switch to rust, rather than upgrading from 3 years old version?

This blog post perhaps is a bit "after the fact" we had made the switch over mid 2019, and wanted to try out rust as well for services like this, due to adoption elsewhere in the company. Also, after upgrading between 4 golang versions on this service and noticing it didn't materially change performance, we decided to just spend our time on the rewrite (for fun, and latency) and to get a head start into the asynchron…

> to get a head start into the asynchronous rust ecosystem.

Sounds resume-driven.

Re: Why Discord is switching from Go to Rust

#197

Post by _ph_ »

calcifer wrote: post #168
_ph_ wrote: post #87

Earlier quoted context omitted.

With recent Go releases, GC pauses have become neglible for most applications. So this should not get into your way. However, it can easily tweaked, if needed. There is runtime.ForceGCPeriod, which is a pointer to the forcegcperiod variable. A Go program, which really needs to change this, can do it, but most programs shouldn't require this. Also, it is almost trivial to edit the Go sources (they are included in the…

> especially, as Go is implemented in Go. Well, parts of it. You can't implement "make" or "new" in Go yourself, for example.

You have to distinguish between the features available to a Go program as the user writes it and the implementation of the language. The immplementation is completely written in Go (plus a bit of low-level assembly). Even if the internals of e.g. the GC are not visible to a Go program, the GC itself is implemented in Go and thus easily readeable and hackeable for experienced Go programmers. And you can quickly rebuild the whole Go stack.

Re: Why Discord is switching from Go to Rust

#198

Post by faitswulff »

deweller wrote: post #179
chc wrote: post #140

Earlier quoted context omitted.

Why would you want to bring up the Actix author's drama? That doesn't seem like something that should reflect on a language one way or the other.

As an outsider to both the Go and Rust cultures, I read the Actix news and walked away with the impression that the Rust ecosystem is less mature.

Every community has it. The dep vs. vgo drama gave me the same impression of Go at the time: https://news.ycombinator.com/item?id=17063724

Re: Why Discord is switching from Go to Rust

#199

Post by _bxg1 »

calcifer wrote: post #178
_bxg1 wrote: post #41

It's always good to see a case-study/anecdote, but nothing in here is surprising. It also doesn't really invalidate Go in any way. Rust is faster than Go. People use Go, like any other technology, when the tradeoffs between developer iteration/throughput/latency/etc. make sense. When those cease to make sense, a hot path gets converted down to something more efficient. This is the natural way of things.

This is a weirdly defensive comment, fighting against a strawman. The article doesn't claim it's surprising, that "invalidates" Go or that it isn't the "natural way of things".

I'm not pushing back against the article, but against the comments that tend to appear below articles like this. The headline in particular, to someone who doesn't read the article, could be taken as "Discord has decided that Rust is better than Go and here's why", and run with.
Post reply on HN