3 ms·
It isn't about “memes” or “ignorant coders.” Please grow up. The way goroutines work isn't compatible with Rust's core language goal of zero-cost abstractions.
by bfrydl 8y ago
It isn't about “memes” or “ignorant coders.” Please grow up.
The way goroutines work isn't compatible with Rust's core language goal of zero-cost abstractions. In order for a goroutine to suspend and resume at arbitrary points in otherwise normal functions, each goroutine needs its own stack. This is convenient but comes at a cost, and I certainly wouldn't say that it matches reality or is close to the system.
The way Rust implements async ensures that there is zero overhead. You can think of the compiler as constructing an elaborate state machine. Each task is a normal structure in memory, just a few bytes rather than an 8 kb stack. This means that by paying the cost of dealing with a somewhat invasive language feature, Rust async code is more efficient than the equivalent Go code.
This is part of Rust's core design. The language should be as convenient or productive as possible, but never at the cost of performance or efficiency even if that cost is very small.
- throwaway487552 8y agoIf "zero-cost abstractions" and "zero overhead" are not memes, then what memes are? > I certainly wouldn't say that it matches reality or is close to the system. The call assembly instruction uses stack, the ret uses stack. Procedures therefore are hardware-assisted stack-based entities. So are interrupt handlers, which are specialization of a procedure. These are the right abstractions to use for fine-granded modularity exactly because they are hardware-assisted and stack-based. Threads are the wrong abstractions (Erlang authors explains why). I have zero interest to investigate the rest of your claims, but I think they are unsubstantiated as the one above.
- bfrydl 8y agolol how boring do you have to be to troll engineers it's like if an accountant tried to start internet fights over what kind of rounding is best