4 ms·

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

by rf15 4mo ago

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.

jbellis 4mo ago
It's no mystery. https://en.wikipedia.org/wiki/Anders_Hejlsberg https://en.wikipedia.org/wiki/Anders_Hejlsberg
- pjmlp 4mo ago
  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 4mo ago
    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 4mo ago
      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.
      - Rohansi 4mo ago
        They said the prototyped in a few languages before settling on Go. Based on what you said it sounds like they didn't do a great job at that and stuck with their decision anyway. > 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. It's been working fine for a few years now. The only problem I know is there is little to no reflection allowed (by design) so a lot of code out there is not compatible with it yet. Not sure if that's what turned the TypeScript team away from it.
        pjmlp 4mo ago
        Yes, see BUILD 2025 talk for example, the section on "extreme refactoring" regarding the ASTs, https://youtu.be/UJfF3-13aFo?t=1453 https://youtu.be/UJfF3-13aFo?t=1453 As for the AOT part, one would expect that being all Microsoft, they could work together to fix whatever were the issues with Native AOT.
amitport 4mo ago
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 4mo ago
  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 4mo ago
    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.
  - int_19h 4mo ago
    .NET had green threads (fibers) in its first iteration. They were abandoned because practical use of .NET was also FFI-heavy - WinForms etc - and native code generally doesn't play well with non-native threads. The benefit of async is that it desugars into callbacks with state, which is something that can be easily expressed in terms of the C ABI (which is the de facto interop standard on all mainstream platforms). Which is why you can have async C# code calling into async C++ or Rust code, or for that matter async Python calling into async C#. Given that .NET was historically supposed to be a multi-language runtime, before they went all in on C#, async made a lot of sense.
- lyu07282 4mo ago
  > 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#...
Someone 4mo ago
> 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)#History 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 4mo ago
  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.
  - cm2187 4mo ago
    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.
    - pjmlp 4mo ago
      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 4mo ago
        But if you define a new type, how is that breaking backward compatibility?
        pjmlp 4mo ago
deleted 4mo ago
[deleted]
za3faran 4mo ago
What things are you referring to? Especially after the many features that Java gained after Java 8.

by rf15 4mo ago

jbellis 4mo ago

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

pjmlp 4mo ago
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 4mo ago
  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 4mo ago
    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.
    - Rohansi 4mo ago
      They said the prototyped in a few languages before settling on Go. Based on what you said it sounds like they didn't do a great job at that and stuck with their decision anyway. > 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. It's been working fine for a few years now. The only problem I know is there is little to no reflection allowed (by design) so a lot of code out there is not compatible with it yet. Not sure if that's what turned the TypeScript team away from it.
      - pjmlp 4mo ago
        Yes, see BUILD 2025 talk for example, the section on "extreme refactoring" regarding the ASTs, https://youtu.be/UJfF3-13aFo?t=1453 https://youtu.be/UJfF3-13aFo?t=1453 As for the AOT part, one would expect that being all Microsoft, they could work together to fix whatever were the issues with Native AOT.

amitport 4mo ago

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 4mo ago
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 4mo ago
  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.
- int_19h 4mo ago
  .NET had green threads (fibers) in its first iteration. They were abandoned because practical use of .NET was also FFI-heavy - WinForms etc - and native code generally doesn't play well with non-native threads. The benefit of async is that it desugars into callbacks with state, which is something that can be easily expressed in terms of the C ABI (which is the de facto interop standard on all mainstream platforms). Which is why you can have async C# code calling into async C++ or Rust code, or for that matter async Python calling into async C#. Given that .NET was historically supposed to be a multi-language runtime, before they went all in on C#, async made a lot of sense.
lyu07282 4mo ago
> 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#...

Someone 4mo ago

> 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)#History 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 4mo ago
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.
- cm2187 4mo ago
  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.
  - pjmlp 4mo ago
    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 4mo ago
      But if you define a new type, how is that breaking backward compatibility?
      - pjmlp 4mo ago

deleted 4mo ago

[deleted]

za3faran 4mo ago

What things are you referring to? Especially after the many features that Java gained after Java 8.