Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New language features since Java 8 to 17

advancedweb.hu

Post reply on HN
Print view View original

271–280 of 358 posts

Re: New language features since Java 8 to 17

#271

Post by dmitriid »

pron wrote: post #160
66fm472tjy7 wrote: post #59

Earlier quoted context omitted.

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collection…

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

> will lead to better development practices, rather than making it easier to work with inferior ones.

C# has these "inferior practices" and is a much better language overall. Why Java doesn't adopt the low and not-so-low hanging fruit from C# is really baffling.

Anything from yes, properties, to object initialization shortcuts and a sane IEnumerable/Collection interface that doesn't require stream/toList everywhere.

Re: New language features since Java 8 to 17

#272

Post by dmitriid »

pron wrote: post #211
xpressvideoz wrote: post #204

Earlier quoted context omitted.

I can understand the hate behind null-safe operators, but why properties? Why is bad to have an ability to "upgrade" a member variable into a property, without breaking any existing contracts? I really hate that I need to resort to using setters and getters in Java because those are bad for searchability.

Properties are probably the worst feature on that list, and no experienced language designer would add them to Java. They make it easier to work with setters, while the goal is to reduce their usage altogether! Records achieve that much better. Unencapsulated component access is standardised on classes with good contracts (construction and deconstruction are duals for records) and will work well with patterns, all wh…

> instead, we'll have "withers" or "reconstructors

When?

> On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet.

Java "dodged it" by never even having to fight. While C#'s "poor choices" are leading to a language with less and less boilerplate with almost each year, in Java we'll have to wait another 10 years before it delivers half of a half of the "withers" functionality that doesn't work with half of existing standard library code (the way arrays, lists and collections are three non-intersecting entities).

Re: New language features since Java 8 to 17

#273

Post by jpgvm »

perl4ever wrote: post #195
jpgvm wrote: post #56

Earlier quoted context omitted.

I don't think Scala ever could have filled that niche, I say this as someone that wanted Scala to be successful. The truth of it is that Kotlin is incredibly easy to learn, even for non-Java devs. It is definitely focused on a very low barrier to entry. I don't think this was an original goal but it's become a significant focus of the language especially after being selected to be the next platform language for Andro…

>The truth of it is that Kotlin is incredibly easy to learn That's not my truth. I tried it, after not doing "real" programming for a while, and found it the most obfuscated, incomprehensible language I've ever run into. What new concepts are there in Kotlin that justify it? "Expressiveness" sounds toxic to me - along the lines of "facilitates a personal idiom that makes your code impossible to understand and you irr…

Yeah I'm not going to argue that Java and C# aren't smaller languages than Kotlin, they definitely are and I like/appreciate both.

I'm surprised you feel Kotlin is incomphrensible though, it definitely can be written that way because it has features that allow for extreme terseness.

I think there is a minimal set of things you need to learn over Java for Kotlin to make sense, nullability operators, block passing syntax and the differences in OOP (inheritance/interfaces are slightly different, classes are closed by default, companion objects replace static methods).

So yeah. Kotlin is strictly larger than Java so it takes longer to learn all of it.

That said because of the look and feel of Kotlin it's more accessible to developers of Ruby/Python/JS/Typescript. This tradeoff is personally worth it for me.

Not because I care that much, I can just as easily use Java. However it's -very- difficult in modern times to convince my team and company to use Java when there is hipster options like Typescript taking all the air out of the room. Kotlin competes in the same area but provides the same battle tested runtime and excelent libraries, it's almost like a compromise between the new age and the old age.

This is why it's such a great language for me in particular but I realize not everyone is in the same boat.

Re: New language features since Java 8 to 17

#274

Post by pulse7 »

p2t2p wrote: post #212

Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and thin…

I've seen projects where the whole architecture/design was screwed just because someone wanted to mock >>everything<< during unit testing...

Re: New language features since Java 8 to 17

#275

Post by kaba0 »

grumpyprole wrote: post #83
jmfldn wrote: post #61

Earlier quoted context omitted.

I hear this a lot about Scala, and I am a Scala dev so maybe I'm biased, but I don't get the difficulty angle particularly. I'm in no way exceptional as a programmer or IQ-wise but I picked up Scala easily as part of my first job. The difficulty thing doesn't compute to me but it could just be that I'm well-suited to the language. It works beautifully as a better Java if that's how you wish to use it. Granted, it mig…

