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.

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.

As for structs, Java avoids e.g. tearing issues with making them immutable, while it is easy to optimize it to local modification under the hood.

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.

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

This cracked me up

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.

> 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.

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.

Second mover advantage.

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.

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

Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.

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/mic...

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.

  -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.

How do you expect this to work then? If the provider is bad, blaming LINQ for it makes no sense...

You either have a high level of abstraction and possible performance pitfalls - or a low level of abstraction, and also performance pitfalls since the code is less modular, more coupled and harder to read.

LINQ can in many cases improve performance significantly in large applications when used properly, since it avoids N+1 query problems due to implementation hiding/modularity, and allows composing parts of queries across different vertical subsystems of the application (vs. each subsystem doing its own query and then joining them with more boilerplate).

Nothing in Java compares to this. jOOQ and Hibernate (and the rest in the ORM ecosystem) are pale shadows, exactly due to lacking language features (such as reified expression trees), and even then, they only work with databases.

Yes Java does not have an alternative for Linq and jooq is a poor knock-off compared to this but then again: I do not care much for JPA/Hibernate.

I don't think this is true anymore since ASP.NET Core. While you can still run under IIS but it's a more typical reverse proxy setup instead of running inside IIS.

> You can't wrap streams in .NET

You've always been able to wrap streams in .NET so I'm not sure what you mean by this

If we want to compress a file we normally just wrap the file ouputstream in a GZIPOutputStream so we add features by wrapping it.

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.

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`.

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)

The main difference is that (T | Null) | Null = T | Null, while Maybe<Maybe<T>> is different from Maybe<T>

First, a record can't extend anything, it's not even valid syntax, so a sealed class can't permit record subclasses. So no, it's not possible to create a Maybe<T> class in Java that can only represent a Some<T> or a None<T> record. You could do it with regular classes, or if it's ok for Maybe<T> to be an interface.

Secondly, regardless of the sealing, nothing in any current or near future of Java prevents you from assigning `null` to any class of any kind you might create. So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`.

None of this will change with the adoption of value classes either. So no, there is absolutely no way in Java to create a real Optional/Maybe type that would guarantee that a variable is either an object of a given type or None. There is probably some way to do it for your specific project using annotation processors, of course, but that is very different from having built-in support.

> So you can always have `Maybe<T> x = null`, or even `Some<T> x = null`.

Yeah and? Practically every type system have escape hatches, like Haskell can also do side effects without the IO monad, does it make the latter useless?

This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't help with at all.

Well wasn't that the argument above, that the stuff they added so far isn't proper at least in part because they didn't fix that problem yet?

And a promise to eventually fix a busted implementation doesn't undo it being busted for a significant amount of time.

Types are both for the compiler, as well as for the developer. Maybe types are implicit documentation telling the developer that it is meaningful in the application that this field can have a None state.

That's a huge code smell to ever set null to an Optional/Maybe and code reviews, linters, nullness analyzers all should/will flag such.

Like I have never ever had an NPE from an Optional being null. Sure, complete null safety would be better of course, but in this very instance it ain't buying you much.

Use a regular class to signal that you may or may not have a value.

Wrap it in an optional to signal that you may or may not have a value.

See the problem?

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.

As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best technical in-memory representation for each use. For example, the compiler could choose not to flatten variables that could be null in the heap but to flatten them in the stack. That's the general idea, but I'm not sure about the details, some of which may yet change.

More generally than just Java, nullability is often a property not of a type but of a variable. For example, in C, an int may not be null, but a pointer to an int may be. Now, in C, `int` and `int*` are two different types, but that's exactly a distinction that the original projection-spit design made and we wanted to avoid. But you could still end up with a variable that could hold either an integer or a null and another that may hold an integer but not a null, only this is separate from the reference/value projection, which combines both identity and nullability (in C, `int*` is not only nullable, but also has identity).

This is a tangent, but I'm not sure I follow this. Can you give an example to make this clear?

In Java, you can ask, `x instanceof T` (and this is a runtime test), which means, is x one of the values in the set of values allowed by T. `null instanceof Integer` is false, even though a variable of type `Integer` can be assigned a null. So you can think of `Integer x` as being `Integer|null x`, i.e. x can hold a null, even though `null instancof Integer` is false.

    type Foo = { x: number; }
    type Bar = { x: number; y: number }
    type FooBar = Foo | Bar;
    function baz(x: FooBar) {
      if ('y' in x) {
        // compiler now knows x is a Bar
      }
    }

I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards.

I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the language.

Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types.

Declaring whole types as non-nullable is less noisy and errorprone than annotating every variable declaration. If you aren't going to give me "declare the whole codebase as non-nullable" then at least give me something coarse-grained.

Then you didn't read the JEP draft (it's not an accepted JEP) carefully. It says, under "future work":

