6 ms·

> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here. I agree. Th

> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here. I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentre/compute business at this point, with appendiges for its legacy activities and a vast overhang of debt. I sometimes wonder if the only parts of Oracle that are still profitable are the Legal and Lawnmower divisions.

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.
watwut 4mo ago
> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.
- andai 4mo ago
  I had the opposite experience, spent a year with each language, first Java then C#, and to me C# felt like "Java done right". (Which appeared to be the original design goal behind the language!) So I'm curious about your experience. To me it felt a bit less like a religion and more like a language. It didn't force me to do things a particular way, quite as much. (Still more than I would have liked, though! After all, it's called that[0] for a reason :) [0] https://www.reddit.com/r/ProgrammerHumor/comments/ddc4b0/microsoft_java/ https://www.reddit.com/r/ProgrammerHumor/comments/ddc4b0/mic...
- bazoom42 4mo ago
  What do you like about Java compared to C#?
  - watwut 4mo ago
    First, huge open source ecosystem and culture. Mature open source projects, culture of writing blogs and tutorials (that one will die due to changes in search engines, but it was super nice while it lasted). Second, working in C# felt clunky, as if every other thing was done to check the checkbox "done" and the author called it the day once it sorta kinda worked. There was some additional syntactic sugar in that language that was nice, but it did not made that much difference in practice and I don't miss it after coming back to java. Third, I found the obsession with bashing java by people who have no idea how java projects look like and which problems they have annoying.
- ivolimmen 4mo ago
  Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are: -Java always has an API, .NET is about extending an existing application (Servlet API vs IIS) -Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET). -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure). -Java's Eco-system is way bigger.
