| >.NET Core has obviously changed the game but other platforms are still treated second class to Windows in many ways. Not really. Maybe a tiny little bit, but not really. Microsoft has discovered that the "other platforms" are very important, because they want to sell Azure, and people there will use linux predominantly. Same as MS invested heavily in WSL to support "linux" workflows. dotnet on linux might not be completely to parity with dotnet on windows when it comes to platform integration, but it's getting there. dotnet on macos is somewhat similar in this regard and maybe a little bit slower to catch up because may be a little lower in priority than linux. Anyway, it's not my impression that platforms other than Windows are treated second class. It's just that Microsoft has already invested decades in the Windows implementation, while the linux and macos implementations are rather fresh (although dotnet using mono as a base certainly helped) and therefore less optimized yet in certain regards. >Java has higher peak JIT performance though after Rosalyn was introduced C# has made strides at closing that gap on many metrics. That isn't really true. JIT (peak) performance is pretty much comparable between Java and dotnet, maybe even a little better in dotnet/RyuJIT. There are certain areas where one is better than the other. Roslyn is the C# to MSIL compiler, btw, while the JIT compiler for MSIL is RyuJIT. While Roslyn helps produce MSIL that is (hopefully) great to JIT compile, the actual JIT compilation work happens in RyuJIT. > GC algorithms are more advanced, namely ZGC and Shenandoah. Yes, GC is where the JVM really shines - if you go through the trouble of finetuning it to your particular need. At the same time the CLR GC seems to work better by default, but it's a lot less configurable too. In the CLR you basically have only 3 modes of operation: interactive GC (concurrent, trying to avoid GC pauses, with the trade off of less performance, for things like GUI applications), non-concurrent GC (which works well for a lot of CLI type tools and some services, where small GC pauses are less noticeable), and "server" (which is e.g. a lot less eager to "return" memory to the OS, aimed at long running processes that are then usually the only major thing running), and that's basically it, where on java you have tons of available schemes/algorithms and each one is usually heavily configurable as well. As you already hinted at, dotnet made great strides in the last years to avoid a lot of heap allocations and the GC with value types, Span<> and friends, avoiding boxing a lot of times and bringing stackalloc to managed code, and their use in the standard library. So peak GC performance is a little less important in the CLR than in the JVM (but still very important, of course). You say "may" a lot, referring to proposed java changes e.g. to add value types, make native code interaction less painful, add some form of async-await. Great. And I hope they will finish up and ship these things eventually, and it will be great implementations. The thing is dotnet already has all these things shipped and in production already, often for quite a while. And while java is still figuring out the design, dotnet can already improve their shipped implementations based on real world experience and data in every new version, and usually does so. Java/JVM is playing catch up here. >Async/await being the key example. It's been in the CLR for what feels like forever now vs JVM which is only now just getting close to landing Loom. However I feel like Loom is an infinitely better solution to the problem that leverages the unique advantages of JIT compiled VM languages that rely on relatively little unmanaged code. From what I have seen of Loom so far (which is admittedly not that much) my impression is the direct opposite. To me it so far looks worse conceptually and API-wise than what MS did, while still borrowing a lot of general async-await concepts and even C# and CLR specific concepts, but worse. Don't get me wrong, C# async-await and the CLR support for it has a lot of problematic areas too and is far from perfect and easy, aside from general async-await conceptual problems, but it doesn't seem to me like Loom is avoiding or solving those things, instead adding quite a few of their own warts on top. But as I said, my exposure to Loom is very limited, and it's not a final product yet anyways, so I may be very wrong here. Loom reminds me of when Java tried to copy a lot of collections-based LINQ stuff but did a terrible job doing so in my humble opinion (they since fixed some of the worst mistakes). Or maybe I am just biased, which is certainly a possibility. |
Very important to be able to run applications, not to develop them. I spent a few years doing dotnet development on Linux and have had enough of it (so I'm moving away to JVM which looks more and more interesting as long-term research projects and some language improvements land). It is very much a second class citizen. They still want to force developers use Windows and their tooling.