Wow that's a long post. While I read it, wanted to note that .NET deals with blocked threads by having the threadpool scale the worker thread count dynamically through hill-climbing algorithm that will work to reduce the time the work items wait in their respective queues unhandled (the threadcount can be 1, it can be 200 or more, depending on what you do, 200 is clearly a degenerate case but this is what you get if you managed to abuse it badly enough to act as good old thread per request way). It also has out-of-hill-climbing blocked thread detection (things like Thread.Sleep) to cope with workers being blocked faster. It is all around a very resilient implementation.

As for the cost of FFI, in .NET, the regular p/invokes that don't require marshalling (most of the time it's just UTF-16<->UTF-8) cost approximately ~4-1.5ns. The cost can be further reduced by

- Suppressing GC frame transition (safe for most sub-1ms calls)

- Generating direct P/Invokes when publishing as an AOT binary (they are bound at startup but dynamically linked dependency referenced this way needs to be available)

- Static linking. Yes, .NET's AOT binaries can be statically linked and it is done by system linker, which makes the call a direct jump, which costs as much as a similar call in C. .NET can also produce statically linkable libraries which can be linked into C/C++/Rust binaries (although it can be tricky)

On AST - you are not parsing C# yourself, you are using the same facilities that are utilized by Roslyn. You can do quite a few tricks, I'm working on a UTF-8 string library (which, naturally, outperforms Go implementation :P) and it uses new interceptors API to fold UTF-16->UTF-8 literal conversions during build. My skill is way lower than of engineers working with it in more advanced settings and yet I was able to easily use it - it is very convenient despite the learning curve.

On Go hate - it's simple. It has reached quite some time ago the critical adoption rate where it will be made work in the domains it is applied to regardless of its merits (hello a post on HN describing the woes of a company investing millions in tooling to undo the damage done by bolting in NILs and their unsoudness so tightly). It has serious hype and marketing behind it, because other languages are either perceived as Java-kind-of-uncool, or are not noticed, or bundled, again, with Java, like C#. And developers, who have a rift where their knowledge of asynchronous and concurrent programming should be, stop reading at "async/await means no thread blocky" and never learn to appreciate the power and flexibility task/future-based system gives (and how much less ceremony it needs compared to channels or manually scheduled threads, green or not).

Just look at https://madnight.github.io/githut/#/. Go has won, it pays well, it gets "interesting and novel projects" - it does not need your help. Hating it is correct, because it is both more popular and worse (sometimes catastrophically so) at what other languages do.