Providing a mechanism in the language to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.

In other words, the draft already incorporates your point, but JEPs (both drafts and actual JEPs) follow the pattern we've found to work so well, that features are best delivered piecemeal rather than in a big bang.

Having said that, I don't know the current plans for this matter, as that document is only in Draft status, so saying it's good or bad is pointless, as it's not even a proposal yet, just something being explored.

I don't think this syntax is desirable as currently proposed, and that one line under "future work" is doing far too much lifting. My sincere hope is that there are people closer to the process that also feel this way, they will provide similar feedback, and the next draft will be something completely different.

So consider that draft as an idea for how the site-specific nullability annotations could work rather than an idea for how nullability could work in the language in general.

That's fine but it's still a bad choice. The problem is that it defaults to everything nullable and adds noise for non-nullable. This is backwards; in the overwhelming majority of software that people use Java for, non-null is the common case and nullability is the exception.

Kotlin and Typescript got this right. Nobody wants! to! write code! like! this! And they won't, so the feature won't get used and we're back to everything being nullable.

Except there's no choice here. It's a draft of an exploration of a portion of a feature.

Drafts are ideas that have not even been submitted for consideration for inclusion in the roadmap. You can find drafts over ten years old that have long since been superseded by other ones or abandoned altogether: https://openjdk.org/jeps/0#Draft-JEPs. Some JDK engineers write JEP drafts when they feel they get close to something they would like to propose, while others write drafts for pretty much any idea they have.

> The problem is that it defaults to everything nullable and adds noise for non-nullable

It doesn't, though. Even if this draft ever becomes a JEP (and I don't know if it or anything like it will), in its present form or another, it would still, like most JEPs, describe only part of the feature. It's perfectly on point for one JEP to describe the explicit nullability annotations, while another describes the defaults. Smaller features than this have been split into two or three JEPs. This is just how Java features have been described and delivered for years now (see how many JEPs patterns were split into: https://openjdk.org/jeps/0).

It's perfectly okay to dislike some design, but I find it strange to assume, based on a draft of a portion of a feature that one of the most experienced and successful programming language design teams in the history of software is likely to get it wrong. Maybe wait until there's an actual proposal and a roadmap for the complete feature before critiquing it? It's like seeing a draft of some building's foundations by a prestigious architectural firm and saying, these idiots forgot to plan a roof.

I'm not saying that the people who wrote this are dumb, or that Java is a bad language, or that it's time to move to Kotlin, etc. I use Java every day. I pick Java for greenfield projects. I'm on Team Java.

I'm saying I don't like this proposal. I happily accept that this proposal might not become part of the Java language. That's great! I'm spending time writing this in public specifically to discourage it in some tiny way.

It would be fair to tell me "you should write this to the proposal writers directly". And I understand how the language snobbery on HN might make you feel defensive - I often feel that too. But I think my criticism here is valid.

And I'm trying to tell you that this document is not what you think it is. It's a rough sketch of a building's foundations and your critique is about the roof. Even if this were to become a proposal, it's likely the matter of defaults of this feature will be covered by a different JEP, because Java features are usually broken down into multiple JEPs. What you're complaining about may be part of the feature, but it is not covered by this document. If this becomes a JEP and another JEP talks about nullabilty defaults, then you could criticise the selection of defaults, but that particular aspect of this feature is outside the scope of this particular document. So one, this is not a proposal, and two, you haven't seen the description of the part of the feature you want to criticise.

We are well aware that splitting features over multiple JEPs can invite such misunderstandings, but that doesn't change the fact that Java features are, at least currently, split over multiple JEPs. We are also well aware that if this does become a proposal, adding ! everywhere is not what we want, but we want to cover that aspect in a different document, as we usually do. Most Java users aren't confused by this because they don't read the JEPs at all, but such splits help focus the discussion on one aspect of a feature at a time. So your desire for a non-nullable default is very understandable, it's just not relevant as a critique of this document.