gf000 4mo ago
> The stewardship of Java seems rather lacking In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times from heap size. Like if anything, Java is at the best place it has ever been.
- lmm 4mo ago
  > They have added proper algebraic data types to the language No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.
  - _kidlike 4mo ago
    optional is not how algebraic data types are implemented in Java. Basically it's the combination of sealed types and records.
    - joe_mwangi 4mo ago
      Until they implement member patterns. https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns https://openjdk.org/projects/amber/design-notes/patterns/tow...
  - gf000 4mo ago
    Sealed classes/interfaces and records are proper sum and product types. The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java: ``` sealed class Maybe<T> permits Some, None { record Some<T>(T obj) {} record None() {} } ``` (You will probably have to write Maybe.Some and I might have messed up the generic syntax as I wrote it on my phone, but that's mostly how it looks)
pron 4mo ago
First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections. Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things: 1. Opinions about features are almost never universal, even among experts, and almost each of them is about a tradeoff where different people prefer different sides. It is rare that some scientific study settles the issue. 2. These preferences are often not evenly split. Even when both sides are equally confident that their preference is the right one, sometimes 80% or 90% of programmers share a preference. The people with the strongest opinions are more often than not in the minority, because most programmers don't think so much about the programming language (nor, I would say, should they). All of the language differences between .NET and Java fall in this "non-consensus" zone, and at least in one area I was deeply involved with, virtual thread, I can say that we thought that whatever we do we mustn't do what .NET did and that what they chose didn't work out well for them at all.
- nixon_why69 4mo ago
  Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.
  - gf000 4mo ago
    You can have a null int, it's called Integer. What was taken away is the other, identity-having functionality of Integer and similar (e.g. no synchronization).
  - tsimionescu 4mo ago
    This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.
pfannl 4mo ago
C# often feels like Java with hindsight; Java feels like Java with 30 years of backward compatibility debt.
- pjmlp 4mo ago
  Hence why so many .NET projects keep being .NET Framework instead having migrated to modern .NET.
  - donkeylazy456 4mo ago
    mostly they are sticking to .net standard 2.0 that is compatible both framework and modern.
pjmlp 4mo ago
Given the mess of some .NET frameworks currently, and how bad it has taken for non nullable references to be widely adopted, I don't see those correct decisions on the last releases. It is all about having AI on the framework, Aspire, multiple Web and Desktop frameworks all over the landscape. Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.
- drdexebtjl 4mo ago
  >Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either. Yeah. Even when they add new grammar nowadays, it's always just something that trivially sugars away into previous grammar (see: records, `with` clones, extension properties, required, etc). The moment they need something that it's slightly more complex... Out of scope. Even when it's completely necessary for the thing to be useful in practice. For example, they added `required`, `record`s and property initializers, giving us good reasons to write `new Foo { A = a, B = b }` instead of `new Foo(a, b)`. A and B must be positive, so you'd write: public required int A { get; init => field = value > 0 ? value : throw ... ; } public required int B { get; init => field = value > 0 ? value : throw ... ; } This is pretty standard C# code that you might see in an example for records. But then the requirements change: A and B must be positive, or they must both be zero at the same time. This cannot be expressed at all with initializers. You simply cannot add code that runs after all initializers are called. You're stuck chasing every single initialization of Foo and using a constructor or factory method instead. Shipped it as a public API? Too bad. Should have seen it coming! The new features are filled with this sort of thing. As if Microsoft never used them beyond the most basic examples. Or maybe they did, and explicitly chose not to fix it and solve later.
  - pjmlp 4mo ago
    I have this idea, that since they went open source, but failed to gain the adoption on UNIX shops they were expecting, there are tons of features to try to make it cool again somehow. The reality, and I can see this on my bubble, is that the .NET shops are mostly former Microsoft shops now saving Windows licenses by deploying on Linux. Stuff like MAUI remains pretty much constrained to former Xamarin customers. Thus minimal APIs, aspire, Blazor, and whatever comes up to support those use cases first. There are some podcast interviews from David Fowler and Maddy Montaquila where they touch the adoption issue among newer generations.
PaulHoule 4mo ago
.NET made different decisions. I was at a conference on scientific programming in Java very early on that Geoff Fox put on up at Syracuse and we had a list of requests from Sun that they didn't give us but Microsoft gave many of them right away. On the other hand I really like Java's all-virtual approach to inheritance because the .NET model gives programmers more ways to screw up and get confused. Both languages slipped in generics after 1.0. Java used type erasure in a way that made it so a List<String> is really a List so generics could be retrofitted easily to existing code. .NET's implementation of generics let you do more but caused a rift in the ecosystem between generic and non-generic collections. I'd say long term Oracle's stewardship of Java has been very good. JDK 8 puts lambdas on your fingertips with a very fluent syntax that belies the idea that Java is terribly verbose. Since then Java has gotten steadily better release after release while maintaining great compatibility. I work with people who are conservative about updates because they are worried about breaking things but for the last few LTS releases I've said "it ought to be really easy, let's give it a try" and it is really easy and we get performance improvements we can feel.
- rjrjrjrj 4mo ago
  Java stagnated for quite a while. Seemed like everyone was stuck on Java 6 for about a decade. But JDK8 was a huge step forward. Lambdas, streams, and a date/time API that is the best I've seen.
- to11mtm 4mo ago
  I think DotNet had a bit of benefit, in that the language was still new enough to do the hard breakage. It was only about 3.5 years between NET1.0 and 2.0 (Where generics were added.)
  - PaulHoule 4mo ago
    I was annoyed by it back when I was doing Silverlight/ASP.NET Thing was a lot of Microsoft APIs for GUIs and whatnot used the List and if you wanted to use the List<X> you had to copy the list or make a wrapper or something. You might say, "just use the List" but at that point (circa 2008) I had to also use the List<X> for some API so I always had to do some conversion.
drzaiusx11 4mo ago
I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.
- Zardoz84 4mo ago
  Type inference was on DLang far before that Kotlin even existed. The only difference it's that reuses "auto" keyword.
  - gf000 4mo ago
    I mean, type inference goes decades before Dlang.
  - drzaiusx11 4mo ago
    not claiming kotlin invented anything, just that after kotlin adopts something and it turns out to be useful, java will come along in a few years and implement it (or avoid it, depending on how it goes)
dingi 4mo ago
As someone who works with Java on a daily basis alongside a dozen other technology stacks, let me go out on a limb and say that I believe Oracle has been a stellar steward of the language. Java has been evolving quite nicely and at a reasonable pace, all without breaking the ecosystem or causing fragmentation. It certainly has its drawbacks, but doesn't everything?

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.

watwut 4mo ago

> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.

andai 4mo ago
I had the opposite experience, spent a year with each language, first Java then C#, and to me C# felt like "Java done right". (Which appeared to be the original design goal behind the language!) So I'm curious about your experience. To me it felt a bit less like a religion and more like a language. It didn't force me to do things a particular way, quite as much. (Still more than I would have liked, though! After all, it's called that[0] for a reason :) [0] https://www.reddit.com/r/ProgrammerHumor/comments/ddc4b0/microsoft_java/ https://www.reddit.com/r/ProgrammerHumor/comments/ddc4b0/mic...
bazoom42 4mo ago
What do you like about Java compared to C#?
- watwut 4mo ago
  First, huge open source ecosystem and culture. Mature open source projects, culture of writing blogs and tutorials (that one will die due to changes in search engines, but it was super nice while it lasted). Second, working in C# felt clunky, as if every other thing was done to check the checkbox "done" and the author called it the day once it sorta kinda worked. There was some additional syntactic sugar in that language that was nice, but it did not made that much difference in practice and I don't miss it after coming back to java. Third, I found the obsession with bashing java by people who have no idea how java projects look like and which problems they have annoying.
ivolimmen 4mo ago
Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are: -Java always has an API, .NET is about extending an existing application (Servlet API vs IIS) -Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET). -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure). -Java's Eco-system is way bigger.

