3 ms·
Why is runtime needed for a syntactic feature like that? All you need is an async wrapper for system calls, and every sync function could, in principle, be comp
by bheadmaster 3y ago
Why is runtime needed for a syntactic feature like that? All you need is an async wrapper for system calls, and every sync function could, in principle, be compiled down to a coroutine and ran on an executor of your choice.
Just because Go has a runtime and has a go keyword, doesn't in itself mean that runtime is necessary for the go keyword to exist.
- pclmulqdq 3y agoThat is basically what happens in go. The runtime also includes a GC and other features that make it more "high-level."
- cstrahan 3y agoAny goroutine can be interrupted to let another goroutine run on the respective OS thread, without the involvement of the code author. The thing managing this scheduling behind the scenes is the runtime. Also, the entire standard library is built atop non-blocking IO, which again is managed by the runtime behind the scenes (e.g. waiting for file descriptor readiness, scheduling the respectively blocked goroutine, etc). And there is no “async system call wrapper” involved - these are fundamentally different system calls (for epoll or kqueue or whatever). You could argue that all go code is async (in the Rust sense), and because of this uniformity, there’s no need for the syntactic distinction that Rust requires you to make. Rust could have done the same (and at one point in time they did have green threads), Rust decided that the convenience to Rust programmers wasn’t worth the cost elsewhere (the inclusion of a runtime, performance overhead, C interop, etc).
- bheadmaster 3y agoSure, but I'm not saying "implement all Go features in Rust" - all I'm saying is "use function call prefix to asynchronize function calls instead of synchronizing them". What exactly makes that particular syntactic construction troublesome? Compiler could compile it exactly the same way it's doing now.