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

291–300 of 670 posts

Re: Why Discord is switching from Go to Rust

#291

Post by topspin »

ascv wrote: post #111
kardianos wrote: post #23

I'm glad they found a good solution (rust) to solve their problem! Also note this was with Go1.9. I know GC work was ongoing during that time, I wonder if this time of situation would still happen?

It's surprising they didn't test upgrading to 1.13.

> It's surprising they didn't test upgrading to 1.13.

It isn't surprising to me. It's stated elsewhere they tried 4 difference version of Go, up through 1.10 apparently, and had performance problems with all of them. At some point you can't suffer garbage collector nonsense anymore and since they'd already employed Rust on other services they tried it here.

It worked on the first try.

That's not surprising either.

What would be surprising is if any of these "but version such and such is Waaay better and they should just use that" actually panned out. The best case would be that the issue just manifests as some other garbage collector related performance problem. That's the deal you sign up for when you saddle yourself with a garbage collector.

Re: Why Discord is switching from Go to Rust

#292

Post by dfee »

The one problem I’m curious as to how channel-based chat applications solve, to which my google-fu has never lead me in the right direction: how do you handle subscriptions?

I imagine a bunch of front end servers managing open web sockets connections, and also proving filtering/routing of newly published messages. Alas, it’s probably best categorized as a multicast-to-server, multicast-to-user problem.

Anyways, if there’s an elegant solution to this problem, would love to learn more.

Re: Why Discord is switching from Go to Rust

#293

Post by iknowstuff »

falcolas wrote: post #260
masklinn wrote: post #231

Earlier quoted context omitted.

Given it's a cache the entries would not have an existing natural owner… except for the cache itself. There would be no need for a GC to traverse the entire map, but that's because rust doesn't use a GC.

While Rust does not have a discrete runtime GC process, it does utilize reference counting for dynamic memory cleanup. So you could argue that they are still going to suffer some of the downsides of a GC'ed memory allocation. Some potential issues include non-deterministic object lifespan, and ensuring that any unsafe code they write which interacts with the cache does the "right thing" with the reference counts (pot…

I think you're confusing Rust's ownership model with Swift's ARC. Rust doesn't do reference counting unless you use Rc or Arc.

Re: Why Discord is switching from Go to Rust

#294

Post by tsimionescu »

the-alchemist wrote: post #96

Looks like the big challenge is managing a large, LRU cache, which tends to be a difficult problem for GC runtimes. I bet the JVM, with its myriad tunable GC algorithms, would perform better, especially Shenandoah and, of course, the Azul C4. The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1]. I can't speak for how their Rust cache manages memory, but the thing to…

> I can't speak for how their Rust cache manages memory, but the thing to be careful of in non-GC runtimes (especially non-copying GC) is memory fragmentation.

As far as I know, a mark-and-sweep collector like Go's doesn't have any advantage over malloc/free when it comes to memory fragmentation. Am I missing some way in which Go's GC helps with fragmentation?

Re: Why Discord is switching from Go to Rust

#295

Post by _qwfv »

dfee wrote: post #292

The one problem I’m curious as to how channel-based chat applications solve, to which my google-fu has never lead me in the right direction: how do you handle subscriptions? I imagine a bunch of front end servers managing open web sockets connections, and also proving filtering/routing of newly published messages. Alas, it’s probably best categorized as a multicast-to-server, multicast-to-user problem. Anyways, if th…

Not sure if this is exactly what you are looking for, but I'd do some digging into consistent hash rings.

Re: Why Discord is switching from Go to Rust

#296

Post by bsder »

dnautics wrote: post #277
kikimora wrote: post #216

Earlier quoted context omitted.

Long GC pauses caused by large collections/caches are decade long problem with no real wide spread solution so far. With Java and .NET you can resort to off-heap data. Not sure if this is possible with Go.

Erlang's basically solved it (and, arguably, solved it decades ago); relevant as discord uses erlang VM in places.

Erlang "solved" the problem by breaking having lots of little heaps so a GC can blast through the entire heap extremely quickly.

Would that actually work in this instance? It seems like that LRU cache they're talking about is kind of large.

Re: Why Discord is switching from Go to Rust

#297

Post by [deleted] »

hinkley wrote: post #224
jasondclinton wrote: post #214

Earlier quoted context omitted.

Finding out if that does resolve the author's issue would be interesting but I'm not sure that that would be particularly supportive data in favor of Go. If anything it would reinforce the downsides of Go's GC implementation: prone sudden pitfalls only avoidable with obtuse, error-prone fiddling that makes the code more complex. After spending weeks fighting with Java's GC tuning for a similar production service tail…

The common factor in most of my decisions to look for a new job has been realizing that I feel like a very highly compensated janitor instead of a developer. Once I spend even the plurality of my time cleaning up messes instead of doing something new (and there are ways to do both), then all the life is sucked out of me and I just have to escape. Telling me that I have to keep using a tool with known issues that we h…

[deleted]

Re: Why Discord is switching from Go to Rust

#298

Post by vogre »

kerkeslager wrote: post #158
_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.

> 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. Well, sure, because categorizing languages as "valid/invalid" doesn't make any sense. But it does show yet another example of how designing a language to solve Google's fairly-unique problems doesn't result in a general-purpose language suitable for solving most people's problems.

Keeping LRU cache that large with these performance requirements is not a "most people's problem".

Go is actually great to solve most people's problem with web servers, while Rust is better for edge cases.

Re: Why Discord is switching from Go to Rust

#300

Post by winrid »

stingraycharles wrote: post #275
the-alchemist wrote: post #96

Looks like the big challenge is managing a large, LRU cache, which tends to be a difficult problem for GC runtimes. I bet the JVM, with its myriad tunable GC algorithms, would perform better, especially Shenandoah and, of course, the Azul C4. The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1]. I can't speak for how their Rust cache manages memory, but the thing to…

> The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1]. For those who care, I was interested how off-heap caching works in Java and I did some quick searching around the Apache Ignite code. The meat is here: - GridUnsafeMemory, an implementation of access to entries allocated off-heap. This appears to implement some common Ignite interface, and invokes calls to a “G…

The idea is that that call is still less expensive than going over the wire and MUCH less expensive than having the GC go through that heap now and then.
Post reply on HN