Comment by throwaway487552 | Hacker News Reader

Comment by throwaway487552 | Hacker News Reader

Parent Full thread

throwaway487552

Why they are ignoring Erlang's and Go's much more saner approach with blocking lightweight processes/goroutines which just work?

It is not just better, closer to reality semantics (someone have to wait), but also better granularity (one connection/channel, one process), shorter, less confusing code.

My guess is that the choices were made on the basis on meme/popularity among ignorant coders (to attract more devs, to gain more momentum, etc) rather than tech per se.

To have a select and receive as a language constructs (with pattern matching, of course) and coroutines (basically, software interrupt handlers) is a much better approach for a system programming language, just by being close to a system.

Universal frameworks like tokyo or async/await is cancer and , it seems, does not suit a system language at all.

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.

Those lose zero-overhead interop with C, which is a core constraint for Rust.

Your guesses are incorrect.

> lose zero-overhead interop

How many LOC is tokyo nowadays?

I don’t understand how that’s relevant.

To me, at least, this means that the overhead is substantially greater than zero.

That’s not what that phrase means.

Tokyo is a city

Reply on news.ycombinator.com