This is consistent with my observations of porting Java code to Rust. Much simpler and nicer to read safe Rust code (no unsafe tricks) compiles to programs that outperform carefully tuned Java code.
Why Discord is switching from Go to Rust
311–320 of 670 posts
Re: Why Discord is switching from Go to Rust
#312Go 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?
I downvoted. "Go is not a general-purpose language" is a statement I could see myself agreeing with, so I started reading your comment excited to read a brief outline of what use-cases Go is specifically aimed at and how that makes it sub-optimal for Discord's use-cases.
But "it's for Google, and you aren't Google" isn't a novel perspective, doesn't leave me with new insights, and isn't really actionable for either Google or people who aren't Google.
Usually this criticism is leveled at Go's dependency management story, with the implication being that it's suited to Google's monorepo but not normal people's repo habits. It's not clear to me how the criticism relates to the issues discussed in the article, which seem to be more about the runtime and GC behavior.
Your comment also doesn't come off as amusing or otherwise entertaining, so it feels like you're just dunking on Go users without really aiming to make anyone's day better.
Disclaimer: I use Go at work and think it's incredibly frustrating at times.
Re: Why Discord is switching from Go to Rust
#313Earlier quoted context omitted.
> 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. Well, sure, because categorizing languages as "valid/invalid" doesn't make any sense. But it does show yet another example of how designing a language to solve Google's fairly-unique problems doesn't result in a general-purpose language suitable for solving most people's problems.
Keeping LRU cache that large with these performance requirements is not a "most people's problem". Go is actually great to solve most people's problem with web servers, while Rust is better for edge cases.
> Keeping LRU cache that large with these performance requirements is not a "most people's problem".
Sure, but that's not what I said.
Any program of sufficient complexity will run into at least one critical problem that isn't a "most people's problem". A well-written general-purpose language implementation will have been written in such a way that that problem isn't totally intractable.
> Go is actually great to solve most people's problem with web servers, while Rust is better for edge cases.
Most people's problem with web servers is writing a CRUD app, which is going to be easiest in something like Python/Django/PostGres/Apache. It's not the new shiny, but it includes all the usual wheels so you don't have to reinvent them in the name of "simple". Similar toolsets exist for Ruby/Java/.NET. Give it a few years and similar toolsets will be invented for Go, I'm sure.
Re: Why Discord is switching from Go to Rust
#314Earlier quoted context omitted.
> especially, as Go is implemented in Go. Well, parts of it. You can't implement "make" or "new" in Go yourself, for example.
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".
Re: Why Discord is switching from Go to Rust
#315Earlier quoted context omitted.
> 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 t…
Nothing you wrote contradicts what I said. You can't implement "make" in Go. The fact that you can implement some approximation of it with a worse signature and worse runtime behaviour (since it won't be compiler assisted) doesn't make it "make".
Re: Why Discord is switching from Go to Rust
#316Looks 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…
> 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…
> context switches between JVM and native code are typically fairly expensive
Aren't these Unsafe memory read and write methods intrinsified by any serious compiler? I don't believe they're using JNI or doing any kind of managed/native transition, except in the interpreter. They turn into the same memory read and write operations in the compiler's intermediate representation as Java field read and writes do.
Re: Why Discord is switching from Go to Rust
#317Earlier quoted context omitted.
Not sure if this is exactly what you are looking for, but I'd do some digging into consistent hash rings.
Oh, interesting: https://en.m.wikipedia.org/wiki/Consistent_hashing > Consistent hashing maps objects to the same cache machine, as far as possible. It means when a cache machine is added, it takes its share of objects from all the other cache machines and when it is removed, its objects are shared among the remaining machines. I guess the challenge here is that subscriptions are sparse: I.e. one ws connection can ca…
There's a number of ways to tweak the algorithm, e.g. by generating multiple hashes per endpoint and then distributing them around a unit circle.
I've seen this used to consistently allocate customers to a particular set of servers, not just ensure you are hitting the right cache. It doesn't fully solve the subscription issue where multiple people are in multiple channels, but it could probably be used as a building block there.
Re: Why Discord is switching from Go to Rust
#318Go 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.
Isn't that indication of a failure? It seems like Go aimed to replace Python and Java code at Google.
Re: Why Discord is switching from Go to Rust
#319Go 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?
I am not downvoter, but you should learn the history of the language.
Most of the concepts in the language were first implemented long before Google even existed, for systems that were very different from modern ones.
It was made by people who had been designing languages for about 40 years now. While some design choices seem weird, they usually have very strong argumentation and solid experience behind them.
Also if you read the list of problems tha Go is intended to solve, you will be surprised how common they are in software development.
Re: Why Discord is switching from Go to Rust
#320Earlier 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!
ARC, used by Swift, has its own cost.