Golang’s most important feature is invisible

Re:Golang’s most important feature is invisible by klabb3 on Wednesday January 26, 2022 @12:40PM (#30088740)

Ah! Finally I think I'm getting the distinction, thanks for being patient. I also agree about the ABI issue - explicit callbacks is much simpler.

It appears as Go doesn't expose green threads as per your definition for it's FFI though, but rather an even simpler synchronous interface in both directions. This makes it impossible to interface with the event loop, and one must use threads. For Go->C, at least, this should not block the runtime since the Go runtime spins up more threads in case of long running synchronous calls (their version of pre-emption).

[ Parent | on HN ]

Re:Golang’s most important feature is invisible by int_19h on Thursday January 27, 2022 @12:49PM (#30103621)

For an opposite example, consider async/await in C# - you're not restricted to .NET when using it; it also supports e.g. the native async OS APIs in WinRT (which are callback-based on ABI level: https://docs.microsoft.com/en-us/uwp/api/windows.foundation....). Ditto for co_await in C++20.

Go's approach leads to an insular ecosystem that tends to reimplement everything, because that's the only way to get this transparent async throughout.

[ Parent | on HN ]