How .net got so many things right where java did not is a mystery to me, but appreciated (it has its own flaws, of course). Java, in my understanding, is still of core relevance to Oracle, and tied into a lot of contracts that require very little effort from them to maintain. But you are correct in observing that they want to be a datacentre/compute business more and more these days; they may have in fact overcomitted to this due to the AI craze, since shareholders are already complaining.

▲

Someone 6 hours ago | parent | next [-]

> How .net got so many things right where java did not is a mystery to me

Part of the reason for that is that Java is older. https://en.wikipedia.org/wiki/C_Sharp_(programming_language)...:

“In interviews and technical papers, he has stated that flaws in most major programming languages (e.g. C++, Java, Delphi, and Smalltalk) drove the fundamentals of the Common Language Runtime (CLR), which, in turn, drove the design of the C# language.”

Also, some of Java’s design warts may be there because Java was initially envisioned for much smaller devices.

▲

toyg 5 hours ago | parent [-]

This. C# was basically always meant to be "Java but done right". It came several years later, after Microsoft was legally barred from "EEE"-ing Java and required a direct competitor.

▲

newsoftheday 2 hours ago | parent | next [-]

> It came several years later, after Microsoft was legally barred

That is an eloquent way of re-writing the history of Microsoft stealing Java and not being allowed to get away with it.

▲

toyg an hour ago | parent [-]

They didn't "steal" anything, iirc; they started as a legitimate licensee and then tried their usual embrace/extend/extinguish as "J++" (the EEE I mentioned). Sun sued for breach of license and won, barring Microsoft from extending Java outside of the (Sun-controlled) process. So they dropped it and built their own version, with blackjack and hookers.

	▲	dingi 12 minutes ago \| parent [-]
		> So they dropped it and built their own version, with blackjack and hookers. This cracked me up

▲

cm2187 4 hours ago | parent | prev | next [-]

But what I don’t get reading the original article is that they present how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.

▲

Someone 4 hours ago | parent | next [-]

> how to insert struct in an object oriented language as an intractable problem, whereas a good implementation with .net (as far as I can tell) has been out there for nearly 30 years. And C# was shameless about stealing from other languages.

I think (but may be wrong) their concerns are about the insert part. C# always had structs, Java wants to add them in a backward-compatible way. They want, for example, existing generic container classes pulled in from a .jar (i.e. already compiled) to support Java value types.

▲

pjmlp 4 hours ago | parent | prev | next [-]

The problem is how to do it without breaking ABI, 30 years of Maven Central is very relevant, Java isn't doing a Python over value types.

▲

cm2187 3 hours ago | parent [-]

But if you define a new type, how is that breaking backward compatibility?

	▲	pjmlp 3 hours ago \| parent [-]
		Because that is missing the point. All the types that are value types in semantics, e.g. Optional, should be proper value types on Valhalla. Additionally, they should be compatible with existing code that expects them as parameters, fields,.... without being recompiled from source. If it is a complete new type without backwards compatibility, no one is going to adopt it, other than a few niche cases.

▲

Zardoz84 3 hours ago | parent | prev [-]

Dlang this this before. You have classes and struts, with different semantics.

▲

pjmlp 4 hours ago | parent | prev [-]

Ironically, they still do need Java for Azure, https://devblogs.microsoft.com/java

▲

jbellis 7 hours ago | parent | prev | next [-]

It's no mystery. https://en.wikipedia.org/wiki/Anders_Hejlsberg

▲

pjmlp 4 hours ago | parent [-]

Which recently decided that Go was a better option than C# for the Typescript rewrite, exactly because not all decisions were done correctly to make C# a better fit for the problem.

▲

Rohansi 2 hours ago | parent [-]

Go was chosen mainly because it aligned more with how the existing compiler is designed. They did not want to redesign the compiler which eliminated C# as a choice. So Go is apparently just a better fit for quickly porting JavaScript code to.

	▲	pjmlp an hour ago \| parent [-]
		That was the original motivation yes, although they acknowledged later that the weaker type system from Go required redesigning the data structures anyway. And as proven in the recent announcement, they had to rewrite parcel from C++ into Go, as they didn't found a comparable library in Go ecosystem. There is also another interview, where again they mention having used AI as tool for code rewriting as well. Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.

▲

5 hours ago | parent | prev | next [-]

[deleted]

▲

amitport 7 hours ago | parent | prev [-]

The mystery of why .NET got so many things right is simply that C# was built several years later by the exact same Microsoft engineers who had previously worked on extending Java, giving them a perfect blank slate to fix the architectural flaws they had already encountered

Second mover advantage.

▲

ah1508 2 hours ago | parent | next [-]

virtual thread instead of async/await is a counter example.

Java is more used than C#, they can wait before delivering a new feature (given their leader position) but cannot deliver a flawed implementation that would stay in the language forever. Glad to have virtual threads and the backward compatibility that comes with it instead a Async version of sync methods + async and await keywords all over the code and Task as a return type in my interfaces methods to allow implementations to do non blocking I/O calls if they need.

I use Java and C# and appreciate them both.

	▲	amitport 33 minutes ago \| parent [-]
		C# did not ship with async/await, and Java didn't have virtual threads back then. I am specifically referring to the initial choices made in C#'s foundation.

▲

lyu07282 4 minutes ago | parent | prev [-]

> giving them a perfect blank slate to fix the architectural flaws they had already encountered

and then they make everything nullable by default in c#...