Microsoft donates the Mono Project to the Wine team

> - You need a valid Visual Studio or IntelliCode subscription

You don't: https://marketplace.visualstudio.com/items?itemName=ms-dotne... (DevKit, which is the licensed one, is completely optional - it gives you VS-style solution explorer. You can already get it with e.g. F#'s Ionide that works for any .NET file in the solution, though I use neither)

Or https://github.com/razzmatazz/csharp-language-server with either Neovim or Emacs.

> Okay, where's Linux? That's what Mono was originally made for and where Mono really shines.

Regretfully, you have not read the rest of the discussion that talks about this a lot, so here it goes:

Uno: https://platform.uno/docs/articles/get-started-vscode.html?t...

(Uno has more involved setup and build than Avalonia but has way better mobile targeting, and casual reports indicate smaller memory footprint)

Avalonia: https://avaloniaui.net + https://marketplace.visualstudio.com/items?itemName=Avalonia...

    dotnet new --install Avalonia.Templates
    dotnet new avalonia.app
    dotnet run

Gir.Core (GTK4 and co., successor to GTK#): https://gircore.github.io/docs/use.html

ImGui with Silk.NET: https://github.com/dotnet/Silk.NET/blob/main/examples/CSharp...

Nonetheless, you could make this argument for select Apache products, but that's Apache for you. It does not hold true for the larger ecosystem and, at the end of the day, quantity is not quality, otherwise we would've all been swept by Node.js :)

Same applies to "packages that bundle native libraries".

First, they are always maintenance-heavy to manage with ever growing matrix of platforms and architectures. Just x86 alone is problem enough as all kinds of codecs perform wildly different depending if AVX2 or 512 is available vs SSE4.2 or even SSE2 without EVEX. Now add ARM64 with and without SVE2 to the mix. Multiply this by 2 or 3 (if you care about macOS or FreeBSD). Multiply linux targets again by musl and glibc. You get the idea. This a worst-case scenario but it's something Java is not going to help you with and will only make your life more difficult due to the reason below.

There is also an exercise in writing JNI bindings. Or maybe using Java FFM now which still requires you to go through separate tooling, build stage, deal with off-heap memory management API and still does not change the performance profile significantly. There's a reason it is recommended to avoid native dependencies in Java and port them instead (even with performance sacrifices).* Green Threads will only exacerbate this problem.

Meanwhile

    using System.Runtime.InteropServices;

    [DllImport("libc", EntryPoint = "putchar")]
    static extern int PutChar(int c);

    var text = "Hello, World!\n";
    foreach (var c in text) PutChar(c);

(I'm not sure if binding process on the ole Mono was any different? In any case, the above is a thing on Linux since 8 years ago at least)

Like with other false claims, the "better native packaging" one is easily disprovable. Just look at the list of supported platforms here: https://github.com/sandrohanea/whisper.net?tab=readme-ov-fil...

It even supports CoreML on iOS and macOS.

* Now applies to C# too but for completely different reason - you can usually replace data crunching C++ code with portable pure C# implementation that retains 95% of original performance while reducing LOC count and complexity. Huge maintenance burden reduction and "it just works" without having to ship extra binaries or require users to pull extra dependencies.

NT also had OS/2 and Posix subsystems ((checks calendar)) about thirty years ago, now that I think of it.

And unfortunately, the only stench I can't stand more than Google's is Microsoft's.