Live data from Hacker News

Why Discord is switching from Go to Rust

blog.discordapp.com

601–610 of 670 posts

Re: Why Discord is switching from Go to Rust

#601

Earlier quoted context omitted.

There are tradeoffs with all languages. C++ avoids the GC, but you then have to make sure you know how to avoid the common pitfalls of that language. We use C++ at Scylla (saw that we got a shout-out in the blog! Woot!) but it's not like there isn't a whole industry about writing blogs avoiding C++ pitfalls. C++ pitfalls through the years... • https://www.horstmann.com/cpp/pitfalls.html (1997) • https://stackoverflow…

(Discord infra person here.) Actually we didn't update the reference to Cassandra in the article -- the read states workload is now on Scylla too, as of last week. ;) We'll be writing up a blog post on our migration with Scylla at some point in the next few months, but we've been super happy with it. I replaced our TokuMX cluster with it and it's faster, more reliable, _and_ cheaper (including the support contract).…

What a glorious combination of things! What a shame faster, more reliable and cheaper don't usually go together, but that's the challenge all developers face...

Re: Why Discord is switching from Go to Rust

#602

Earlier quoted context omitted.

Some people say this, but I think it's misleading; refcounting can make things live longer, but the borrow checker cannot.

Well, with ownership, a move can make things "live" longer, I guess.

You're not wrong. I just think there's enough difference that the analogy doesn't really work.

Re: Why Discord is switching from Go to Rust

#605

Earlier quoted context omitted.

Landing in a shop that uses N programming languages for N microservices would be a pretty miserable experience.

I've seen quite a few environments, and usually there's only a limited current set of tech the devs are allowed to use, and if that's not the case, I try to enforce this, but this set should evolve depending on the needs. The main issue however is manpower. At my current client, one of the technologies still actively being used for this reason is PHP (which is a horrible fit for microservices for a lot of reasons), b…

I can buy this for Rust but if people have issues picking up Go quickly ...

Re: Why Discord is switching from Go to Rust

#606
post #192

Really interesting post, however they're using a 2+years old runtime, Go 1.9.2 was released 2017/10/25 why did they not even try Go 1.13? For me the interesting part is that their new implementation in Rust with a new data structure is less than 2x faster than an implementation in Go using a 2+years old runtime. It shows how fast Go is vs an very optimized language + new data structure with no GC. Overall I'm pretty…

The graphs were in different units. The final Rust version was over 100x faster.

Which doesn't make any sense. Rust is not x100 faster than Go.

Re: Why Discord is switching from Go to Rust

#607
post #307

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."

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's form of GC is one of the slowest one, no wonder porting to Rust made it faster, specially given that most tracing GC outperform Swift's current implementation.

If one goes with reference counting as GC implementation, then one should take the effort to use hazardous pointers and related optimizations.

Re: Why Discord is switching from Go to Rust

#608

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.

It incurs some cost, but whether it is higher is very debatable. This is very much workload dependent. A smart compiler can elide most reference updates.

No it can't, not in Swift's current implementation.

https://github.com/ixy-languages/ixy-languages

Re: Why Discord is switching from Go to Rust

#609
post #416

Earlier quoted context omitted.

D, Nim and Crystal all do very well on all metrics. Author finds Rust pretty close but not as maintainable. Interesting that the top 3 (performance close to C++, but more maintainable) all are niche languages that haven't really broken into the mainstream.

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.

That is what MS is doing with C#/F# and .NET Native/Xamarin AOT/CoreRT, with the experience taken from Midori.

So I doubt they would sponsor D.

Re: Why Discord is switching from Go to Rust

#610
post #381

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.

Unsafe is being replaced by less error prone APIs, not killed.

Project Panama is what is driving that effort.

Post reply on HN