The first time I tried Scala, I got a type error based on the result of an implicit conversion, which succeeded locally but not for the entire expression. It took me a while to figure out what had happened. Advanced (mis) features such as this combined with encoding everything into objects with subtyping make Scala very complex. F# and OCaml are examples of much simpler languages that have most of the advantages (alb…

Implicits were majorly revamped in Scala 3, so do give it a look if you hadn’t already!

Re: New language features since Java 8 to 17

#276

Post by kaba0 »

xvilka wrote: post #236
hota_mazi wrote: post #113

Earlier quoted context omitted.

Android is based on the JVM, it will never switch to Flutter (and an aggravating factor is that Dart is an inferior version of Kotlin).

Java is an Android's curse. Just compare how completely native iOS and iPadOS beat it in terms of speed and power saving. I hope they will get rid of the Java remnants completely and focus on the native toolchain, frameworks, system libraries.

Android doesn’t run java though? It runs native code the same way as ios, so bringing the latter ecosystem’s better performance into the picture without considering the generational leap in terms of CPU design is just a faulty logical conclusion.

Re: New language features since Java 8 to 17

#277

Post by kaba0 »

zorr wrote: post #78
hocuspocus wrote: post #60

Earlier quoted context omitted.

Scala is fine. People understood it's not really worth it as a "better Java". Companies that choose Scala in 2021 are using either big data frameworks (where Python bindings are the most common alternative to Scala, not Java), or functional ecosystems (Typelevel, Zio). Scala 3 has taken an interesting direction and to me it seems that Odersky wants to win Python developers over rather than Java shops using Spring. Ne…

Kotlin started out as a better Java but it's more than that now. With Kotlin multiplatform you can compile to JVM, Javascript and Native from the same repository. Java has been catching up on language features but I'm not sure if I'm ready to switch back to Java for Spring projects yet. Mostly because of nullability, extension methods and coroutines in Kotlin.

Targeting all those platforms will result in Kotlin falling in-between all of them. It will not be truly close the the JVM primitives, or the native ones or both in the end and will suffer from platform-specific quirks.

Especially with the heavy, under-the-hood developments of the JVM, like Loom and Valhalla.

Re: New language features since Java 8 to 17

#278

Post by kaba0 »

66fm472tjy7 wrote: post #265
pron wrote: post #160

Earlier quoted context omitted.

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

those feature are either horrible I speculate that most users of languages that have these features (Kotlin has all of them) would be unhappy if you took them away. algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones. I am not arguing against those features, but the ones I asked for seem easier to implement by comparison as th…

Adding syntactic sugar for properties to the language will cement the worse than ideal get/set naming convention to the language forever, while there are sure better abstractions that could be made instead (eg. records with withers)

Mutable records, especially primitives are a pain in the ass for C#, so it is a bullet avoided. Immutable objects are much easier to optimize away, and are safer to use in concurrent code.

Re: New language features since Java 8 to 17

#279

Post by kaba0 »

fulafel wrote: post #263
pron wrote: post #160

Earlier quoted context omitted.

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

Question from a non Java programmer, where can I read more about algebraic data types in Java? The article doesn't mention the term.

They are not used that much yet, and the whole deal (with destructuring pattern matching) is not yet ready, but it is basically just records as (nominal) product types and sealed classes as sum types.

What is already possible with switch expressions is branching based on type, in a much more ML-like style like case Point p -> … which doesn’t require instanceof checks and castings, but it will soon become Point(x, y), where the x, y will automatically get the values of the corresponding fields.

Re: New language features since Java 8 to 17

#280

Post by kaba0 »

dmitriid wrote: post #272
pron wrote: post #211

Earlier quoted context omitted.

Properties are probably the worst feature on that list, and no experienced language designer would add them to Java. They make it easier to work with setters, while the goal is to reduce their usage altogether! Records achieve that much better. Unencapsulated component access is standardised on classes with good contracts (construction and deconstruction are duals for records) and will work well with patterns, all wh…

> instead, we'll have "withers" or "reconstructors When? > On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet. Java "dodged it" by never even having to fight. While C#'s "poor choices" are leading to a language with less and less boilerplate with almost each year, in Java we'll have to wait another 10 years before it delivers half of a half of t…

But at the other hand, C# is heading in the direction of C++, where even after n years working with it, it can still surprise you/find yet another way of doing this and the rest.

Like, I would prefer not having 10+ initializers from C++ in a language.

Post reply on HN