Live data from Hacker News

Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

infoq.com

491–500 of 555 posts

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#491

Earlier quoted context omitted.

I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries. I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate. Go is far from perfect, but i…

> I mean, it’s also less verbose Are we talking about the same language? Or maybe you consider writing "if err != nil" every few seconds as good exercise for your fingers... I think we shouldn't point fingers at Java when it comes to Go's verbosity. I can simply do dict.contains("foo") in Java vs having to go through a verbose hoop: if val, ok := dict["foo"]; ok { //do something here } Common operations like filterin…

Well, I listed a number of things I prefer about Go, and the verbosity I was talking about was the classic ButtonFactoryFactory and other naming classics. It’s true however that I ended up throwing that stuff away from my Java code and started to enjoy life again.

But I can say honestly that I prefer Go’s error handling, which I find tends to result in errors which are actionable. I think it takes a lot more effort up front to get Java exceptions to work rationally.

If I could change Java then the thing I’d do is I’d make it necessary to declare all exceptions in a method, but get rid of caught exceptions. So you can see what’s coming, even if you don’t have to deal with it.

In terms of stream operations, well, I write a lot of typescript lately and just like in Java, I find that I end up having to fall back to regular loops quite often. I’m not convinced that stream operations are useful in as many use cases as people would like. For example, the moment something can throw an exception, things are going to get gnarly.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#492
post #438

Earlier quoted context omitted.

That was one reason I liked Go as well, it's no longer the case though, you can produce native binaries with GraalVM.

Last time I used GraalVM, there were huge holes in what language features were supported, compiling dynamic code was hit-or-miss, and also its cross-compilation story was not good (requires you to compile it on the target architecture). Perhaps my information is out-of-date now?

Yeah I find the argument for Graal to be very disingenuous. It’s certainly not an out of the box solution; I’d say it’s just another Java technology stack we would need to learn. And there are so many of those.

So I guess I also like Go’s batteries-included standard library.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#493
post #422
post #193

Earlier quoted context omitted.

The younger generation chose Go because they're dumb and fell for the Google marketing hype. Most of them have never even used Java outside of school.

If anything, Google doesnt promote it at all, never had official Android support. They love Dart and now they are building Carbon.

Google is a patch work family where the siblings constantly fight each other for their parents' favor. All the teams are competing for promotions and money that you get through "impact". Go and Dart are just like all the other Google products that get released with much fanfare and then quickly forgotten once their creator's no longer need them for their next brag sheet.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#494
post #465

Earlier quoted context omitted.

> I mean, it’s also less verbose Are we talking about the same language? Or maybe you consider writing "if err != nil" every few seconds as good exercise for your fingers... I think we shouldn't point fingers at Java when it comes to Go's verbosity. I can simply do dict.contains("foo") in Java vs having to go through a verbose hoop: if val, ok := dict["foo"]; ok { //do something here } Common operations like filterin…

Go's language maintainers refusal to add list operations / comprehensions and you having to type it out by hand every time is something I hate everyday while I'm getting paid to write it.

I’m guessing these will come with generics. Wasn’t that also the case with Java?

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#495
post #22

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

Not fear. Disgust.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#496
post #188

Earlier quoted context omitted.

Nah, totally different than channels. And Goroutines are proper managed threads with their own stacks. As an aside pipelines are terriblely unergonomic. The public APIs are not fully developed and something simple, like IDK creating an actual processing pipeline, is funky as all hell. Creating a pipe wrapper feels dirty. The buffer management is cool though and sequence seems like it should have just been made a firs…

C# has channels as a library and not a language construct, it lives in System.Threading.Channels namespace.

They do have channels but they don't supply a select equivalent.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#497
post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

This is missing the forest for the trees.

Languages are very complex, you will not get a good picture of their overall strengths and weaknesses if you limit yourself to a very zoomed-in view, like comparing a few features of the languages themselves.

As an example, consider the digital camera market vs the cameras in smartphones.

The digital camera is a clear winner! So many features. The quality of photos taken is objectively better in every metric too.

And yet the digital camera market is dying, completely killed by smartphones.

But why, the features are cleary better right?!

Because we're looking at it wrong, we're tunnel-visioned on the "camera" part. We need to look at what actually matters.

Thankfully, that's simple to answer and is the same for every product in existence. All that matters is the user experience.

Nobody wants extra features on their camera, nobody wants a camera in the first place, nobody wants to take photos either. What people actually want is to preserve the moment of their first born child taking their first steps. The technology is irrelevant as long as it lets the user do what they really want.

Why would I want a digital camera when my smartphone has a decent enough one that is effectively free and always available? A low quality camera on you is infinitely more valuable than the professional camera at home.

Programming languages are no different, just that "users" in this case are programmers, which seems to be confusing to some.

What is the developer experience of using Java vs Go? - that's the real question you need to answer to get to the bottom of this.

Start a new project and write some code in both languages, compare the experiences. Be wary of biases, if you have pre-existing experience in one of the languages it's going to shadow your judgement (the curse of knowledge). Pay attention to aspects of good design - how many pointless decisions do you have to get through before actually shipping code?

Go eliminates whole areas of pain points:

- Dependency management? Go modules.

- Tests? Built-in.

- Code formatting? Built-in autoformatter.

- Compilation time? As fast as it gets.

- Distribution? Single binary.

- Writing code? Minimal ceremony, just make a function.

- Performance? The idiomatic code you write will naturally perform well due to value types, explicit pointers, a culture of straightforward code with no needless indirection. If you need to optimize, the profiling tooling is great and the optimizations themselves straightforward due to intuitive language and GC semantics - just reduce allocations.

- GC? A single implementation, good enough for 99% of cases. Two whole knobs available if you really need to tune it. Performs well due to the language not getting in its way.

- Standard library? Excellent, good balance between batteries-included and bloat. The built-in HTTP server is suitable for 80%+ of workloads.

- Concurrency? Core to the language - syntactically supported green threads. The entire language and its ecosystem are built with it in mind.

- Linting? Community-made linter runner with a curated list of good linters.

- Found a bug in a library? No problem, the library is written in straightforward Go, the same flavor of Go you've been writing. It's of course autoformatted as well.

There you go, a single go-to solution to each problem. The language's designers have gotten all the pointless details out of the way for you. You get to focus on writing code.

Now compare the above points with Java.

Go was designed for developers, with the same philosophy Steve Jobs designed Apple products for users. Java wasn't. Simple as.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#498
post #474

Earlier quoted context omitted.

Java's already got tasks[1] within the namespace of parallelism though, but it hasn't overloaded any meaning onto virtual. [1] https://docs.oracle.com/javase/9/docs/api/index.html?javafx/...

JavaFX is not really a part of Java and isn’t actually shipped with most builds of OpenJdk. Azul Zulu is the only build that I know of that you can get FX built in.

"Fun" fact, there might just come official JDKs that do include javafx.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#499

Earlier quoted context omitted.

> I mean, it’s also less verbose Are we talking about the same language? Or maybe you consider writing "if err != nil" every few seconds as good exercise for your fingers... I think we shouldn't point fingers at Java when it comes to Go's verbosity. I can simply do dict.contains("foo") in Java vs having to go through a verbose hoop: if val, ok := dict["foo"]; ok { //do something here } Common operations like filterin…

Well, I listed a number of things I prefer about Go, and the verbosity I was talking about was the classic ButtonFactoryFactory and other naming classics. It’s true however that I ended up throwing that stuff away from my Java code and started to enjoy life again. But I can say honestly that I prefer Go’s error handling, which I find tends to result in errors which are actionable. I think it takes a lot more effort u…

> If I could change Java then the thing I’d do is I’d make it necessary to declare all exceptions in a method, but get rid of ~~caught~~ checked exceptions

That's pretty much what javadocs contain already

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#500

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

Because Java did not have a good async model for decades, most Java apps are thread-intensive (thread-per-client) and there's an enormous amount of code that can't easily be refactored into async. Light-weight threads help save all that thread-per-client code from the ash pile of history. But in general it's best to write async code from the get-go because that forces the programmer to compress application state rath…

We are made of meat. It’s rarely worthwhile to sacrifice developer effort to conserve hardware, and if you do manage to break even today, you probably won’t in the future. Async Java was pretty painful and only penciled out because the cost of a million native threads was just ludicrously higher than everything else.
Post reply on HN