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

Java 26 is here

hanno.codes

Post reply on HN
Print view View original

291–300 of 352 posts

Re: Java 26 is here

#291

Post by saghm »

dzonga wrote: post #37

the people that work on Java & the JVM are very smart. it has become a best of breed language - hell its better than Go for industry purposes. the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change. All those people using typescript (could be…

> All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory)

I assume you're specifically talking about the backend and not suggesting that people write Applets or use GWT or something.

Re: Java 26 is here

#292

Post by wbl »

gf000 wrote: post #208
wbl wrote: post #132

Earlier quoted context omitted.

I think you want sum types which admittedly Go doesn't have in a matchable way. However complex error recovery is an anti pattern for Go.

> However complex error recovery is an anti pattern for Go. Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes". Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.

Why exactly do you have complex error analysis happening above a component that has the error? That's anti modular.

Re: Java 26 is here

#293

Post by deepsun »

troad wrote: post #238
deepsun wrote: post #118

Earlier quoted context omitted.

I recently worked on a Go project and my task was to make it more configurable at build time and start time (add plugins / addons, make it possible to reuse from other libraries and tools). Turned I had to create *Factory and *Providers, even though I did not want to. It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yoursel…

> It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself. The first domino is opting for OOP. AbstractFactoryProviderBuilders are just the inevitable downstream consequence of that initial choice. No need for factories if you don't traffic in objects in the first place. Objects. Just say no.

Mmm, no, I don't see why OOP has anything to do here (any examples?).

I did not use any inheritance. In general I would say OOP craziness faded long ago (in Java too), together with XML. Interfaces -- yes, are very much alive though.

Re: Java 26 is here

#294

Post by cess11 »

rubzah wrote: post #269
cess11 wrote: post #232

Earlier quoted context omitted.

Not really, no. It is similar but worse than Maven in that it requires quite a bit of time investment to configure, and shares the drawback of Gradle that it is configured in a programming language instead of a configuration language. Switching out Maven for a larger maintenance burden might be reasonable in a large organisation that is swimming in competent employees, but most do not. As for obvious contender, I'd s…

Did everyone just agree to forget about Gradle? It was everywhere not too long ago. I think I even prefer it to Maven, in a choice between a rock and a hard place type of way.

I don't think so, but the pain points have become more widely known and taken the edge off the hype.

Re: Java 26 is here

#295

Post by armchairhacker »

beachy wrote: post #110
dzonga wrote: post #37

the people that work on Java & the JVM are very smart. it has become a best of breed language - hell its better than Go for industry purposes. the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change. All those people using typescript (could be…

I wonder if at we are standing looking at the smoking field of programming languages created over the last 50 years and gazing at the final survivors, of which Java is definitely one. Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction. I learned IBM /360 assembler when I started in comp…

What advantage do old languages have that can’t be overcome or at least reduced to insignificance?

The 50-year head start in training data, runtime, and ecosystem? That may not be much, because LLMs are rapidly accelerating software development. LLMs can also generalize: take what they learned for one language and apply it to a “similar” language (and I think most modern languages are similar enough for broad effective translation: all have records/unions, objects, functions, types, control-flow, exceptions, and more). Some fairly recent languages (e.g. Rust, Swift) already have comparable runtimes and ecosystems to older ones, from human-driven development acceleration and concept generalization.

In a recent study, LLMs solved the most exercises in Elixir (https://autocodebench.github.io Table 4). Anecdotally, I’ve heard others say that LLMs code best in Rust, and (for UI) Swift. More importantly, I don’t see an older language advantage that is widening from LLM use; an older language probably is better for most use cases today, but any written code can be translated or regenerated into a newer one.

Re: Java 26 is here

#296

Post by owlstuffing »

megapoliss wrote: post #257
gf000 wrote: post #199

Earlier quoted context omitted.

Well, what mainstream language has better tools for composition?

kotlin

Kotlin's "delegation" feature isn't true delegation, it's just call forwarding, which is better than nothing, but it falls down pretty quickly as an alternative to implementation inheritance.

The manifold project provides true delegation[1] for Java.

1. https://github.com/manifold-systems/manifold/blob/master/man...

Re: Java 26 is here

#297

Post by beachy »

armchairhacker wrote: post #295
beachy wrote: post #110

Earlier quoted context omitted.

I wonder if at we are standing looking at the smoking field of programming languages created over the last 50 years and gazing at the final survivors, of which Java is definitely one. Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction. I learned IBM /360 assembler when I started in comp…

What advantage do old languages have that can’t be overcome or at least reduced to insignificance? The 50-year head start in training data, runtime, and ecosystem? That may not be much, because LLMs are rapidly accelerating software development. LLMs can also generalize: take what they learned for one language and apply it to a “similar” language (and I think most modern languages are similar enough for broad effecti…

> I don’t see an older language advantage that is widening from LLM use

A classic one is C++. Microcontrollers like esp32 cost about $10 these days, for a machine more capable than an early PC.

One downside though is that you typically need C++ to program them, and the barrier to entry with C++ is very high, especially for non-programmers.

LLMs remove that barrier so that anyone can create powerful embedded devices - programmed in C++ - without knowing anything about C++.

Re: Java 26 is here

#298

Post by zadikian »

owlstuffing wrote: post #153
HendrikHensen wrote: post #51

Earlier quoted context omitted.

What do you mean by "better than Go for industry purposes"? I don't understand what "industry purposes" means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I'm interested in your perspective).

Go can't compete with Java bc it's not in the same category as Java. - Java is a high-level, multi-paradigm programming language - Go is designed as a systems language to supersede C projects at Google Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.

Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)

Re: Java 26 is here

#299

Post by troad »

deepsun wrote: post #293
troad wrote: post #238

Earlier quoted context omitted.

> It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself. The first domino is opting for OOP. AbstractFactoryProviderBuilders are just the inevitable downstream consequence of that initial choice. No need for factories if you don't traffic in objects in the first place. Objects. Just say no.

Mmm, no, I don't see why OOP has anything to do here (any examples?). I did not use any inheritance. In general I would say OOP craziness faded long ago (in Java too), together with XML. Interfaces -- yes, are very much alive though.

I'm not using OOP to mean presently unpopular facets of OOP, to the exclusion of presently popular ones, I mean all of OOP. It's pretty hard to need factories, let alone factory factories, when one isn't using objects or classes.

A friendly joke in response to the claim that sufficiently complex code always ends up sprouting OOP abstract nonsense.

Re: Java 26 is here

#300

Post by owlstuffing »

zadikian wrote: post #298
owlstuffing wrote: post #153

Earlier quoted context omitted.

Go can't compete with Java bc it's not in the same category as Java. - Java is a high-level, multi-paradigm programming language - Go is designed as a systems language to supersede C projects at Google Now Go identifies as a general purpose language that competes with Java? It's a free country, I guess.

Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)

> I think the reputation you mentioned. . .

Actually no. Go was designed from the beginning as a systems language as a C replacement.

Post reply on HN