gf000 4mo ago

> The stewardship of Java seems rather lacking In what way? If anything Java's main developers (employed by Oracle for the most part, working on the completely open source and free OpenJDK) are extremely knowledgeable and are responsible a big jump in how fast the platform evolves. They have added proper algebraic data types to the language, delivered virtual threads and garbage collectors that decouple pause times from heap size. Like if anything, Java is at the best place it has ever been.

lmm 4mo ago
> They have added proper algebraic data types to the language No they haven't. E.g. they added a class that superficially looks like Option but subtly breaks the rules that Option is meant to follow, ensuring that no-one can ever manage to migrate existing codebases away from using `null`.
- _kidlike 4mo ago
  optional is not how algebraic data types are implemented in Java. Basically it's the combination of sealed types and records.
  - joe_mwangi 4mo ago
    Until they implement member patterns. https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns https://openjdk.org/projects/amber/design-notes/patterns/tow...
- gf000 4mo ago
  Sealed classes/interfaces and records are proper sum and product types. The stdlib's Option type predates this language update by a long shot, so it doesn't use sealed classes, but it is now possible to have the usual FP "Maybe" type in Java: ``` sealed class Maybe<T> permits Some, None { record Some<T>(T obj) {} record None() {} } ``` (You will probably have to write Maybe.Some and I might have messed up the generic syntax as I wrote it on my phone, but that's mostly how it looks)

pron 4mo ago

First, your parent comment misunderstood what the section they were critiquing is referring to. It's not about nullability (which is orthogonal) but about reference/value projections. Now, as a member of the Java team (although I'm not directly involved in Valhalla), I'm obviously biased so let me just say that both designers and fans of programming language features would do well to remember two things: 1. Opinions about features are almost never universal, even among experts, and almost each of them is about a tradeoff where different people prefer different sides. It is rare that some scientific study settles the issue. 2. These preferences are often not evenly split. Even when both sides are equally confident that their preference is the right one, sometimes 80% or 90% of programmers share a preference. The people with the strongest opinions are more often than not in the minority, because most programmers don't think so much about the programming language (nor, I would say, should they). All of the language differences between .NET and Java fall in this "non-consensus" zone, and at least in one area I was deeply involved with, virtual thread, I can say that we thought that whatever we do we mustn't do what .NET did and that what they chose didn't work out well for them at all.

nixon_why69 4mo ago
Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.
- gf000 4mo ago
  You can have a null int, it's called Integer. What was taken away is the other, identity-having functionality of Integer and similar (e.g. no synchronization).
- tsimionescu 4mo ago
  This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.

pfannl 4mo ago

C# often feels like Java with hindsight; Java feels like Java with 30 years of backward compatibility debt.

pjmlp 4mo ago
Hence why so many .NET projects keep being .NET Framework instead having migrated to modern .NET.
- donkeylazy456 4mo ago
  mostly they are sticking to .net standard 2.0 that is compatible both framework and modern.

pjmlp 4mo ago

Given the mess of some .NET frameworks currently, and how bad it has taken for non nullable references to be widely adopted, I don't see those correct decisions on the last releases. It is all about having AI on the framework, Aspire, multiple Web and Desktop frameworks all over the landscape. Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either.

