Ever since LINQ, maybe even before that, I feel Java is a more boring C# clone. C# keeps innovating their language (borrowing a lot of times from other languages, of course), and then java seems to look and wait and do a half-assed implementation of a lot of tried-and-true C# language features some years later.
Java had two tech advantages over C#: It officially ran on platforms other than Windows and ran well, and their JVM was far ahead of the MS CLR.
Both of these things went away/are going away.
What really remains is Java's reputation over "Embrace, Extend, Extinguish Microsoft" (tho Oracle has been busy trying to destroy Java's reputation ever since they bought Sun) and the larger eco-system/community/existing code bases and sunk costs.
JVM's garbage collectors are at least a decade worth of effort ahead of CLR. I am talking out of my ass here, but from reading people working on large projects JVM has no problem chewing through multi-terabyte large heaps. The recently introduced collectors (Shenandoah and ZGC) even keep the same pause times (something like 99 percentile within 1 ms and 99.9 within 10 ms). The largest heap you might be able to use under CLR without ridiculous GC pauses and overhead is around 200 GB. Yes, value types and Span<T>/whatever lower the GC pressure, but not by a factor of 10×, and value types are coming soon™ anyway.
That's all of no use to me (I don't work on projects like that), but let's not just shove that aside.
I also don't really agree with this:
> look and wait and do a half-assed implementation of a lot of tried-and-true C# language features some years later
Loom looks like a much more interesting approach compared to async/await hell (I've done it enough to know). I like records and upcoming "withers" much more than { get; set; } (which is easy to write but promotes shit code) because of their focus on immutability. (Yes, I am aware of { get; } and recently introduced { get; init; }, it doesn't really help with the thing withers are trying to solve — copying most fields while replacing one or two values, keeping both the old and the new value immutable). LINQ? maybe, I miss expression trees in Java.
Had Oracle not bought Sun, Java would have died in version 6, and MaximeVM would never had become GraalVM.
There weren't other buyers in town, besides IBM, which I probably would have managed it just as Oracle has, given that the trio have been around in Java world since the early days.
Maybe, maybe not. Google was already heavily invested in java with Android. And lots of other places were too. If Oracle hadn't bought it, Google or one of the others might have bought java specifically from Sun. Or may have just let java die and be reborn as an "open source foundation" as they are en vogue now (which to some degree happened anyway, with the proliferation of the OpenJDK).
Reflection does away the need to manually implement serializers. In a growing codebase where data models transform and references to those models begin to rot, that is incredibly useful.
Serialization libraries need to be decoupled from the records being serialized. These two things are compiled into different assemblies, and often written by different people.
Still possible to replace with compile time codegen, but the implementation gonna be complicated and fragile.
There are anonymous types for intermediate results in the linq stream. And since they are anonymous types you need the c
var keyword when working with the outcome.
….All these years and I’ve never known about Anonymous types. I know about records and dynamic objects. I’m guessing they aren’t used often because I have yet to find them.
Java had two tech advantages over C#: It officially ran on platforms other than Windows and ran well, and their JVM was far ahead of the MS CLR.
Both of these things went away/are going away.
What really remains is Java's reputation over "Embrace, Extend, Extinguish Microsoft" (tho Oracle has been busy trying to destroy Java's reputation ever since they bought Sun) and the larger eco-system/community/existing code bases and sunk costs.