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

281–290 of 670 posts

Re: Why Discord is switching from Go to Rust

#281

Post by steveklabnik »

ncmncm wrote: post #266
therockhead wrote: post #127

Earlier quoted context omitted.

> By choosing rust you will suffer a great deal of the limitations of it's poor, not production ready, ecosystem. Why do you think that? Seems like Rust is a great choice for this type of high performance work.

Rust does best when the number of lines of code that must be parsed in an edit-compile-test loop is small. When the sources that must be parsed get large, coders suffer. It is doubtful that this will improve, much, without breaking changes to the language. The range of code over which type inference operates, or at least programmers' reliance on it, would need to contract by quite a lot. There would be Complaints.

Type inference only operates within function bodies. It's also not the thing that causes compilation to be slow.

Re: Why Discord is switching from Go to Rust

#282

Post by cmrdporcupine »

kerkeslager wrote: post #112

Go is not a general-purpose language. It's a Google language designed to solve Google's problems. If you aren't Google, you probably have different problems, which Go isn't intended to solve. EDIT: Currently at -4 downvotes. Would downvoters care to discuss their votes?

As a Googler, I don't consider this accurate. I've been here 8 years and have yet to work on a Go code base. Yes, there are projects in Go. Certainly not a majority, nor even a significant minority, honestly.

No, I wouldn't say Go is specific to Google's problems, though I'm sure some of the engineers had them in mind. I see Go used far more outside of Google than in.

Re: Why Discord is switching from Go to Rust

#283

Post by pstuart »

outworlder wrote: post #238
hinkley wrote: post #224

Earlier quoted context omitted.

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…

While I completely agree with the "janitor" sentiment... and for Newton's sake I feel like Wall-E daily... > Telling me that I have to keep using a tool with known issues that we have to process or patches to fix would be super frustrating. All tools have known issues. It's just that some have way more issues than others. And some may hurt more than others. Go has reached an interesting compromise. It has some elegan…

I'll take boring over WTF code any day :-)

Re: Why Discord is switching from Go to Rust

#284

Post by slrz »

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.

And yet, maps and slices are implemented in Go.

https://golang.org/src/runtime/map.go

https://golang.org/src/runtime/slice.go

I don't see why you couldn't do something similar in your own Go code. It just won't be as convenient to use as the compiler wouldn't fill in the type information (element size, suitable hash function, etc.) for you. You'd have to pass that yourself or provide type-specific wrappers invoking the unsafe base implementation. More or less like you would do in C, with some extra care to abide by the rules required for unsafe Go code.

Re: Why Discord is switching from Go to Rust

#285

Post by nicoburns »

pstuart wrote: post #283
outworlder wrote: post #238

Earlier quoted context omitted.

While I completely agree with the "janitor" sentiment... and for Newton's sake I feel like Wall-E daily... > Telling me that I have to keep using a tool with known issues that we have to process or patches to fix would be super frustrating. All tools have known issues. It's just that some have way more issues than others. And some may hurt more than others. Go has reached an interesting compromise. It has some elegan…

I'll take boring over WTF code any day :-)

It's not necessarily an either-or though. I'll take clear, concise expressive code over either!

Re: Why Discord is switching from Go to Rust

#288

Post by tybit »

mperham wrote: post #20

Better title: "One Discord microservice with extremely high traffic is moving to Rust"

Given the rampant misuse of Microservices, this was a really nice read about a seemingly well designed system.

They were able to rewrite their hot spot in a new language without having to rewrite all their business logic in a new language. Not that there wouldn’t have been solutions with a monolith, but this certainly seems elegant and precise.

Re: Why Discord is switching from Go to Rust

#289

Post by nicoburns »

Symmetry wrote: post #202
_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.

I think the way I'd put it is that languages with manual memory management, like Rust, have more scope for optimization than languages that don't. You can just use the gc crate in Rust and have almost the same ease of development but the same performance problems you do in Go.

Notably, it didn't sound like the development in Rust was particularly difficult anyway. That's certainly been my experience in any case.

Re: Why Discord is switching from Go to Rust

#290

Post by novok »

dochtman wrote: post #256
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…

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