Comment by pron | Hacker News Reader

Comment by pron | Hacker News Reader

Parent Full thread

> Another feature, that Java finally adopts, after decades of not adopting it.

Back in 1997, James Gosling published an article that serves as a blueprint to Java's evolution to this day: https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java... He explained it further, as related by Brian Goetz in the first 20 minutes of this talk: https://www.youtube.com/watch?v=Dq2WQuWVrgQ

In short, Java attempts to be "a wolf in sheep's clothing," with a state-of-the-art, innovative runtime, wrapped in a language that's intentionally conservative. Java the language only adopts features that have already proven themselves as worthwhile elsewhere, and when mainstream programmers are ready for them. We don't always live up to that standard, but we try.

So another way of putting what you said is that this is another feature that has proven itself enough, for long enough, and that's matured enough for Java to adopt it. Many if not most programming language features don't make it to that stage.

The flip side is to examine which features have never made it to Java and probably never will (at least, they're not on our long-term roadmap). Those include, among others, macros, extension methods, first-class properties, and async/await.

> async/await

Why would those be considered in the first place especially after Loom lands?

It was considered before.

there is nothing to be proud of about lacking extension methods. Kotlin has them and it allow to make amazing APIs that are much more ergonomic/reduce cognitive overhead.

I personally think there's much to be proud of in lacking any feature, as long as you deliver what your users expect, especially if the number of users is very large. After all, the goal of a mainstream programming language is not to have as many features as possible, but as few as necessary, where "necessary" takes into account both the common software requirements of the era (which are also shaped by the hardware characteristics of the era) as well as the expectations and habits of the majority of programmers at that point in time.

I can tell you that if Java's language team encounters some language feature that solves a particular problem, they'd rather spend spend several years thinking how to avoid adding that feature while still addressing the problem, than the six months needed to implement it. A good strategy for doing that is to wait, and try to think of ways to solve multiple problems with one feature (even if imperfectly) rather than solve multiple problems with multiple features.

The same feature does not entail the same tradeoff depending on the languages.

For Kotlin, extensions methods are essential otherwise you can not extend existing Java types with Kotlin types.

For C#, you need extension methods for LINQ because modifying the .Net runtime was not an option at that time.

For Java, changing the VM is not an issue, instead of extension methods you add default methods which can be overridden by implementations.

Same feature, different tradeoffs.

I think Kotlin went the easy way with extension methods. Scala’s solution is much more elegant with implicits (especially now with Scala 3).

I'd be very interested in a comparison between scala 3 using/given and Kotlin new context receivers https://github.com/Kotlin/KEEP/blob/master/proposals/context...

Reply on news.ycombinator.com