or may be: https://blog.discord.com/why-discord-is-switching-from-go-to...

The Discord Go to Rust seems quite sensible engineering.

Sensible? I guess when you dig yourself into a hole, wanting to move to a shallower hole seems sensible. It showed that they understood neither their requirements nor their chosen tools, not surprising given that their stack is Elixir, Go and Rust, languages that there aren't too many experts for, and such consistent choices are a clear display of inexperience. There's just no way that technical sensibility is a chief concern of a company that goes from Elixir to Go to Rust within a few years.

If they had started with a runtime with better GCs or chosen, say, C/C++ from the beginning, none of this would have been necessary. They clearly choose hype first and everything else second. If that's their technical evaluation process, they are likely to choose wrong the first time, the second time, the third time, and however many times they need to rethink their choices, and every time their rationale would seem sensible when it becomes clear that their previous, ill-advised, choice is wrong, and before their new, untested choice shows its own problems. Making a bad choice and then wishing to fix it by making another using the same process that's led to the first doesn't inspire confidence.

Yes, if they used C/C++ from the beginning, they wouldn't have run into GC issues, but they would run into another whole set of issues exclusive to C/C++ (free-after-use, buffer overflows, annoying threading bugs, etc.)

Just like they've run into issues with Elixir and are going to run into plenty of serious issues with Rust. The belief that your chosen language/runtime does not have some very serious issues is the mark of inexperience. The only thing you can do is know what they are and what you can live with. Choosing a hyped language makes the first part very hard; their history shows that they consistently fail on the second part, too. It looks like it's a very inexperienced team, which tech has plenty of, but turning their blunders into success stories is precisely the kind of amateurism dressed in bluster that this post is rightly ridiculing.

There's an argument that it's good to avoid premature optimization - build your thing with something easy like rails or elixir and then if you run into performance issues rewrite those bits in something faster.

It's not about premature optimization. They clearly didn't know enough about Go when they decided to use it -- partly because few people do, but they did know that -- and they clearly don't know enough about Rust, either. They're stumbling from one hype to another based on sales brochures and bragging about it.

Again, Tech is full of such low-experience teams writing this kind of unimportant software and rewriting it every couple of years, and I guess it's good that someone volunteers as a lab rat for new languages (even if they do it over and over). But they're so inexperienced that they can't even see they're being snooty about their ignorance of their own requirements and tech.

> free-after-use

I wish ;)

Oops, meant to say "use-after-free"

Elixir could be argued as almost-sensible if they made the typical chat product backend decision to bolt some features onto ejabberd and pretend like they're hot shit at designing distributed servers. Though I would still stick with vanilla erlang because if you use elixir without also knowing erlang, you'll find yourself up shit creek without a paddle eventually. But a halfhearted google doesn't even confirm that they built on ejabberd.

I work for twitch and I've seen that article before and it doesn't seem to fit the pattern of we messed with GC and it didn't fix out problem. The solution in the article uses weird features and behaviors of the golang GC and how VMs allocate memory but it did work very well for them.

Can you please remove the channel points button for me? Thanks