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

591–600 of 670 posts

Re: Why Discord is switching from Go to Rust

#591

Post by dancemethis1 »

jhgg wrote: post #254
penagwin wrote: post #137

Earlier quoted context omitted.

I feel that it's not really fair to expect them to natively implement their app on every platform and put tons of resources into it's client performance - anecdotally discord is a very responsive app - see [0]. But think of it this way, all the effort they put into their desktop app works on all major OSes without a problem. They even get to reuse most of the code for access from the browser, with no installation req…

A lot of the startup cost right now is in our really ancient update checker. There are plans to rewrite all of this, now that we understand why it's bad, and have some solid ideas as to what we can do better. I do think it's reasonable to get the startup time of Discord to be near what VS Code's startup times are. If we remove the updater, it actually starts pretty fast (chromium boot -> JS loaded from cache) is The…

The thing that's really bad is that it's proprietary.

Re: Why Discord is switching from Go to Rust

#593

Post by calcifer »

_ph_ wrote: post #573
calcifer wrote: post #563

Earlier quoted context omitted.

I gave an example a bit further up, here [1]. [1] https://news.ycombinator.com/item?id=22240223

But this isn't a contradiction to the statement, that Go is implemented in Go. If you look at the sources of the Go implementation, the source code is 99% Go, with a few assembly functions (most for optimizations not performed by the compiler) and no other programming language used.

That's not correct. The implementation of "make", for example, looks like Go but isn't - it relies on internal details of the gc compiler that isn't part of the spec [1]. That's why a Go user can't implement "make" in Go.

[1] https://golang.org/ref/spec

Re: Why Discord is switching from Go to Rust

#594

Post by willvarfar »

This is a bit late to add, but from the description of the problem in the article, the way to make the program faster, irregardless of language, is to use a big array rather than lists and trees. Carve the array up as necessary, so the array of users to offsets in the array where the data is. Basically, be your own memory allocator, with all the loss of safety but the order of magnitude improvement in efficiency that that brings.

Re: Why Discord is switching from Go to Rust

#595

Post by giornogiovanna »

earthboundkid wrote: post #461
cesarb wrote: post #414

Earlier quoted context omitted.

Another interesting comment in the same reddit thread, from /u/brian-discord ( https://old.reddit.com/r/programming/comments/eyuebc/why_dis... ): > Another Discord engineer chiming in here. I worked on trying to fix these spikes on the Go service for a couple weeks. We did indeed try moving up the latest Go at the time (1.10) but this had no effect. > For a more detailed explanation, it helps to understand what is go…

Ugh, linked lists fuck everything up. It’s never the right data structure. Use a vector!

The two main cases when linked lists are better are (a) when you want to guarantee a low cost per insert, since vector insertion is only O(1) amortized, and (b) when you want to insert in the middle, but somehow found that middle without scanning the list.

Anyway, in this case, I guess they're using a free list because (1) it's simpler since you don't need an external collection keeping a list of unused stuff, and (2) reason (a) above.

Re: Why Discord is switching from Go to Rust

#596

Post by Nitramp »

gwbas1c wrote: post #223
rvcdbn wrote: post #157

Seems like you were hitting: runtime: Large maps cause significant GC pauses #9477 [0] Looks like this issue was resolved for maps that don't contain pointers by [1]. From the article, sounds like the map keys were strings (which do contain pointers, so the map would need to be scanned by the GC). If pointers in the map keys and values could be avoided, it would have (if my understanding is correct) removed the need…

Everything I've read indicates that RAM caches work poorly in a GC environment. The problem is that garbage collectors are optimized for applications that mostly have short-lived objects, and a small amount of long-lived objects. Things like large in-RAM LRU are basically the slowest thing for a garbage collector to do, because the mark-and-sweep phase always has to go through the entire cache, and because you're con…

> The problem is that garbage collectors are optimized for applications that mostly have short-lived objects, and a small amount of long-lived objects.

I think it's not quite that.

Applications typically have a much larger old generation than young generation, i.e. many more long lived objects than short lived objects. So GCs do get optimized to process large heaps of old objects quickly and efficiently, e.g. with concurrent mark/sweep.

However as an additional optimization, there is the observation that once an application has reached steady state, most newly allocated objects die young (think: the data associated with processing a single HTTP request or user interaction in a UI).

So as an additional optimization, GCs often split their heap into a young and an old generation, where garbage collecting the young generation earlier/more frequently overall reduces the mount of garbage collection done (and offsets the effort required to move objects around).

In the case of Go though, the programming language allows "internal pointers", i.e. pointers to members of objects. This makes it much harder (or much more costly) to implement a generational, moving garbage collector, so Go does not actually have a young/old generation split nor the additional optimization for young objects.

Re: Why Discord is switching from Go to Rust

#597

Post by _ph_ »

calcifer wrote: post #593
_ph_ wrote: post #573

Earlier quoted context omitted.

But this isn't a contradiction to the statement, that Go is implemented in Go. If you look at the sources of the Go implementation, the source code is 99% Go, with a few assembly functions (most for optimizations not performed by the compiler) and no other programming language used.

That's not correct. The implementation of "make", for example, looks like Go but isn't - it relies on internal details of the gc compiler that isn't part of the spec [1]. That's why a Go user can't implement "make" in Go. [1] https://golang.org/ref/spec

In which language do you think is "make" implemented?

Re: Why Discord is switching from Go to Rust

#598

Post by damnyou »

romaniitedomum wrote: post #480
smabie wrote: post #344

Earlier quoted context omitted.

What would you recommend that doesn’t have a GC? Zig? C? Rust is a fine choice. Besides if you really don’t care, just make the entire program unsafe and you’ll still reap benefits over C or C++.

Whatever language and toolset gets the job done with the least amount of effort. Given the hoops that Discourse had to jump through to get Rust working, that wasn't a good technical decision. They'd have got the same result with less pain with C++.

The costs of any long-lived service are dominated by ongoing maintenance, not the initial work.

Re: Why Discord is switching from Go to Rust

#599

Post by danesparza »

novok wrote: post #290
dochtman wrote: post #256

Earlier quoted context omitted.

One the one hand, yes. On the other hand, all of this sounds much more complex and fragile. This seems like an important point to me: "Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version."

A C app will tend to outperform a Java or Golang app by 3x, so it isn't too surprising.

I call utter bullshit especially when dealing with threads. I think you'll spend so much time debugging pointers, the stack and your memory allocations that switching to a more modern language could save you significant debugging time.

But now I sound like a Geico (insurance) commercial. Sorry about that.

Re: Why Discord is switching from Go to Rust

#600

Post by cft »

toxicafunk wrote: post #583
cft wrote: post #543

Earlier quoted context omitted.

> From a purely architectural perspective, I would try to put cacheable material in something like memcache or redis You cannot use a caching server at that scale with those latency requirements. It has to be embedded

Something like rocksdb ( https://rocksdb.org/ ) then

You cannot use that either, due to I/O block device saturation, even on enterprise PCIe NVMe. Not enough parallel IOPS. Only RAM can be used.
Post reply on HN