[scottlamb]

As a general rule, I'd expect Rust stuff to use less CPU (as the grandparent comment mentioned, it's optimized with LLVM) and less RAM (no GC). If that's a big win or not depends a lot on what your CLI application is doing. I'm a big fan of Rust but if Go does what you want, great. Go's a simpler language with a more mature/stable ecosystem and much more straightforward async code.

Rust of course has generics too, so I find it easier to use the right data structure for the problem (eg btrees) without dropping to interface{}. But it seems like the Go team is getting serious about adding generics so this advantage may be temporary.

[cle]

I've found it to be mixed, depending on the nature of the workload. Sometimes having GC can be faster, since allocations can be cheaper. But it will generally trade off higher memory utilization, and the behavior is harder to predict under diverse workloads.

[scottlamb]

I agree GC doesn't necessarily mean more CPU. Just more RAM. My reason for thinking Rust code generally uses less CPU is based on it using a more sophisticated compiler.

That said, when Rust code spends a lot of time on allocations, it's usually fixable:

* You can switch global allocators to jemalloc or, for short-lived programs with acceptable total allocation size, bumpalo.

* You can often restructure code to borrow/reuse buffers instead of having per-iteration allocations.

* You can use slabs or arena allocators.