Rewrites of services to decomp into different services, migrate to different datastores to scale up etc. is completely justified and is a good problem to have.
Compare Go and C++, and I bet C++ has had more language changes since Go's 1.0 than Go has. That makes large portions of C++ "relatively new and immature" compared to Go.
Furthermore, A lot of companies to this date have there performance critical code written in C++ , C or Java
Such as you can take HFT for example they use C++ for most of their trading applications instead of newer languages
I'm definitely not saying C++,C or Java is better than Rust or Golang each language has its own pros and cons
High performance systems in GC languages often preallocate or use object pools to reduce time spent in the garbage collector. LMAX's Disruptor, for example, allocates all memory at startup; no additional memory is allocated so the garbage collector never runs. Generational GCs make this strategy more effective because long-lived or large objects are traced rarely or not at all. Another option for trading systems is to run garbage collection after hours when the market has closed.
Go's GC is conservative, not generational, and has a hard coded collection interval of 2 minutes; you pay for a GC even if no memory has been allocated. There are only a few configuration options for Go's GC; if it doesn't work for your use case then you can either fork or use a different language.
This is more about scale and saving computing costs, than proving out a business idea or implementing new features.
One of the big issues with Go is that it's got a steep learning curve. (There was an article about this posted on HN yesterday, in fact)
Rust, by contrast, is an extremely easy language to learn. Of all the languages I've picked up at least partially in my ~12 years of professional programming, Rust was probably second only to to PHP in "get up and start running with it".
If Discord is trying to pick up new developers, or cross discipline seniors to improve their talent pool, Rust is definitely a better choice than Go.
I wish we had a good way to evaluate this question in a quantitative way, but I haven't seen one yet. So reasonable people are going to disagree on the answers here.
I am sure rust is great but it is at the very least more difficult to learn then go.
I don't get Rust. I got Go very easily. Rust just doesn't make sense for me.
In Go I can just write down my thoughts and they translate to code easy. I don't even know which mental game I have to play in Rust. And all the conventions in Rust are another step. The final nail is the un-community of Rust. I still have no idea how to write a simple RESTful http server with a mongodb backend. I've asked only to have been met with downvotes on Reddit. The official MongoDB discourse didn't answer either.
Time and again I want to do something with it but every time I just quit frustrated and irritated of the complexity of everything in Rust land.
Think of Result as (foo, err) bundled into one thing. result.unwrap() is then equivalent to:
if err != nil {
panic(err)
}
if err != nil {
return ..., err
}
Don't get me wrong, there are complicated things in Rust, I just don't see how Result-based error handling is one of them. This is also not a new idea, many languages have something similar.
Also mature languages, even though they're more stable, are just more of a pain to work with since they don't have a lot of the new shortcuts.
For something like Discord, Rust is perfect.
To get actual product work done with optimal efficiency, a mature ecosystem will always win.
Maintaining a codebase written in C is far far harder than one written in Java and that's far harder than one written in Go.
Personally i think developer skill has far more to do with maintainability than language choice. And I have worked with a lot of shit code.
Just like how they did in this case completely switching from Go to Rust
I'm sure we're glossing over probably hundreds of hours of investigations by dozens of people.
The service itself is pretty simple, so it wasn't a gargantuan task. So it was either, rewrite this again in Go (using off-heap data structures to avoid GC pauses, which makes the software both harder to maintain, and also less idiomatic) or try a new language where we won't have these issues - where we don't have to resort to clever hacks to work around the runtime system.
Since then we've continued our investment in Rust, after success of this project (and many others we've yet to blog about as well.)
It seems like everyone is just applying their subjective view. Which is fine. Just don't assume your equation works for everyone and every business.
C++, C and Java are old, so some mistakes can be forgiven. However there are problems with these languages that new languages have addressed.
Do you think a car from 1985 is better than one from 2015? The same applies to programming languages. Given the explosion of programming, it is absurd that the best ideas from PLT are not in mainstream languages.
A complete re-write (preceded by a very deep analysis) is exactly the opposite of productivity.
> problems with these languages that new languages have addressed.
And new problems were introduced... case in point: this very article.
> Do you think a car from 1985 is better than one from 2015?
Depends on the car...
I think this analogy would be better: "Do you think a hammer and screwdriver from 1985 are better than the ones from 2015?"
Plus most of the organizations still write code in matured languages such as C,C++ and Java.
As others have said, however, a big factor certainly is that an internal lead developer lobbied for Rust, which they experimented with.
Scala has already found its niche in Big Data, streaming and distributed systems. Usually, the stack that you can find in my area, consist mostly of Java codebases, sprinkled with some Scala services that are purely data-oriented. There's a high probability that Discord is already using Scala.