Hacker News Reader

Comment by api | Hacker News Reader

Go can do this because it’s closer to Java or C# than C. It has a runtime that gets compiled into every binary. Rust deliberately avoided that by design.

View on HN

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.

That is basically what happens in go. The runtime also includes a GC and other features that make it more "high-level."

Any 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).

Sure, 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.

Indeed.

That means that the interop story for golang is horrible. Golang can somewha work with libraries with C bindings. But you can not publish a golang lib as a lib.so with C bindings because of the runtime.

You can, actually, using '-buildmode c-shared' and '//export FuncName' comment directive. CGo supports exporting Go functions in shared libraries, and sets up the Go runtime to be used properly with native C types (e.g. int64 will be long long).

Not necessarly, .NET and D have a much better interop story, despite having runtimes.

You can certainly publish lib.so with Go, here is an example,

https://www.ardanlabs.com/blog/2020/07/extending-python-with...

Reply on news.ycombinator.com