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

531–540 of 670 posts

Re: Why Discord is switching from Go to Rust

#531

Post by arcticbull »

giornogiovanna wrote: post #524
chubs wrote: post #307

Earlier quoted context omitted.

I found similarly when I ported an image resizing algorithm from Swift to Rust: I'm experienced in swift thus was able to write in an idiomatic way, and have little Rust experience thus I wrote it in a naive way; yet still the rust algorithm was twice(!) as fast. And swift doesn't even have a GC slowing things down!

Reference counting is a (low-throughput, low-latency) form of garbage collection.

Yes and no. From a theoretical perspective, I suppose that's true, but "garbage collection" tends to mean a non-deterministic collector that does its own thing, and you don't have to think at all about memory. That does not apply to Swift, as of course, you need to understand the difference between strong and weak references. It's unfairly simplistic to couple the two.

Re: Why Discord is switching from Go to Rust

#532

Post by arcticbull »

terminaljunkid wrote: post #455
chubs wrote: post #307

Earlier quoted context omitted.

I found similarly when I ported an image resizing algorithm from Swift to Rust: I'm experienced in swift thus was able to write in an idiomatic way, and have little Rust experience thus I wrote it in a naive way; yet still the rust algorithm was twice(!) as fast. And swift doesn't even have a GC slowing things down!

> Swift doesn't have a GC slowing things down This Apple marketing meme needs to die. Reference counting incurs arguably more cost than GC, or at least the cost is spread through-out processing.

Apple's ARC is not a GC in the classic sense. It doesn't stop the world and mark/sweep all of active memory. It's got "retain" and "release" calls automatically inserted and elided by the compiler to track reference counts at runtime, and when they hit zero, invoke a destructor. That's not even close to what most people think of when they think "gc". Of course it's not free, but it's deterministic.

Re: Why Discord is switching from Go to Rust

#533

Post by latch »

blondin wrote: post #468
latch wrote: post #456

Earlier quoted context omitted.

> Go is purpose-built for writing web services Is this true? Go was built specifically for C++ developers, which, even when Go was first release, was a pretty unpopular language for writing web services (though maybe not at Google?). That a non-trivial number of Ruby/Python/Node developers switched was unexpected. (1) https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

your quote is just corroborating what the reply is saying. go was written for web services which were written in c++ at google.

The linked article doesn't say anything about web services. Just C++. I believe Rob Pike was working on GFS and log management, and Go was always initially pitched at system programming (which is not web services).

> Our target community was ourselves, of course, and the broader systems-programming community inside Google. (1)

(1) http://www.informit.com/articles/article.aspx?p=1623555

Re: Why Discord is switching from Go to Rust

#534

Post by giornogiovanna »

estebank wrote: post #526
dodobirdlord wrote: post #503

Earlier quoted context omitted.

This reminds me of the ongoing saga of RUSTC_BOOTSTRAP[0][1] The stable compiler is permitted to use unstable features in stable builds, but only for compiling the compiler. In essence, there are some Rust features that are supported by the compiler but only permitted to be used by the compiler. Unsurprisingly, various non-compiler users of Rust have decided that they want those features and begun setting the RUSTC_B…

This is not entirely correct. These things that "can only be used by the compiler" are nightly features that haven't been stabilized yet . Some of them might never be stabilized, but you could always use them in a nightly conpiler, stability assurances just fly out the window then. This is also why using that environment variable is highly discouraged: it breaks the stability guarantees of the language and you're eff…

Yep. Beyond that, there is at least one place[0] where the standard library uses undefined behavior "based on its privileged knowledge of rustc internals".

[0]: https://doc.rust-lang.org/src/std/io/mod.rs.html#379

Re: Why Discord is switching from Go to Rust

#535

Post by tonyferguson »

Wow, Rust is amazing, so fast! It is like these people never learnt c? Why did they spend all this time trying to optimise such a high level language? Surely they can afford a more experienced engineer who will tell them that is a path that isn't worth it? I jump straight to c when there is anything like this, although I guess Rust is an option these days.

Re: Why Discord is switching from Go to Rust

#536

Post by _ph_ »

calcifer wrote: post #314
_ph_ wrote: post #197

Earlier quoted context omitted.

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 rebuil…

> You have to distinguish between the features available to a Go program as the user writes it and the implementation of the language. I do, I'm just objecting to "Go is implemented in Go".

But on what basis? What part of Go isn't implemented in Go?

Re: Why Discord is switching from Go to Rust

#537

Post by trevor-e »

arcticbull wrote: post #532
terminaljunkid wrote: post #455

Earlier quoted context omitted.

> Swift doesn't have a GC slowing things down This Apple marketing meme needs to die. Reference counting incurs arguably more cost than GC, or at least the cost is spread through-out processing.

Apple's ARC is not a GC in the classic sense. It doesn't stop the world and mark/sweep all of active memory. It's got "retain" and "release" calls automatically inserted and elided by the compiler to track reference counts at runtime, and when they hit zero, invoke a destructor. That's not even close to what most people think of when they think "gc". Of course it's not free, but it's deterministic.

I think you are being borderline pedantic here. ARC _is_ GC in the classic sense: https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

I agree with you that most people tend to associate GC with something more advanced nowadays, like mark and sweep as you said in another comment, but it seems pointless to argue that ARC is not a form of GC.

Re: Why Discord is switching from Go to Rust

#538

Post by _ph_ »

_ph_ wrote: post #259
jhgg wrote: post #251

Earlier quoted context omitted.

When we investigated, there was no way to change that that we could find - barring compiling go from source (something we could have done, but wanted to avoid.)

Yes, you have to rebuild go, but that is literally done in a minute. It also would be interesting, if you happen to have some conclusive benchmarks, how the latest Go runtime would perform in this sense.

I don't get, why this is downvoted without comments. Compared to a rewrite, this would have been a miniscule change. Furthermore, considering that you wrote that long blog post (which I quite appreciate, as it contains interesting information), it would have been important knowledge, whether the setting of the parameter was the real culprit - and if it was, a good reason to shout out to the Go implementors to look closer at it.

Re: Why Discord is switching from Go to Rust

#539

Post by jayd16 »

sreque wrote: post #381
stingraycharles wrote: post #275

Earlier quoted context omitted.

> 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…

Unsafe lets you manipulate memory without any JNI overhead other than when allocating or de-allocating memory, and that is usually done in larger chunks and pooled to avoid the overhead at steady state. Netty also takes advantage of Unsafe to move a lot of memory operations off the java heap. Unsafe was one of the cooler aspects to Java that Oracle is actively killing for, well, no good reason at least.

C# seems to have a neat middle ground for this kind of stuff with their Span api.

Re: Why Discord is switching from Go to Rust

#540

Post by sophiebits »

jholman wrote: post #505
corford wrote: post #439

Earlier quoted context omitted.

I really wish Intel or MS or someone would fund D so it could give Go and Rust a run for their money. It's as fast (or faster), expressive, powerful and, subjectively, easier to pick up and code in than Rust. It just needs some backers with muscle.

Maybe some big FAANG company. Start at the beginning of the acronym, I guess. I wonder if anyone could persuade anyone at Facebook to do a little bit of D professionally. I bet if even one serious Facebook engineer made a serious effort to use D, its adoption woes would be over.

Facebook is unlikely to move to D at this point and already has multiple serious projects in Rust (that they’re happy about, AFAIK).
Post reply on HN