[blablabla123]

I'd be really surprised to hear that Go is supposed to be faster than Rust. Of course Rust is a bit newer but to me it always sounded like Go is fast because it's static but it doesn't have to be high-speed if that would sacrifice conciseness. Given that this is an artifical example, this here looks more realistic: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[arcticbull]

Rust and Go are contemporaries. Rust started in 2006 at Mozilla, and the first Go public release from Google was in 2009, meaning it probably started at the same time.

Except of course all the Plan 9 garbage (like Go's hand-rolled assembler) brought in to underpin Go from the 80s ;)

[gpm]

Rust is also basically just LLVM in terms of optimization, which looks like it had it's initial release in 2003.

[entha_saava]

> Except of course all the Plan 9 garbage (like Go's hand-rolled assembler) brought in to underpin Go from the 80s

This is unfair criticism. If Go had used LLVM, it would affect its selling point (fast compile times) and authors knew the plan 9 toolchain well.

Go the language feels like it is from 80s. But its toolchain is not at all bad. LLVM monoculture is the last thing one would want. Obligatory reminder that LLVM has its flaws too..

[blablabla123]

Also when this LLVM stuff doesn't work, it's a major pain to troubleshoot because all this is a complexity monster. Go and its Plan 9 heritage is more like 80s retro future and things like cross-compiling are super easy

[arcticbull]

In my opinion, compile times are irrelevant. Developers can always get faster or larger machines if they need them. What matters is how the final product performs on customer machines. Performance and memory usage of the final product, plus your ability as an engineering team to avoid costly and difficult mistakes are basically the only thing that matters.

[entha_saava]

> Developers can always get faster or larger machines if they need them.

Those who can get top notch hardware are already on top notch hardware and those who can't are limited by management decisions.

Even with top notch machines, compile times matter. Because the difference are huge in compile times of C++ and Go in moderately complex projects with bad build systems that are the norm.

> What matters is how the final product performs on customer machines.

Apparently today's developers value fast iteration speed and that's fine. The problem is they don't value user resources because they have top notch machines and don't care about performance.