The actual issue wasn't Go over Rust, rather having key people responsible for C# design, on a Microsoft project, going for a Google language.
While at the same time, the .NET team routinely talks about .NET image problem outside traditional Microsoft shops, which naturally decisions like this aren't helping a tiny bit.
Yeah loved the language and the IDE, but only boring Enterprise stuff built with it. Also C# got so complex, since it had to absorb every idea from F# rather than making F# a viable programming language on itself and improving interop...
At a given point after being a C# programmer for years I still encountered patterns that were completely unreadable to me.
That's what happens when you have an high level VM that wants to support high level concepts from multiple high level languages, and all your languages need to be able to talk to each other.
Same thing will happen to Wasm as it decides to add more and more high level stuff “to avoid shipping multiple GCs” and “to get different languages to talk to each other.” As soon as you want to abstract over more than “a portable CPU and memory” you get into that mess.
Never worked in the past better than JVM and CLR, but let's keep trying.
Do you have a specific snippet in mind which demonstrates the issue? It is likely more of a team or a community issue when it comes to writing unreadable code than a language one since it tends to happen in every sufficiently powerful language.
> rather than making F# a viable programming language
F# is a viable language aside from using specific few libraries that don’t play with it nicely or around writing ref struct heavy code. I’m not sure what makes you think it is not. In comparison, it is probably more viable for shipping products than Scala, Clojure, OCaml and Haskell.
I've quit working on .net solutions a few years ago, but I've built a feature in F# about 7 year ago. While the language was wonderful, the IDE support was very minimal. Documentation and examples were really hard to find. So I don't feel it's really pushed as an alternative.
C#: A lot of LINQ style code was really hard to grok for me. Like a language in a language. The language got really huge in general. While it was fine as a "better Java" for most purposes.
I think it speaks to an incredibly pragmatic viewpoint though. When you take a look at your flagship language/ecosystem and you say, "hey, this is great for building entire systems for doctor/patient data... or perhaps even banking software"... but recognize that "it's probably not the best thing for building a compiler/tooling". Google themselves show the same pragmatism when NOT using Go for Android. They prefer Kotlin these days.
Complete different reasoning, choosing Go instead of Kotlin would mean rewrite from scratch 100% of Android userspace, minus the C++ libraries for Treble drivers, graphics and ART toolchain.
And Google did do exactly that with Fucshia, which doesn't seem to be going to power anything beyond Nest screens.
Do you want more portable than bytecode with a dynamic compiler? Apparenty the greatest thing on Earth as per WebAssembly folks.
As for AOT compilation, there have been multiple approaches since the early days, and the latest, Native AOT is good enough for everything required to write a TypeScript compiler, including better WebAssembly support than the Go compiler, thanks to Blazor infrastructure.
While at the same time, the .NET team routinely talks about .NET image problem outside traditional Microsoft shops, which naturally decisions like this aren't helping a tiny bit.