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

191–200 of 352 posts

Re: Java 26 is here

#191

Post by dinkumthinkum »

kyrra wrote: post #64
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).

Not the GP, but for really large code bases, Go is missing a few features that I've noticed: 1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this. 2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method…

This is not a dig at Go and this will be controversial but I so struggle to see what problem or area Go is solving outside of CSP. It's a nice language it just feels far too simple and I am really convinced of it as a systems language over Modern C++ and if you want that alternative then we have our rather oxidized friend that seems to more substantial. That's just my take.

Re: Java 26 is here

#192

Post by EdwardDiego »

Seeing as we're having a $LANG war, after 15 years in JVM land, I moved to a Python / Go shop, and fuck I miss Java.

Not so much the language (although modern Java is pretty slick), but the stuff surrounding it.

* No typosquatting issues because every package has a group id verified by real humans and DNS TXT records.

* JMX as a standardized mechanism of exposing ways to interact with running code / expose metrics. (Even if you have to deal with the stupid ass protocol where you have to connect using a DNS identity the JMX server recognizes)

* Logging libraries that give people running the code control over what gets logged and how, not the developers (looking at you Golang, wtf is with your logging approach where devs have to explicitly consider the fact that you might want to run logging at DEBUG and code it into your start up args?)

* The ability (via JMX) to set, at runtime, one particular logger in one class or file to a desired logging level without restarting the application.

* The performance of the JVM.

* The vast FOSS ecosystem.

* Not having to fight C build chains for that one dependency that's using CGo or a Python wrapper around a C lib that no wheel supports for your given tuple of Python version, OS, and architecture.

Honestly, as someone who is a self-taught developer who taught himself in Python, I thought I was coming home to my first love.

Turns out, I really hate the horrible things you can do in Python - looking at you Django, don't be so dynamic your brains fall out - and really dislike the experience of trying to run a Go service compared to a JVM service.

Java and its ecosystem is just good at getting shit done in a predictable manner at both the dev level and ops level.

Re: Java 26 is here

#194

Post by dwaite »

cogman10 wrote: post #13
dmos62 wrote: post #7

Earlier quoted context omitted.

What are colored functions?

Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function. In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions. It ends up creatin…

The coloring is a property of concurrency safety and whether the language enforces it.

For instance, if you resolve a future in the wrong context you'll still have problems - the coloring is just a compile time error that you are doing things wrong, rather than a runtime deadlock.

Re: Java 26 is here

#195

Post by samus »

OSaMaBiNLoGiN wrote: post #95

All the changes look great. But I don't know how I feel about the syntax. A lot of things that very well could be first-class just aren't. Instead of a `lazy` keyword, we get `LazyConstant `. I'm sure there's reasons as to why. I just don't know them.

Once introduced, keywords and Java syntax is nearly impossible to change or to remove. If it's possible to get the job done using a class, perhaps with some JVM magic, it's not wise to whip out new syntax.

Re: Java 26 is here

#196

Post by pjmlp »

rossjudson wrote: post #167
pjmlp wrote: post #27

Earlier quoted context omitted.

J# was the transition product to port J++ into .NET, I am quite sure. Not only I was there on those years, my employer was a MSFT partner that got to test .NET before it was announced to the world, so that we could have our products as part of the announcement event in Portugal. OpenJDK is cherry picked, Google only picks pieces of it, rather than full compatibility.

No idea what you are talking about. Google internally has a massive amount of code based on JDK 21, and the (amazing and completely transparent move) to JDK 25 is nearly complete. That's the full OpenJDK @ Google, and it has been for a very long time.

I am talking about fu..... Android!

Re: Java 26 is here

#197

Post by pjmlp »

geodel wrote: post #86
pjmlp wrote: post #34

Earlier quoted context omitted.

They definitely did not, it was Android Java from day one, and Oracle should have crushed them like Sun did to Microsoft, unfortunately Google was the geek darling of do not evil, thus they got a pass from fanboys.

Oracle's Java Mobile Edition could've crushed Android. No one stopped them. > Google was the geek darling of do not evil, thus they got a pass from fanboys. Oracle's case against Google went all the way up to Supreme Court of US. Oracle did not win anything substantial in courts against Google is not fanboys' doing.

Yes they did, although judge say despite Google's wrongdoing, fair use clause would apply.

Additionally to this day it is hit and miss to port standard Java code into Android unless you are lucky with the APIs being used.

Re: Java 26 is here

#198

Post by cryptos »

mands wrote: post #177
jiehong wrote: post #174

Earlier quoted context omitted.

Quarkus is better, but isn’t that amazing IMO. It’s still very much an annotation festival in the code, making the framework quite lengthy to learn for newcomers (gotta learn Java and the whole quarkus annotation DSL with it). Go is verbose, but it is much more explicit and only uses standard language things instead of a whole annotation DSL.

Helidon SE ( https://helidon.io/#se ) or Javalin ( https://javalin.io/ ) would be more in that vein - straight-forward modern Java, super fast.

In my opinion Helidon is the most refreshing of these frameworks. It supports virtual threads from the ground up and comes with clean, function, mostly annotation free APIs. It really looks like a Java framework should look today.

Re: Java 26 is here

#199

Post by gf000 »

owlstuffing wrote: post #151
lucketone wrote: post #65

Earlier quoted context omitted.

> for not embracing religion of OOP and FactoryFactory Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture. FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”. We now know that we prefer composition over inheritance, we have st…

> We now know that we prefer composition over inheritance When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a. But that’s not what composition is really about. The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface. Java provides inheritance and interfaces…

Well, what mainstream language has better tools for composition?

Re: Java 26 is here

#200

Post by gf000 »

jiehong wrote: post #174
mands wrote: post #58

Earlier quoted context omitted.

It's getting better, it doesn't all have to be Spring Boot and JBoss. There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI ( https://tamboui.dev/ ) for terminal UIs, and more. Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resourc…

Quarkus is better, but isn’t that amazing IMO. It’s still very much an annotation festival in the code, making the framework quite lengthy to learn for newcomers (gotta learn Java and the whole quarkus annotation DSL with it). Go is verbose, but it is much more explicit and only uses standard language things instead of a whole annotation DSL.

There are non-DSL frameworks in Java. It's just that arguably the benefits of a DSL outweigh learning them.

Putting an annotation on a method is much easier than registering this method at n places in ordinary code, which could look any number of ways. If you move to a new project, in the first case can just immediately jump into framework-related stuff, while in the second all this logic has to be untangled first. And let's be honest, Spring/Quarkus probably got their abstraction right after n iterations, which is not necessarily true of a random team.

Post reply on HN