For example, the virtual threads JEP described a pinning limitation. We knew it reduced the applicability of that JEP and said as much. We just wanted to address it in a different JEP, and so we did (https://openjdk.org/jeps/491). Ever since the JDK switched to time-boxed, semiannual releases, this is how we've delivered features: in multiple pieces. The same applies to Valhalla.

What was taken away is the other, identity-having functionality of Integer and similar (e.g. no synchronization).

These people may point out that languages become more or less successful not because of the things these people care about but because of other factors. And they're right, but then the question is, shouldn't a smart product team focus more on the things that actually matter more to more people?

Programming languages are tools, and so their value is not intrinsic, but comes from the value of the software they're used to create. Now, some people claim that Java's success is largely the result of it being one of the most hyped languages of the late 90s and early 00s, alongside VB, Delphi, FoxPro, and C#. But this claim doesn't stand up to even the slightest scrutiny.

  An alternative solution to that of fibers to concurrency's simplicity vs. performance issue is known as async/await, and has been adopted by C# and Node.js, and will likely be adopted by standard JavaScript. Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.

  While implementing async/await is easier than full-blown continuations and fibers, that solution falls far too short of addressing the problem. While async/await makes code simpler and gives it the appearance of normal, sequential code, like asynchronous code it still requires significant changes to existing code, explicit support in libraries, and does not interoperate well with synchronous code. In other words, it does not solve what's known as the "colored function" problem.

This is true in some languages but not in Java. The limitations (and performance cost) are not from the nature of continuations/stackful coroutines/"colourless functions", but from their interaction with other constraints and existing designs in the language. E.g. in Java, virtual threads have zero impact on FFI.

In general, the costs and limitations associated with a feature in language X don't extrapolate to language Y, because they often stem from interaction with existing constraints in language X.

The design of FFI is a very common source of problems for various features. For example, if the FFI is designed such that you frequently pass pointers to to objects to C, that can have a big impact on other features. In Java, you nearly always only pass pointers to "off heap" memory, i.e. memory that's not managed directly by the JVM. While this has no performance cost, you could say that this, in itself, has some convenience cost, except Java programs need to rely on FFI much less than other languages, so the overall cost to convenience is low.

But 1. there's no speed penalty in Java for doing that, and 2. In Java, calling native functions that block (which is the only time this limitation matters) is rare, especially in high concurrency situations where you'd use virtual threads in the first place.

Structure concurrency/virtual threads seem like a good fit for Swing; just have your event handler fire off virtual thread[s] and do your work and call SwingUtilities.invokeLater to schedule the result to be applied on the event loop thread when you're done. Structured concurrency simplifies managing groups of concurrent tasks, cancelation, etc.

You still can't block in UI code, right? You don't know whether you're on a virtual thread or the UI thread (even if its virtual) by design. You still have to bifurcate your APIs into blocking and non-blocking, don't you? Virtual threads will help you keeping the CPU fed but it won't handle separating UI and non-UI work, or know when a frame deadline ends.

Have there been Swing specific updates to deal with that?

Curious if you think fibers vs async/await is still in this zone (amongst experts). It seems fibers are objectively better. But I'm no expert*

The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties.

Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.

Structs, Shared Structs, and Synchronization Primitives

There are a few things that would be required to make it all work, this would be one of them.

"All differences are opinions....except what .net did. Those are wrong!"

I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again.

Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse.

It's probably exactly because of the "not like .NET! We must be different to explain being late" mentality.

It felt like magic, maybe too much magic, but so useful nevertheless.

They have different philosophies though, C# is mostly "give the developer a complex toolkit so they can do whatever they want, but keep the runtime simple", while Java is more like "keep the language as simple as possible, and put new features mostly into the runtime making it more complex, but benefiting even old code".

Async vs virtual threads is a clear example of that. The former makes the language much more complex, and has a huge surface area where it may clash with other features, so a developer has to remember all of these. But it's a simple machinery under the hood.

Meanwhile virtual threads don't change the language at all, it's the same as it was with Threads, but under the hood it is a very complex feature.

And in this particular instance I think it is quite clear cut that Java made the correct decision, for the most common use case of these languages having non-blocking IO "automatically" makes for significantly better user experience.

For things like UI programming where you need a main thread or where you do need a cross language OS thread, I think Java is going to end up more complex. Under the hood it is very complex and that _will_ show itself.

So from my perspective it's not virtual threads, it's virtual threads with structured concurrency vs async/await. When you look at it that way, the comparison of complexity is certainly not seamless or simple.

But that doesn't mean the preferences are equally distributed. Some people liked Betamax's better picture quality while others liked VHS's better recording times, but they didn't do it in equal numbers. And that's what's funny, because there are two languages doing as well as Java or better (one of them is much more popular), and yet what's almost universal is that when people say "Java is worse than X", X is invariably a language that's doing much worse than Java.

I'm not saying that there isn't much to learn from less popular languages, but the claim "Java is consistently making the wrong decisions compared X" doesn't make sense when X is consistently losing to Java.

And I can even give you the secret to our strategy: Make Java the language that people who choose it regret less than people who choose other languages.

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.

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 ... ; }

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.

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.

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.

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.

Then, when WinForms or WPF wanted a list, you could just give it a List<T> instance, and it would talk to it via IList, boxing and unboxing if necessary.

What you describe happened in the other direction - if you had, say, a generic method operating on IEnumerable<T> or IList<T>, and wanted to pass it a WinForms collection. WinForms generally defined strongly typed collection classes on a case by case basis, but none of them implemented the new interfaces. It was there where you had to wrap things, most often using AsEnumerable<T>().