Live data from Hacker News

Java 21 makes me like Java again

wscp.dev

401–410 of 777 posts

Re: Java 21 makes me like Java again

#401

Earlier quoted context omitted.

I don't think any existing Go developer is going back to Java. I worked with Java for 10 years and switched to Go and I will never go back. This is mostly because applications and libraries are so hard to reason about and understand due to inheritance, packaging, OOP, build tools ect compared to Go. Go is simple. It's easy to understand, read, and maintain. The packaging is like how you would package files on your co…

Go's major selling point to me is that you can ship one binary, nothing beats that. Python, Node, Java all have to pre-install lots of dependencies before you can use them, fine for developers, not so great if you want to distribute software for people who are not software savvy, who typically just wants to download one file, install and start using it. c and c++ can also do one executable, but, it is not as portable…

> Go's major selling point to me is that you can ship one binary, nothing beats that.

You can ship one compiled binary in Java too if you want it. https://www.graalvm.org/22.0/reference-manual/native-image/

> Go is simple. It's easy to understand, read, and maintain

Go involves a lot of code repetition which makes it difficult to human-scan and maintain. Worked on both large scale Go and Java projects and I found Java projects easier and more comfortable to maintain. Had to pay a lot more attention to Go. Go is easier to write though thanks to its well-designed and extensive standard library which is possibly the best in the world, but the maintenance angle still tilts to Java. There are also more Gotchas in Go compared to Java.

Re: Java 21 makes me like Java again

#402

Earlier quoted context omitted.

Rust isn’t thread safe either. It’s borrow checker will attempt to correct you but you can still run Rust unsafely.

As I understand it Rust's unsafe is designed so you can encapsulate unsafety behind a safe interface. It's up to the programmer to verify the safety of code using unsafe. But it they do so correctly then you can rely on the borrow checker to verify that everything else is safe. This means that when you run into a thread safety bug in Rust code you should only have to look at the unsafe blocks to find the culprit.

With that said, I think it is important to mention that if you go off the safe path in rust and you do hit such a bug, your current execution is no longer trustable, it could have corrupted the heap, introduce UB, and die with a segfault, etc.

In java, race conditions can enter illegal application state, but their scope is much more limited. NPEs are 100% safely handled, etc. you can only get off the safe road with using Unsafe unsafe, and manipulating the JVM’s inner state which is not even allowed by default. Depending on application, this difference may matter a lot!

Re: Java 21 makes me like Java again

#403
post #153

Earlier quoted context omitted.

var list = []; while (true) { list.add(1); } Here you are, which language won't leak memory here? Also, which language will let you connect to a prod instance without a performance hit to get some stats on the heap and its allocated objects? Hell, you can even list every instance of a type as I've recently learned.

>var list = []; > while (true) { list.add(1); } idk, I don't think endlessly growing memory usage is really what a leak is, a leak is really when you have no way of accessing the allocated memory to free it (ex. dropping the last remaining pointer to a `alloc`'d block in C) or the opposite in garbage collected languages: accidentally holding onto a strong reference to objects that should be freed.

> the opposite in garbage collected languages: accidentally holding onto a strong reference to objects that should be freed

So basically what I gave an easy example of. Sure, it won’t look like this in practice, you probably accidentally keep adding to a list, or a cache, but basically this is what happens. The former kind of leak can’t happen with tracing GCs.

Re: Java 21 makes me like Java again

#404

Sad this gets to front page while a blog post which documents that .NET 8 has 200 A4 pages worth of performance improvements gets absolutely ignored. C# keeps being the language people are looking for but don't know about.

I've written in C#. It's Java. If they're not the same language to you, you need to learn more languages.

Re: Java 21 makes me like Java again

#405

The biggest feature in Java 21 is the release of Virtual Threads: https://openjdk.org/jeps/444 For some reason, this is missing from the article. If there was any feature that would sway existing Golang developers to switch to Java, it would be this. It would perhaps also convince the haters of the reactive-style concurrency patterns.

Java 21 has me anticipating the next JRuby release because of Virtual Threads. Charles Nutter gave a talk about JRuby in August where he showed a demo of the impact on Ruby fibers and it’s pretty significant. There’s a lot that I really like about the JVM and it’s tooling, I just don’t like writing Java code anymore. JRuby kinda gives the best of both worlds. Here’s the talk. Virtual thread demo is around the 45 minu…

I loved this. Is there any post comparing Ruby performance with JRuby?

Re: Java 21 makes me like Java again

#406

Earlier quoted context omitted.

How could you possibly like C++ but feel that Java is bloated? Like I academically understand disliking Java but this just makes no sense.

I mean...Java is run through a VM while C++ is compiled to native code. I can see that being used as a reasonable argument for bloat.

> run through a VM

This is just incorrect use/understanding of Java’s execution model. It does have a runtime, but it is definitely not a VirtualBox VM.

Re: Java 21 makes me like Java again

#407
post #73

Earlier quoted context omitted.

Having worked extensively in Java, Node, and Python, I’ll take the JVM ecosystem absolutely any day of the week. Me and my catheter will be over here delivering actual software while you figure out how React 32 broke your transcompiler.

> delivering actual software while you figure out how React 32 broke your transcompiler. Say that to enterprise software systems still running on Java 7 or 8 without any clear path to upgrade because their whole systems will break.

It’s almost like there is even a CS law for this exact scenario.. but Java 8 will be around and will still work 10 years from now, plus it is not an insurmountable task to bump it up to the latest version at all. Tell me literally any platform that has a better backwards compatibility story, because honest to God there is simply absolutely none.

Re: Java 21 makes me like Java again

#408

The biggest feature in Java 21 is the release of Virtual Threads: https://openjdk.org/jeps/444 For some reason, this is missing from the article. If there was any feature that would sway existing Golang developers to switch to Java, it would be this. It would perhaps also convince the haters of the reactive-style concurrency patterns.

`Executor.newVirtualThreadPerTaskExecutor` versus `go` really gets to the heart of why I think that Go developers aren't going to be switching. edit: Sorry, it's actually: try (var executor = Executors.newVirtualThreadPerTaskExecutor()) { executor.submit(...) ) instead of `go`

Extend that to a full function and the Go code will be 2x more verbose than Java with all the `if err != nil` stuff.

Re: Java 21 makes me like Java again

#409
post #189

Earlier quoted context omitted.

A minimal Java app can easily start up in 0.1 seconds, which might just as well be good enough, but if not, there is also GraalVM that can output a native binary.

I’ll just leave this with you. 0.1 difference may not seem like a lot until you start hitting 100M invocations. https://mikhail.io/serverless/coldstarts/aws/languages/

At that point, why lambda?

Re: Java 21 makes me like Java again

#410
post #329

Earlier quoted context omitted.

Go almost instant build time is a huge productivity boost when compared to Java. You get both the solidity of a typed language, and the development speed of interpreted languages (py, js).

Java's build times are very fast. Java's build tools are anything but. And I'm surprised no one is doing anything about it.

If you are leveraging Maven, use mvnd during development: https://github.com/apache/maven-mvnd
Post reply on HN