[foldr]

You’d generally expect Rust and Go to perform about the same for CPU bound workloads. Rust has access to more advanced codegen and optimizations via LLVM, but Go’s garbage collector will often be faster than refcounting (or whatever manual memory management technique your Rust code ends up using). This is especially so given that the GC runs on a separate thread without any additional effort on your part, making it almost ‘free’ in the context of parsers (which tend to be single threaded).

A real world example of this is esbuild. The author posted on HN that his initial Rust implementation was actually somewhat slower than the subsequent Go version.

[super_flanker]

> Go’s garbage collector will often be faster than refcounting (or whatever manual memory management technique your Rust code ends up using)

I'm not supporting the argument that everything should be written in Rust (or whatever) for good performance. However blanket statement like this is not true; micro-benchmarks are often misleading. There are many factors which affect the performance and they come with tradeoffs, so you can choose what options favor you most. At the end, objectively Rust offers more ways to optimize your program.

[foldr]

Rust doesn’t offer the option of using a multi-threaded garbage collector. And ‘will often be faster’ is not a blanket statement; it’s just a rough generalization. I was basing the statement not on microbenchmarks but on the profiling done by the author of esbuild: https://news.ycombinator.com/item?id=22336284

[super_flanker]

> Rust doesn’t offer the option of using a multi-threaded garbage collector. I'm not sure why do you want a garbage collector in rust, most likely an arena allocator would be sufficient for what you may be looking for.

> esbuild That's an interesting situation. I'll have to take the author's word here since rust's version is not available for us to see. I write both go and rust (go for living and rust for side projects), I can see some situation where a naive implementation in go could perform better than naive implementation in rust (assuming both are implementing same algorithm). Again rust provides options to mitigate performance problems once you decide to optimize a bottleneck, but if you touch the upper ceiling in go program, there is not much you can do about it.

[foldr]

You’d want a garbage collector in Rust for the same reason you’d want it in any other language. Manual memory management adds code complexity and can often be slower. Arena allocators only work in certain situations and considerably complicate management of lifetimes.

> , but if you touch the upper ceiling in go program, there is not much you can do about it

I’m not seeing this. There’s lots you can do to optimize Go code. Could you give a concrete example?