[pents90]

This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and harder to learn. Rapid changes to languages can also result in regrets, and it is essentially impossible to take something back in language development.

In general, I think too much stock is put into language features, perhaps because many developers are bored with the actual software they are writing/maintaining, and so new language features are relatively fun. As a mental experiment for those who know both Java and Kotlin, or both Java and Scala: Suppose you were asked to estimate the time required to implement a system in Java, and you arrived at an answer of 2 months. Now what would be your estimate for the same system, but written in Kotlin? How about Scala? Admit that it would be the same. (Well, probably a little longer for Scala, but just because it takes forever to compile, ha.)

[filereaper]

Brian Goetz the Java Language Architect addressed the very points you raised in a talk called "Stewardship: the Sobering Parts" [1]

I highly recommend anyone with these very valid concerns to view it once.

[1] https://www.youtube.com/watch?v=2y5Pv4yN0b0

[Latty]

I think that good languages offer features that make your code better, not let you write it faster.

Sure, it may take me two months to write that thing in Scala still, but I'll have more confidence it will work well, and it'll be nicer to read, maintain and work with moving forward.

Scala is an interesting example for this, because the language is a grab-bag of features that definitely can be abused by people who don't know better, it's definitely easy to write worse code in it.

The reality is there is an easy blueprint for Java, because C# is Java, but done better. It's moving at a good clip, but the features coming in are very useful and well thought out.

[x0x0]

Not to mention the implicit dismissal of developer happiness. That's one of the best things about the ruby and rails communities: why shouldn't our tools be nice to use? Kotlin has (imo) that same attitude as compared to java.

[crumbles]

> I think that good languages offer features that make your code better, not let you write it faster.

And great languages let you do both.

[brianwawok]

And what do you define as a great language?

Language greatness is pretty subjective and task specific. There are some languages I will never declare great (i.e. PHP, JavaScript, Ruby), but others could be great for different tasks..

[crumbles]

> Language greatness is pretty subjective and task specific. There are some languages I will never declare great

If greatness is subjective AND task specific, then the languages you will never declare great could be considered great by others for the tasks they perform. And by your own admission if they were great subjectively AND for a particular task, that would make those languages great. But, you still claim that you would never declare them great?

[1ba9115454]

> Now what would be your estimate for the same system, but written in Kotlin? How about Scala?

Perhaps the same, but the code is going to be much safer.

I think that is something you've missed we want features in Java that let us write more reliable code. Otherwise we will migrate.

I'm already starting the process of migrating to Kotlin for any Java work and I'm learning Haskell for side projects.

[SomeHacker44]

Common Lisp has moved forward exactly zero "officially" for decades. Yet, modern CL implementations are largely compatible with one another, largely interoperable with modern multicore hardware and multithreaded operating systems, largely capable of using Unicode and other representation formats, etc.

Of course, CL was designed with "extending CL" as a feature, and not locking the CL user into CL as it is "today." Shame so few other languages bother with this (Java and Clojure on the JVM come to mind immediately as hard to extend). Other languages have very active language evolution (Haskell/GHC comes to mind).

I like my languages to evolve. Preferably not the way Java did (I still hate the 1.5 type erasure hack).

[mreinhold]

I agree with what you say about language evolution, but this proposal isn't just about the language—it’s also about APIs, tools, and implementation-specific features (e.g., JITs and GCs), which can evolve more flexibly than the language itself.

[saosebastiao]

> Admit that it would be the same.

Sorry, can't do that. If my estimate was 2 months in Scala, it would be 6 months in Java: 2 to write the software, and 4 to find and chase down all the NPEs, casting exceptions, and concurrency bugs, while building a test kit for things the scala compiler already verified the moment my scala code compiled.

[ivan_gammel]

Last time I've had casting problem was when someone passed Scala Map to Freemarker. If it takes 4 extra months to debug NPEs, then someone still needs to learn how to code, because things that compiler can fix, experienced programmer should be able to do avoid at first place.

[saosebastiao]

That's what I hear. I personally think it's a shame that we have to live through years of terrible bugs in terrible languages just to become an experienced programmer that can finally know how to always avoid those mistakes in the first place.

If you're already there, great. I applaud your superior experience, and hope you really enjoy your C++ footguns. But don't tell me that the scala compiler doesn't have value to me just because you're a code god and don't need it. I actually benefit from languages that help me avoid stupid mistakes.