[leethaxor]

So you're saying they wrote exactly the same program in Go and Rust for the comparison, changing the syntax only? Well then it's no surprise the Go version was faster.

Don't write Rust as if it was Go. That doesn't say anything meaningful about either Go or Rust.

[eloff]

Actually he wrote the Rust version first, so you're wrong jumping to conclusions.

I'm not trying to say Go is faster than Rust, it's usually slower. But there are always exceptions to the rule. The Go code, on the other hand, is usually simpler and quicker to write. For that reason I'd prefer Go if the problem lends itself to a garbage collected language.

[leethaxor]

So what did you mean by this?

> Because different programs, implemented differently, run at different speeds...

We're talking about two programs with exactly the same purpose - ingest TypeScript and output JavaScript. It's a pretty clear-cut comparison, IMHO.

> The Go code, on the other hand, is usually simpler and quicker to write

I'm writing Go code at work, and Rust code mostly for fun (but used it at work too). I'd say this has changed significantly in the last 2 years. Now with rust-analyzer and much improved compiler output, writing Rust is very simple and quick too. I guess getting into Rust can be a little harder if you've only ever used GCed languages before, but it's not that hard to learn - and once you do it's super-effective. And the type inference of Rust is a huge reason why I'm using it - while Go has none.

Another thing to consider - usually the code in Go is much more about writing algorithms yourself instead of using library functionality (this is changing slowly thanks to the new support of generics but most code hasn't caught up yet and there aren't good libs using it so far). The resulting code in Go can be convoluted a lot and contain very hidden bugs. People also usually don't bother implementing a proper search/sorting algorithm for the sake of simplicity/speed of development - which you'd get automatically if you used a library function - so the code is less efficient. My Go code is usually 2-3x longer than the equivalent in TypeScript or Rust.

Go is great, I like it. Rust is great too. I recommend you to do what the esbuild author did - test it and choose for yourself, don't bother too much about others' opinion.

[eloff]

> We're talking about two programs with exactly the same purpose - ingest TypeScript and output JavaScript. It's a pretty clear-cut comparison, IMHO.

There are an infinite number of ways to design two programs for that task, with different trade-offs. You can't draw conclusions about which language is faster based on two different implementations by different people.

> Go is great, I like it. Rust is great too. I recommend you to do what the esbuild author did - test it and choose for yourself, don't bother too much about others' opinion.

I'm actually writing Rust code the last two years. It's been a while since I've used Go. But I'd rather use Go if the problem allows for a garbage collector. It's just simpler than managing it manually in Rust with the borrow checker and its rules. This is my opinion, nobody else's.

[stavros]

The GP didn't say that, maybe they wrote Go as if it were Rust, for all we know.