Hacker News new | ask | show | jobs
by super_flanker 1331 days ago
> 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.
1 comments
foldr 1331 days ago
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
link
super_flanker 1328 days ago
> 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.

link
foldr 1326 days ago
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?

link