[pron]

The gap between Java and C# has grown very slowly but surely for many years, and more people feel Java is changing too quickly than too slowly. Different people prefer different things, some will always prefer Pepsi (although C# will probably not be that Pepsi, as it's lost too much ground and MS seems to be losing interest in it, as they tend to do), and our goal isn't to adopt the strategy of less successful products, but to forge our own, even if some on HN have other ideas.

[dmitriid]

> it's lost too much ground and MS seems to be losing interest in it

wat

> our goal isn't to adopt the strategy of less successful products

This sounds like "we don't care if some other languages have great quality of life improvements, we pretend that success (for some unknown definition of success) is the only thing that matters, so we'll keep implementing one or two features every 10 years that don't work with half the language and standard lib, and still require hundreds of lines of boilerplate to work with."

In a sibling comment you're pretending that withers is a thing that will ever happen. It won't, not for another ten years. Meanwhile we're left with a language that has to resort things like Lombok to try and cut down on the ridiculous amounts of code one still has to write for even the simplest things. Or almost but not quite incompatible lists and collections (none of which have even a pretence of a DX for easy construction). Or value types that have been a proposal for 9 years, and generics with primitive types that has been a proposal for 7. And the list (or collection? or stream? or?...) just goes on and on and on.

Thank god we finally got multiline text blocks and some form of pattern matching. Wait. Those come from less successful languages. How could you?

[pron]

> wat

Their focus seems to have shifted to TypeScript, and that's understandable as they have far better chances for success there. Their best hope for .NET was to make it the Pepsi to Java's Coke, but that hasn't materialised (in fact, it's getting further away). .NET has not been anywhere near the go-to alternative choice for people who just don't want Java for one reason or another in years.

> This sounds like "we don't care if some other languages have great quality of life improvements

I'm sorry it sounds that way to you. It means, "we understand that some portion of developers prefer more features, but we cater to the majority, and, given that Java has a very long future, we'd rather pace ourselves." For the quick-feature-loving minority -- which we also care about -- we make sure the platform can host more feature-rich languages that interop well.

> It won't, not for another ten years.

You're very wrong about that. Remember that only five years ago, Java didn't have var, didn't have switch expressions, didn't have text blocks, didn't have records, didn't have sealed classes, and didn't have pattern matching. More people complain that Java is getting new features too quickly than too slowly.

> Wait. Those come from less successful languages. How could you?

It's not that we don't adopt features from less successful language; it's that we don't copy their evolution strategy. Our goal isn't just to make sure Java is very popular now, but also that it's very popular ten and even twenty years from now. This means that we have to budget language complexity very carefully. We also have the new developers learning Java in 2035 to think of.

[dmitriid]

> Their focus seems to have shifted to TypeScript

C# 9 has more features in the release (one year after the release of C# 8) than java had in the past five years.

Whatever "seems" to you, it clearly isn't true.

> > It won't, not for another ten years.

> You're very wrong about that. Remember that only five years ago, Java didn't have var, didn't have switch expressions, didn't have text blocks, didn't have records, didn't have sealed classes, and didn't have pattern matching.

Me: Java is moving too slowly

You: no-no. Some people even think we're moving too fast. Here, we have five features in five years. Some of those features should've been there 20 years ago.

> it's that we don't copy their evolution strategy.

It's a great delusion. Java's development is abysmally slow. It has nothing to do with "quick-feature-loving minority" as you so condescendingly put.

Java moves in fits and starts, taking 5-10 years to add some features that often don't fit with either the rest of the language, or with half of the standard library. Almost literally everything takes near a magnitude more boilerplate to write and develop than it should. And when it's not, it's only available to some parts of the lang, and not to the other.

But when you express concern about this? Oh, then you're a "quick-feature-loving minority", and not a developer earning their living with Java and hoping for any meaningful improvement to it.

