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

111–120 of 352 posts

Re: Java 26 is here

#111

Post by gf000 »

jillesvangurp wrote: post #88
oystersareyum wrote: post #66

Do changes to Java itself impact e.g. Clojure? I think it uses many java primitives instead of emitting jvm byte code but I can be wrong.

Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java. I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured…

Java improvements usually have a runtime component, so no, kotlin simply couldn't have had Lazy no matter what. It was just syntactic sugar for a getter.

Re: Java 26 is here

#112

Post by nradov »

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…

Programmers would create a new language when there is a fundamental change in hardware architecture such that the assumptions underlying the old programming languages no longer apply. Java is probably a poor choice for writing software in which most computation happens on GPUs. But I agree that someone (or something) will still be using Java to write new line-of-business applications in 50 years.

Re: Java 26 is here

#113

Post by ivan_gammel »

chrysoprace wrote: post #100
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…

The problem is that many jobs with Java (that I've found) lean so heavily towards OOP that it's part of the job description. I just don't enjoy OOP and find that there's almost always a simpler approach, and to have it prescribed as part of the engineering culture will always steer me away.

Most of backend development on Java is procedural with OO syntax and ability to replace something in the chain of calls with stub in tests. Spring beans are usually stateless singletons containing a few references.

Re: Java 26 is here

#114

Post by joeblubaugh »

oefrha wrote: post #105
kyrra wrote: post #64

Earlier quoted context omitted.

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…

> No immutable types (in Go) The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.

In fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.

Re: Java 26 is here

#115

Post by ivan_gammel »

hackemmy wrote: post #94
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 write TypeScript daily and honestly it is not about being scared of Java. The ecosystem just makes more sense if you are already building for the web. You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. That is a hard thing to replicate in Java even if the language itself is technically better in some areas. The…

With SSR/HTMX/HATEOAS the amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.

Re: Java 26 is here

#116

Post by deepsun »

nradov wrote: post #74
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).

Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using J…

Are you sure about Go's garbage collector doesn't have pauses? AFAIK they are worse than modern Java's garbage collector [1].

I'm not sure it's even better than Java's, especially for modern ZGC (and you can choose your GC in Java). Definitely less configurable. I would say most of online comments about Java's GC are long outdated.

For example, in web servers a lot of work is request-response, so it's convenient to utilize generational GCs (so that each request data would fit into "young" generation). Similar to arenas, but without code changes. Go's GC is not generational though, so you should care about allocations.

https://codemia.io/blog/path/The-Evolution-of-Garbage-Collec...

Re: Java 26 is here

#117

Post by ivan_gammel »

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.

It‘s easier to evolve library code. If Java would ever infer type of constants from initializer (makes more sense than a new keyword), it could look nice and powerful:

   private final LOG = lazy(logger(MyThing.class));

Re: Java 26 is here

#118

Post by deepsun »

ludovicianul wrote: post #63

I program in Java for more than 15 years now. I can resonate with people hating the language from it's early days due to the experience with all the enterprisy features and over abstractions. Or confunding Java with the Spring ecosystem. But Java came a long way over the years. It's now what many would call a "modern" language. It's less verbose, has many of the features people find appealing in Scala and Kotlin and…

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 yourself.

Re: Java 26 is here

#119

Post by oefrha »

joeblubaugh wrote: post #114
oefrha wrote: post #105

Earlier quoted context omitted.

> No immutable types (in Go) The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.

In fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.

Hey it's better in Go. In Java it's getFoo(). In Go it's just Foo(). Saves three bytes, and three keystrokes if you program by hand and don't autocomplete!
Post reply on HN