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

51–60 of 60 posts

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

#51

Post by Xylakant »

bsder wrote: post #27
Xylakant wrote: post #21

Earlier quoted context omitted.

Rust as a language does not protect against memory leaks - std::mem::forget even explicitly does so. Generally garbage collected languages do, so trading go for rust increases the risk of having memory leaks.

You are invoking std::mem::forget which is explicitly for circumventing destructor execution and then complaining about leaks. Okay. The documentation page for std::mem::forget goes through all the alternatives you should try before resorting to std::mem::forget. Now, perhaps std::mem::forget should be marked unsafe. However, you don't just "accidentally" run std::mem::forget. BTW, one of the problems with GC languag…

I'm not complaining - I'm pointing out that leaking memory is considered "safe" in the rust memory model to the point where there is a safe method in the stdlib to do so.

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

#52

Post by mountainriver »

steveklabnik wrote: post #32
mountainriver wrote: post #31

Earlier quoted context omitted.

They actually would have mitigated it by upgrading their Go version, because the latest release at the time had a fix in the runtime that would have basically solved this. Turns out no one on the team actually looked into issues in the Go repo to see if it was being addressed. Looks like they just wanted to write Rust, which is fine Rust is cool, but let’s not deceive ourselves.

That is not what happened, they did not publish the blog post immediately after the transition, and those changes to the GC did not happen until after the port happened. Some people made assumptions about timeline that were incorrect, and then repeated. The discussion at the time on Reddit [1] mentions this. The general discussion as well talked about if the improvements, which were big in many cases, would have even…

The point is that they could have found the issue and seen that it was about to be released. That would be good engineering, bad engineering is when you don't find the root cause of your problem and see if its being worked on

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

#53

Post by steveklabnik »

mountainriver wrote: post #52
steveklabnik wrote: post #32

Earlier quoted context omitted.

That is not what happened, they did not publish the blog post immediately after the transition, and those changes to the GC did not happen until after the port happened. Some people made assumptions about timeline that were incorrect, and then repeated. The discussion at the time on Reddit [1] mentions this. The general discussion as well talked about if the improvements, which were big in many cases, would have even…

The point is that they could have found the issue and seen that it was about to be released. That would be good engineering, bad engineering is when you don't find the root cause of your problem and see if its being worked on

Good engineering is when you solve the problems you have. Sometimes there are multiple ways to solve a problem. Just because they did not choose the solution (which again, we're only speculating would actually solve the issue here, we don't have proof of that) you prefer does not make it poor engineering.

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

#54

Post by mohanmcgeek »

tbillington wrote: post #43
mohanmcgeek wrote: post #35

Earlier quoted context omitted.

I remember when this article came out, everybody was pointing out the fact that they used a go version that was several releases older. Perhaps if the intent wasn't to convince their managers to let them write it in Rust, they would have tried using the latest Go version at the time?

https://news.ycombinator.com/item?id=31021719

Then why publish it at all?

Not to mention, the article made no effort to establish that it's describing the world 2 years prior to this being written

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

#55

Post by jatone »

jhgg wrote: post #44
abeltensor wrote: post #41

Earlier quoted context omitted.

Hmm, well Go itself has gone through a ton of revisions where the GC saw large improvements. And other languages coming up are experimenting with various types of GCs. Its really up to the use case though. With discord, I imagine a big reason why Rust was considered as an alternative to Go is because they already have a substantial Elixir codebase. Rust and Elixir have a very easy time communicating with one another…

We use Elixir + Rust in a few select places. But the majority of our Rust code is services that are purely written in Rust. We use Rust over Go, not only because of the garbage collection issues, but because it's truly a better language in almost every way (once you learn it!) I will say, Go is much easier to pick up, but in exchange you pay in the long term having a language that actively works against you when you…

all the issues you mention for go literally plague every other language out there except for a very small minority. of which rust is one. its a fair criticism but you're completely disregarding the downside around development speed.

I've used both languages extensively. I like both languages. I still reach for golang first because its faster to develop with simply due to the compile times.

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

#56

Post by pornel »

Xylakant wrote: post #21
whoisburbansky wrote: post #16

Earlier quoted context omitted.

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?

Rust as a language does not protect against memory leaks - std::mem::forget even explicitly does so. Generally garbage collected languages do, so trading go for rust increases the risk of having memory leaks.

Rust is precise with what it guarantees, but don’t take “not an absolute guarantee in every case” as “no guarantee at all”.

Leaking in Rust requires either explicit leaking function call, leaking in C/FFI code, or a type that is 1. recursive 2. refcounted 3. with interior mutability, and 4. a programming error in use of such type. If any of these four conditions aren’t met, it can’t leak.

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

#57

Post by abeltensor »

wut42 wrote: post #49
abeltensor wrote: post #38

Earlier quoted context omitted.

I love Rust elixir Nifs. Gives you the best of both worlds to be honest. Highly fault tolerant code with fast computation. Only downside is that it can't really handle extreme crashes like a native process can.

Erlang/Elixir + Rust is an awesome couple. For the downside you mentioned, depending on the use case, it could be interesting to use Rust as a node: https://github.com/sile/erl_dist

Very nice. Nodes are great if you want a long running system along side your elixir app.

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

#58

Post by SirGiggles »

jhgg wrote: post #11
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, y…

Bit of a late reply, but how does Elixir fit into the overall strategy? Is it still like how it is described in previous engineering blogs where it acts as a kind of orchestrator for guilds?

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

#60

Post by coxley »

jatone wrote: post #55
jhgg wrote: post #44

Earlier quoted context omitted.

We use Elixir + Rust in a few select places. But the majority of our Rust code is services that are purely written in Rust. We use Rust over Go, not only because of the garbage collection issues, but because it's truly a better language in almost every way (once you learn it!) I will say, Go is much easier to pick up, but in exchange you pay in the long term having a language that actively works against you when you…

all the issues you mention for go literally plague every other language out there except for a very small minority. of which rust is one. its a fair criticism but you're completely disregarding the downside around development speed. I've used both languages extensively. I like both languages. I still reach for golang first because its faster to develop with simply due to the compile times.

+1. Used Go, Python, React, etc extensively for years at Facebook. The massive Go projects were easiest to extend, operate, and on-board people to.

Rust vs Go discussions are pretty silly. More folks should think of Rust + Go. There are a lot of glue-services that can take the trade-off of a GC, be magnitudes better than Python, and be maintained by a short-staffed team.

Plus, Rust is still plagued by Python (and others) Async problem — it's easy to accidentally block the event loop. When you have a ton of tiny glue services, esp. if one has a lot of contributors / internal libs, it's an easy mistake. Critical path things are worth the attention to detail. Others... ¯\_(ツ)_/¯

Post reply on HN