Oh, I'm sorry. I'm not smart enough to understand why a possible solution to tolstoyesque method chaining calls that will maybe come to Java in 10 years is "evolution of the language", but literally the same solution to collections (and unifying lists and arrays) is "a quick feature from less successful languages, and we don't adopt evolution strategies from those".

As I don't understand a hundred other things that can elevate Java-the-language from mediocre to great.

[pron]

> C# 9 has more features in the release (one year after the release of C# 8) than java had in the past five years.

Not even close. They're adding small features to the language, while Java adds huge features to the runtime. .NET is 10-15 years behind Java on the runtime. Roughly speaking, Java's philosophy (going back to Gosling) has been to innovate on the runtime and keep the language conservative, while .NET's has been to add a lot of features to the language and keep the runtime relatively crude. There is no indication that changing our strategy would be a wise move.

> Some people even think we're moving too fast. Here, we have five features in five years.

Not some; most. Most people prefer fewer than five features in five years, even though many prefer more. I really wish we could make both you and the others happy, but I don't see how we can do that other than what we're already doing: have Java be the popular mainstream language, and support other languages on the platform for those who prefer something else.

> Some of those features should've been there 20 years ago.

Should have been there so that what? Or at the expense of what? Our goal is to build a successful language used by millions, not to push the envelope in programming language design (although we are pushing the envelope in runtime design). We introduce features when we think mainstream programmers could use them in the best way, and we add them slowly enough so that we're not overtaken by fashion and we have room to grow for decades. You may not like it, it's okay, and it's even perfectly reasonable. But this has worked really, really well.

> It's a great delusion.

Fine. Maybe you have more access to market data than we do. Fact of the matter is, no other language is doing any better, and Java has fewer serious competitors today than it did in the last 15 years.

> But when you express concern about this?

I am not dismissing your concerns. I am merely explaining that we have about ten million other developers we cater to aside from you, and they don't all share your opinions. Your views are far from unique, and we are well aware that many people want the language to evolve faster -- and that's perfectly legitimate although I personally don't think it's a good idea for such a popular language -- but even more don't.

[dmitriid]

> we think mainstream programmers could use them in the best way, and we add them slowly enough so that we're not overtaken by fashion and we have room to grow for decades

Ah yes. Using a single common way to initalize things and unifying arrays and lists (so that you don't need helper modules, and you don't have to rely on the kindness of libs to provide .of methods) is "fashion" (as are many other things).

But "yeah, we will maybe some day 10-20 years from now provide a way to build records, and only records, in a way that doesn't require hundreds of lines of boilerplate", that's long-term strategic planning and evolution.

Well, we're talking past each other. I'm well aware that any change in a language the scale of Java is a daunting task. But the condescending tone that dismisses something as "features for the quick-feature-mided fashion crowd" clearly shows that it's not these concerns that drive these decisions, but purely subjective outlook on things.

[pron]

I am not dismissing you just pointing out that while your preferences are reasonable, legitimate, and are shared by many, they are also far from universal. I'm a developer, not a diplomat or a marketing person, and if different people ask for opposite things, I don't know how I can say yes to both.

I think that being honest about our strategy that dates back to Java's inception -- an innovative runtime and a conservative, slow-changing language -- that has worked well for us and so we're sticking to is more respectful than giving you some non-committal marketing response. I think you should also be respectful and understand that the Java language team is one of the most successful and experienced language design teams in the world and know what they're doing, even when people might disagree with some decisions. Even experts disagree, and people have different tastes (I find C# and contemporary Kotlin positively garish, while I think Clojure and Zig are elegant and beautiful).

And the language features Java does intend to adopt will come quickly, just as the smallish-medium ones over the last few years have. I believe lambdas were the only language feature that took more than a couple of years to deliver. Once the language team decide they want a feature, they deliver quite quickly. The features that take a long time are usually changes to the runtime (what I mostly work on), not just the language.

[int_19h]

Are you saying that e.g. pattern matching is a "small feature"?

As far as runtimes... CLR bytecode is expressive enough to compile C++ into it. Try that with JVM.