I unfortunately encounter this mindset so much in Java programmers, and the similar "we don't need no feature X" even if the feature has proven themselves for a long time in a large amount of languages. I'm hesitant to bring it up, but I see a lot of Blub Paradox [1] among Java programmers. Heck, a lot of places disallow `var`, while over here in Kotlin-Python-Rust-C#-Typescript-Go-etc-land that's been the default since forever.
Taking this comment in good faith, the following language features from 9+ are incredibly useful for everyday programmers, you should give them a serious try before dismissing them:
Var is nice. But I generally prefer to not require people to jump out of the current code to figure out the type of a variable. And yeah, I've worked in those other languages, and navigating unfamiliar code with var everywhere can be confusing, so I try to avoid that kinda thing.
Records are nearly useless to me. Immutability is great, but I need a way to derive new sets of information based upon an set of information. And the only way to do that is bug prone.
Text blocks are nice for writing SQL queries and other multi-line things. But I'm not sure how often I actually use it.
Switch expressions are nice because it gets me compile time checking for things I would previously use a runtime check for. Other than that, as they currently exist, they're meh.
Sealed classes are something I've not had a use for. Maybe libraries will eventually make good use of them.
So I would say there's some nice QOL things in here. But I think "incredibly useful" is overselling it.
The thing is, lots of these things are built to support a longer term roadmap towards better support for data oriented programming. I think that is a worthwhile goal to drive for - and the sum of the parts (many of which are still in preview) will be less than the whole together - but we don't have the whole, yet. That, to me, would pass the "incredibly useful" bar.
`var` in Java is local for a reason. In most contexts I can think of the variable either was created above or was passed in as a parameter/object field. Unless you set it from a weirdly named creation pattern/function.
Regarding records, you never had someone update a POJO, add a field, and forget to update equals and hashCode?
Sealed classes are great for everything parsing/validation, in data modelling. They're not a solution for behavior polimorphism, but I don't think they were supposed to.
Taking this comment in good faith, the following language features from 9+ are incredibly useful for everyday programmers, you should give them a serious try before dismissing them:
- `var` local type inference
- record classes
- text blocks
- switch expressions
- sealed classes and interfaces
[1] http://paulgraham.com/avg.html