Anyway, I'm not sure what Mono's AOT compiler looks like these days, but the new Native AOT for .NET (which is improved in .NET 8) is definitely designed for production and things like binary size and startup speed, with no external dependencies, and they definitely seem to be trying to make it act and feel like other natively compiled AOT languages. People care more about it these days because a big shift is in things like containerized runtimes where you don't want to pay for the overhead of distributing the .NET runtime for each container, because they can't be shared. So things like AOT, dead code elimination, reflection removal for source generators at build time etc all add up. Cold-start time is also important for some of those uses.
Linux distro fragmentation and userspace ABI compatibility being an afterthought also makes some FOSS/Linux projects that require interpreters/runtimes more annoying than they need to be and that also had some cultural, perceptive ramifications for a long time too -- that's not really .NET specific, but it probably never helped. Like, you're saying "just download an executable and run it" but that was actually often not workable in many cases for many reasons for many apps. And whether or not whether users understand what those reasons were, correctly or not, it colors their perception of that class of tools.
But anyway. These days there are lots of solutions for these problems. Native AOT is a pretty welcome solution for a good class of issues IMO, and Mono and .NET Core both seem to be established in various domains. I'll definitely be looking forward to trying Native AOT on server-side apps.
> Banshee is a pretty long-lived project; we might be talking 10+ years ago.
Mono was a very different thing back then -- less mature, and Microsoft (mid Ballmer era) seemed to have a love/hate relationship with it.
It was announced for Java 6, half baked during Sun/Oracle transition, and to this day most people still don't grasp the difference between OpenJDK, other OpenJDK distributions and alternative JVM implementations.
Mono included a powerful GUI framework which run on far more platforms than the .NET GUI. And Ximian/Xamarin invested a lot of effort to be as compatible as possible to all aspects of .NET (see e.g. https://www.mono-project.com/docs/about-mono/compatibility/).
It was also not explicitly intended, blessed or even recognized by MS for a number of years. It was just another open source project.
This gave rise to other platforms that were attempting to improve on C (GNOME) / C++ (KDE), such as D, and finally JavaScript for GNOME. Meanwhile, web apps (and then Electron apps) became de-facto defaults due to their cross-platform nature.
Had MS embraced (err...in a positive way!) Mono from the start, taking into consideration Miguel's influence in the GNOME community, GNOME 3 might have been written in .NET.
Which is unjustified, because Mono CLR is just a single executable less than 5 MB which you can download and run without a complicated installation process (see e.g. https://github.com/rochus-keller/Oberon/#binary-versions ). AOT compilation on the other hand is a huge and complex installation depending on a lot of stuff including LLVM, and the resulting executables are not really smaller than the CLR + mscorlib + app.