Live data from Hacker News

Java 26 is here

hanno.codes

211–220 of 352 posts

Re: Java 26 is here

#211

Earlier quoted context omitted.

Lack of virtual threads was its biggest remaining problem because this made the common ways of doing cooperative multitasking very ugly. Go's big thing was having that from the start. Maybe now that Java has it too, it's set? Though JS will still have the least boilerplate because of the way it handles types.

IMO, Kotlin coroutines are better of Go's goroutines, although they are a little different beasts to compare honestly (apples and oranges). Go inits goroutines on stack, but min size is 4KiB, so it's not trivial to grow them. Also you need to watch over and destruct goroutines manually to prevent memory leaks (using var wg = sync.WaitGroup defer wg.wait() wg.Add(1) go func() { defer wg.Done() } ) And create a separat…

Kotlin coroutines don't really exist. They're a (very neat) programming trick to support coroutine-like behavior on the JVM which doesn't support coroutines. If you look at the bytecode it produces, it honestly is a mess. And it colours your functions too: now you have be ever careful that if your function is running in a coroutine, there are certain things you should absolutely avoid doing in that function, or any function called by that function (like spinning the CPU on loop without yielding). In Go, you don't have to worry about any of this because the concurrency is built-in from the start.

Also I don't understand "it's not trivial to grow them". It is trivial to grow them, and that's why Go went this way. Maybe only 0.1% or fewer of use-cases will ever find any issues with the resizing stack (in fact probably the majority of uses are fine within the default starting stack size).

Re: Java 26 is here

#212

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.

How is Go not high level? What makes it "systems" language? That's just marketing.

It is a language with a fat runtime, running a garbage collector. You just burn it into the binary and call it a day.

Re: Java 26 is here

#213
post #74

Earlier quoted context omitted.

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 u…

Java's GCs (plural) are hands down better.

Re: Java 26 is here

#214

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. (…

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

While I think this is a huge boon, have you ever published a package on the Maven Central repository? I must confess I haven't in a few years now, but when I did until ~3 years ago it was a major pain in the ass. And every release again.

I think there's something to say about Go's model where the package is just in some Git hosting and a release is just creating a tag. As a package maintainer, this is just pure bliss compared to the Maven thing.

> and really dislike the experience of trying to run a Go service compared to a JVM service.

What are you running into specifically? I have the complete opposite experience. With Go, 1 small binary comes out that I can run anywhere (and put into a distroless container), whereas with Java I have to find a way to somehow run a full JVM (most often with (large parts of) an OS too).

Perhaps you're alluding to the things you can do with JMX, but I have never really seen much benefit in that. I found it trivial to add similar functionalities with internal HTTP endpoints easily. But since I don't have much experience in this particular area, probably I'm missing something.

Re: Java 26 is here

#215

Earlier quoted context omitted.

I think this is a misunderstanding. If the program out-paces the GC because the GC guessed the trigger point wrong, something has to give. In Go, what gives is goroutines have to use some of their time slice to assist the GC and pay down their allocations. In Java, I believe what you used to get was called "concurrent mode failure" which was somewhat notorious, since it would just stop the world to complete the mark…

A lot of the answer is that if you can do more work while generating less garbage (lower allocation rate) this problem basically solves itself. Basically every "high performance GC language" other than Java allows for "value type"/"struct"s which allow for way lower allocation rate, which puts a lot less pressure on the GC.

How much less allocation rate? Value types are an important thing and fortunately they are coming to Java as well. But they don't decrease allocation rates nearly enough in every kind of software. They may be a necessity in games/certain computations/low-lat trading, but for a typical web server they don't matter all that much - people are using identity having objects in value typed languages the same way here. Especially that with thread local allocation buffers in Java single-use object allocations are not particularly expensive to begin with - live objects are evacuated and then the whole buffer is reset.

So unless you claim that there is no software in Go/C# where the GC is the bottleneck, no, the problem absolutely doesn't solve itself.

Re: Java 26 is here

#216
post #163

Earlier quoted context omitted.

> 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's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity. I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).

GWT was a huge success, and eventually became obsolete -- which is not the same as "failing horribly". It took a long time for the web ecosystem to build up the capabilities that removed the need for GWT. For a while, it was quite a good way to build and heavily optimize certain kinds of web client applications.

Yeah, I believe some ex-Googlers even claimed that writing Gmail was simply impossible at that time with ordinary JS, and the abstraction behind GWT was an absolute necessity (though maybe the frontend part was not all that important - closure compiler is still alive though)

Re: Java 26 is here

#217
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…

"a solid foundation for the future" is faint praise for a language that has been around for over thirty years. > It has become a best of breed language To me it lags significantly behind .net (runtime) and C#/F# (language). I don't see Java catching-up.

On the contrary, as someone that earns their bread using both ecosystems, .NET is still pretty much tied to Windows, regardless of .NET team efforts, most shops going with macOS or Linux are former Microsoft shops saving on server licenses or giving Macs to their devs.

There are many platforms where .NET doesn't have an implementation, a phone to call their own (even if ART isn't proper Java, WP is no longer around), embedded systems, including factory and military weapons deployments (PTC, Aicas, microEJ), copiers (Xerox, Ricoh), phones (Cisco),....