drdexebtjl 4mo ago
>Those interceptors and inline arrays via attributes instead of proper language grammar aren't that great either. Yeah. Even when they add new grammar nowadays, it's always just something that trivially sugars away into previous grammar (see: records, `with` clones, extension properties, required, etc). The moment they need something that it's slightly more complex... Out of scope. Even when it's completely necessary for the thing to be useful in practice. For example, they added `required`, `record`s and property initializers, giving us good reasons to write `new Foo { A = a, B = b }` instead of `new Foo(a, b)`. A and B must be positive, so you'd write: public required int A { get; init => field = value > 0 ? value : throw ... ; } public required int B { get; init => field = value > 0 ? value : throw ... ; } This is pretty standard C# code that you might see in an example for records. But then the requirements change: A and B must be positive, or they must both be zero at the same time. This cannot be expressed at all with initializers. You simply cannot add code that runs after all initializers are called. You're stuck chasing every single initialization of Foo and using a constructor or factory method instead. Shipped it as a public API? Too bad. Should have seen it coming! The new features are filled with this sort of thing. As if Microsoft never used them beyond the most basic examples. Or maybe they did, and explicitly chose not to fix it and solve later.
- pjmlp 4mo ago
  I have this idea, that since they went open source, but failed to gain the adoption on UNIX shops they were expecting, there are tons of features to try to make it cool again somehow. The reality, and I can see this on my bubble, is that the .NET shops are mostly former Microsoft shops now saving Windows licenses by deploying on Linux. Stuff like MAUI remains pretty much constrained to former Xamarin customers. Thus minimal APIs, aspire, Blazor, and whatever comes up to support those use cases first. There are some podcast interviews from David Fowler and Maddy Montaquila where they touch the adoption issue among newer generations.

PaulHoule 4mo ago

.NET made different decisions. I was at a conference on scientific programming in Java very early on that Geoff Fox put on up at Syracuse and we had a list of requests from Sun that they didn't give us but Microsoft gave many of them right away. On the other hand I really like Java's all-virtual approach to inheritance because the .NET model gives programmers more ways to screw up and get confused. Both languages slipped in generics after 1.0. Java used type erasure in a way that made it so a List<String> is really a List so generics could be retrofitted easily to existing code. .NET's implementation of generics let you do more but caused a rift in the ecosystem between generic and non-generic collections. I'd say long term Oracle's stewardship of Java has been very good. JDK 8 puts lambdas on your fingertips with a very fluent syntax that belies the idea that Java is terribly verbose. Since then Java has gotten steadily better release after release while maintaining great compatibility. I work with people who are conservative about updates because they are worried about breaking things but for the last few LTS releases I've said "it ought to be really easy, let's give it a try" and it is really easy and we get performance improvements we can feel.

rjrjrjrj 4mo ago
Java stagnated for quite a while. Seemed like everyone was stuck on Java 6 for about a decade. But JDK8 was a huge step forward. Lambdas, streams, and a date/time API that is the best I've seen.
to11mtm 4mo ago
I think DotNet had a bit of benefit, in that the language was still new enough to do the hard breakage. It was only about 3.5 years between NET1.0 and 2.0 (Where generics were added.)
- PaulHoule 4mo ago
  I was annoyed by it back when I was doing Silverlight/ASP.NET Thing was a lot of Microsoft APIs for GUIs and whatnot used the List and if you wanted to use the List<X> you had to copy the list or make a wrapper or something. You might say, "just use the List" but at that point (circa 2008) I had to also use the List<X> for some API so I always had to do some conversion.

drzaiusx11 4mo ago

I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.

Zardoz84 4mo ago
Type inference was on DLang far before that Kotlin even existed. The only difference it's that reuses "auto" keyword.
- gf000 4mo ago
  I mean, type inference goes decades before Dlang.
- drzaiusx11 4mo ago
  not claiming kotlin invented anything, just that after kotlin adopts something and it turns out to be useful, java will come along in a few years and implement it (or avoid it, depending on how it goes)

dingi 4mo ago

As someone who works with Java on a daily basis alongside a dozen other technology stacks, let me go out on a limb and say that I believe Oracle has been a stellar steward of the language. Java has been evolving quite nicely and at a reasonable pace, all without breaking the ecosystem or causing fragmentation. It certainly has its drawbacks, but doesn't everything?