In Discord’s defense, their product’s scope and userbase has increased orders of magnitude over just a few years. Setting language choice aside, one would expect several rewrites of core code and infra over this time.

My intention was to not set the language choice aside, especially where rewrites are squarely targeted at migrating to a different language.

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.

Go is starting to get a bit old though. Version 1.0 dates back from 2012, 9 years ago. It's as old and mature as Java was in 2005.

Not having a v2.0 does not mean it's old, it just means that they did not break backward-compatibility since then.

Yup this makes me wonder why do companies go for relatively newer languages compared to old ones such as Java,C++ or C as they have been matured and has been widely used

Go was announced in 2009, and went 1.0 in 2012. Sure, it's "newer" than languages from the 90s, but calling it "new" when it's nearly a decade old doesn't pass the smell test. Serious software has been written in both Go and Rust, and real issues with Java, C++, and C that these newer languages address are well known.

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.

I agree with you on that but this still makes me question the problem they are trying to solve can't they solve in Go instead of switching to Rust.

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

> I agree with you on that but this still makes me question the problem they are trying to solve can't they solve in Go instead of switching to Rust.

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.

They did solve it in Go, then got performance improvements re-implementing a small piece in Rust.

This is more about scale and saving computing costs, than proving out a business idea or implementing new features.

Not all problems are specifically technical in nature.

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.

Not to discount your experience, because I think that this topic has a lot of nuance and is very different on an individual level, but most people regard Go as easy to learn, and Rust as difficult to learn.

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.

This is the reverse of the characterization of the two languages I usually see. I usually see "Go is easy to learn and use" and "Rust is hard to learn but has performance advantages". I often see comments about how you "really need to go read the Rust book" and not just try to pick up Rust on the fly.

This is the first time i have seen this argument. Just understanding ownership seems more complex to me than writing a simple web app in go or PHP for that matter.

I am sure rust is great but it is at the very least more difficult to learn then go.

to this day I can't wrap my head around the need to unwrap almost every single variable/function/whatever.

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.

> to this day I can't wrap my head around the need to unwrap almost every single variable/function/whatever.

Think of Result as (foo, err) bundled into one thing. result.unwrap() is then equivalent to:

    if err != nil {
        panic(err)
    }

And the ? operator is:

    if err != nil {
        return ..., err
    }

You don't need to unwrap (or ?) everything, just things that return a Result -- which is the same as functions which return an error in Go. The advantage of Result is that you can never forget to handle the error because the compiler requires you to get the value out of the Result in such a way that you have to handle errors.

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.

Because excited developers generally means more satisfaction from work. And one way to keep developers excited is to give them new toys to play with.

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.

Crap developers get excited by new tech. Good devs want to get problems solved. If a new tech is the best solution then use shiny new tech. Usually it´s not the best choice.

What a ridiculous statement. You can be excited by new tech and realize how it can solve your problems.

New languages lack most of what is needed to be highly productive. Tooling is minimal to none. Libraries are sparse and still catching up, this takes many years. Many gotchas remain undiscovered and will bite you in production.

To get actual product work done with optimal efficiency, a mature ecosystem will always win.

And you can be maintaining a system built by developers who got excited by shiny new tech and made a load of inappropriate technology choices because they were flavor of the month and looked good on their resumes.

It sounds like you've had bad experiences with some devs and you're applying that to everyone.

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.

I have worked in tech long enough to see some common patterns. It's usually intermediate devs (though not always) who get excited by new tech. The same people are usually pushing to use shiny new tech in places where it isn't needed. You don't get cynical old school devs trying to replace working parts of the tech stack with tech less than 5 years old.

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.

I agree with you, developers do get excited when are using newer technologies but the question is what if a new problem arises and they might not be able to find a to it solution.

Just like how they did in this case completely switching from Go to Rust

Then they'll have to cross that bridge when they come to it. Nothing of this article gave me the impression that the second they saw this bug they're like WELL TIME TO SWITCH.

I'm sure we're glossing over probably hundreds of hours of investigations by dozens of people.

We kept dealing with GC pauses in go, and eventually after investing a bunch of time trying to fix this - we decided to research what it'd be like to rewrite it in another language.

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

Excitement < the countless hours required to rewrite a complex system in a non-trivial language.

And do you have numbers to back up excitement of devs vs their productivity?

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.

The simplest answer is that these newer languages were created specifically to address problems with existing languages. If a new language has no compelling reason for anyone to switch to it, why bother to create it in the first place?

It's not that easy. A new language starts because a set of developers has a problem, however that doesn't mean that others share that problem or agree to the choices and solutions made. Rust seems to be in a good situation where this worked for large parts, but many languages came and got no or only short attention.

There are actually very good reasons to go with Rust over those languages, which were the motivating reasons Rust was developed in the first place. Rust supports lower-level development than Java, offers much stronger safety and correctness guarantees than C or C++. This is why Google's security team also supports reimplementing C libraries in Rust (https://security.googleblog.com/2021/02/mitigating-memory-sa...).

Have you ever considered that programming language design is an evolving field, and programming languages directly influence programmer productivity?

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.

> programming languages directly influence programmer productivity

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

I definitely see the appeal of Java (used to be my main lang), but I would never in a million years base a company's flagship product on C or C++ unless it was a domain requirement (embedded, kernel, etc.). It's just not safe.

There's a difference between starting new projects and rewriting old ones. I have 7+ years of professional C++ under my belt and probably wouldn't start a new project in it. Same with Java. Sometimes new things are better.

Easier to hire people working in the new hot languages, and get younger programmers out of college.

At the same time, in college we are teaching our students Java and C++ because that's what companies expect our students to know. Half our CS curriculum is in Java. The students I teach loathe C and C++ and want to learn Rust, but we won't teach it to them except in an experimental elective that won't count toward their graduation. So it's hard to say how many young programmers out of college actually know these "new hot languages".

I totally agree with you on this comment since as I college graduate I learned Java , C++ ,C and python but I was exposed to Golang and Rust through online discussion forums.

Plus most of the organizations still write code in matured languages such as C,C++ and Java.

I don't think so. There is a full load of people with experience in C++ or Java, but people with experience in performance critical (whatever that means) Rust code is more limited for being a newer language. You however win on the hipness scale and attention in places like hacker news.

As others have said, however, a big factor certainly is that an internal lead developer lobbied for Rust, which they experimented with.

> we'd have seen Scala thrown into the fray as well.

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.