C# is definitly better than Java dealing with value types and low level programing, or being embraced by the game development community, however not sure if the featurities of last years is the right path, I am starting to feel I should just reach directly to C++ instead.

Re: Java 26 is here

#218
post #137
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…

Maybe this is just a question of taste but I never could get along with Javas (or Kotlin's) tooling. Primarily working in Vim/Helix works for most languages from Nix to Typescript or Rust and C, but Java just never worked quite right. It also generally felt like it had a worse story around tooling from a DX perspective, something like Golang or even npm feels a lot lighter than the molasses of JDK management and grad…

Besides doing yourself a disservice of not using a proper IDE, what exactly makes Java not writeable in vim or the like? Like it's a pretty simple language with not much magic going on.

Re: Java 26 is here

#219
post #210

Earlier quoted context omitted.

> It performs better than Go Do you have some sources or experiences to share on this topic? I'm very curious. My experience is the complete opposite. At my previous job there was a Java web application and running in Kubernetes (1 vCPU and 1Gi of memory) was able to deal with at most 80 requests per second, using up almost the full 1 vCPU and ~600-700MiB of memory. That was a bit disappointing, since we were suppose…

From your description it sounds like you're comparing an old Java program running on an old JDK with a new Go program running on a new Go runtime. These days Java has virtual threads (similar to Go's goroutines) and doesn't need a "reactive stack", and its optimising compiler and GCs blow Go out of the water without breaking a sweat.

I mean, what is old? How far along are frameworks these days, and what are companies using?

That team was using Java 17. Java 21 was just released and frameworks had no meaningful support for virtual threads whatsoever.

In my experience, most companies using Java are chronically multiple versions behind (e.g. some of my friends still in the Java world are on 11).

Perhaps you can share some sources which prove that Java's performance blows Go out of the water without breaking a sweat? I have not seen any such articles about that in the past 3 years, besides the cherry-picked cases where the JVM JIT can optimize some small algorithmic part of the program on the fly (which is not relevant in most web applications).

I'm happy to stand corrected.

Edit: I found this one using a quick search myself https://medium.com/@mohnisha/java-vs-golang-performance-test... I'll check it out and see if I can reproduce it myself too. Still too bad about that gargantuan memory usage, but I guess memory in the cloud is cheap.

Re: Java 26 is here

#220
post #53
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…

After ~13 years of working with C#, I moved to Kotlin. It's such a beautiful language. When I have to read docs for a Java lib I realize why I like Kotlin. I want to say culture around Java doesn't have to change, new culture is growing around succinctness (if not simplicity) of Kotlin, and it gets most of the benefits of Java ecosystem.

I also like Kotlin. The readability is awesome. ;)

  inline fun  Any?.cryptic() = (this as? T)?.let { it::class.simpleName?.also(::println) } ?: Unit
Post reply on HN