whisper.net

was introduced. The main change was the switch to SDK-style projects files. Kind of like Cargo.toml but XML. Adding a file to a nuget package (or anything else you build) is just adding a <Content ... /> item to an <ItemGroup>. Adding custom MSBuild stage or behavior is done via .targets file for packaging purposes: https://learn.microsoft.com/en-us/nuget/concepts/msbuild-pro... Which is why I linked you Whisper.net. It has a .targets file that manages platform-specific dependencies: https://github.com/sandrohanea/whisper.net/blob/main/Whisper.... As you can see, it is possible to make definitions conditional and use arbitrary information provided by the build system. It is very powerful. I don't know what made you think that I assume anything about .jar files. For another example, look at these lines: https://github.com/U8String/U8String/blob/main/Examples/Inte... Together with <PublishAot> property, invoking 'dotnet publish -o .' calls into cargo to build a static library from Rust, then compiles C# project, then compiles the produced .NET assemblies to native object files with ILC (IL AOT Compiler), and then calls system linker to statically link together .NET object files and a Rust object file into a final native binary. The calls across interop, as annotated, become direct C ABI calls + GC poll (a boolean check, multiple checks may be merged so less than a branch per call). This produces just a single executable that you can ship to users. If you open it with Ghidra, it will look like weird C++. This is a new feature (.NET 7+) but even without NativeAOT, it was already possible to trim and bundle CIL assemblies into a single executable together with JIT and GC. As far as I'm aware, the closest thing that Java has is Graal Native Image, which is even more limited than NativeAOT at the present moment (IL linker has improved a lot and needs much less annotations, most of which can be added as attributes in code and the analyzer will guide you so you don't need trial and error). And the project that allows to embed bytecode in the .NET trimmed single-file style in Java is still very far from completion (if I understood it right). I think https://two-wrongs.com/dotnet-on-linux-update is more or less representative of unbiased conclusions one makes when judging .NET by its merits today. You can always say "it used to be bad". Sure. It does not mean it still is, and the argument is irrelevant for greenfield projects, which is what I advocate C# is the better choice for anyway. > I fully agree though that .NET is far superior in terms of native interop. This is not limited to native interop. At its design inception, C# was supposed to replace C++ components at MS. Then, in C# 2, a focus group including Don Syme if I'm not mistaken pushed for generics and other features. Someone posted a history bit here on HN. This and influence from the projects like Midori (spans, struct improvements), and subsequent evolution (including the existence of Mono) and especially after it stopped being .NET Framework and became .NET resulted in a language that has much wider scope of application than most other GC-based languages, including Java, particularly around low-level tasks (which is also why it's popular in the gaming industry). Unfortunately, the perception of "another Java" hurts the ecosystem and discourse significantly, as the language and the platform are very unlike this claim.

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); since C# 2 or maybe 1? No setup required. You can echo this snippet into Program.cs and it will work as is. (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.

e packages that have native dependencies either simply expect the host to have them installed (like you install, say, gstreamer), or come with dependent packages per-platform (and the matrix gets quite big: [x86, x64, arm64] x [linux, osx, win]). Like https://github.com/sandrohanea/whisper.net But then again, this has to do with a specific package and its owner, if that's what you meant. Note that there is no culture issue, there is poor framing and a strawman one. "I had issues on a niche target" is not mutually exclusive with cross-platform. Would you say lack of support for SunOS is a damning evidence of "pro-windows agenda"? (whatever it is, I use macOS and Linux hosts mainly and surprisingly and funnily enough, there is work to support SunOS as well) The thinly veiled "but linux/unix!" low effort replies are unfortunate and tiresome. They don't strike me as a productive attitude that seeks to make things work.