Live data from Hacker News

Java 21 makes me like Java again

wscp.dev

581–590 of 777 posts

Re: Java 21 makes me like Java again

#581

the argument for Java seems to be that it's gradually gaining features we already have in Scala, Kotlin, OCAML, F#, etc... so why not use the languages that have those features today?

One thing about "gradually gaining features" is that the Java language architects do a very good job with backward-compatibility. This means that your application/library will be easier to migrate to newer versions of the language and you will continue to have a large number of 3rd-party libraries available. The Scala community is currently migrating to Scala 3 and many libraries have not been ported (Scala experts correct me if I'm wrong.) Kotlin also seems to be less stable at the API level than Java (but I may be wrong here, Kotlin experts please correct me.)

This backward-compatibility does comes with costs (e.g. non-reified generics)

Also, if you're a library developer and you want to create a JVM library that can be used by Scala, Kotlin, etc. developing in Java is often the best choice. For one thing it avoids any dependencies on the standard libraries of those other languages.

Disclaimer: I like Kotlin and Scala, but mostly use Java.

Re: Java 21 makes me like Java again

#582
post #573

Earlier quoted context omitted.

I’ve got to disagree with this strongly. I built and operated the same large system in both languages (acquisition forced me to rewrite) and both the dev and operating cost of the JVM was much higher. Go is a high velocity language. Code reviews on language/style issues are non existent, it’s GC is blazing fast (not our experience with JVM) and it’s really easy to read. I’ve watched many new engineers ramp up on both…

The main pain-points in a large org at least: Lack of a "default" stack for nearly anything. The stdlib is great but the ecosystem isn't. Which web framework? Does it come with a logger? If not which logger? Do the third party libraries I want to use work with my logger/have a mechanism to provide one via an interface or am I shit out of luck? This goes for so many more things though, cache libraries, data structures…

Teasing this apart I see a few things: a) logging, b) modules rollout and c) missing frameworks.

I’ve never had a logging issue in large systems. Explicit error return (as you know, on every function) allows you to log in your code, not lean on only libraries that support your interface.

Modules rollout was part of growing up. But, you won’t get Go 1->2 upgrade issues as we have 100% backward compatibility on version upgrades. Moving to the latest version of Go is trivial and simply unlocks new features.

Too many allocations for Go is going to be too many allocations for JVM too. This seems like an problem isolated to that team.

I’ve done Go at both a three engineer startup and at Google and I can’t help but notice none of these are really the type of problem that crop up later.

Re: Java 21 makes me like Java again

#584

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…

Coming from Spring Boot with it's 17+ level deep abstractions to Go / gin-gonic was such a breath of fresh air!

With the little difference that spring boot offers you 99% of your needs, both to fetch the data from (sql, nosql, you-name-it), and to offer your interface out (web, rest), and programming style (syncronous, asyncronous), and observability, ....

while for go you'll find yourself deep in the mud of choosing what 3rd part library to use for logging and how to make it work with the rest of custom stuff you have to write

Re: Java 21 makes me like Java again

#585
The title of the blog post is IMO a poor choice. The (hidden) subtitle of the post is "Algebraic data types in Java" which is much more descriptive of the content. A better title would have been "Algebraic data types in Java 21".

Perhaps because of the title, many/most of the comments here are off-topic. I was hoping to see more discussion about algebraic data types, strengths and weaknesses of the Java implementation, technical comparisons to other languages, etc.

Re: Java 21 makes me like Java again

#586

Earlier quoted context omitted.

DI buys you maintainability. Without DI, there's too much flexibility in how objects get constructed. If you want to add new functionality to a legacy code base, it can be difficult to track down the different integration points and slow to plumb through your dependencies. These projects can turn into spaghetti very quickly. DI solves this with a simple recipe: define your functionality, define your dependencies, wir…

the problem is that those DI frameworks are all adding substantial amount of complexity and brain load. I started using just static factories in my code, and abandoned all those DI and it works well enough.

  > I started using just static factories in my code, and abandoned all those DI and it works well enough.
i have done this as well (though not in java), it makes knowing what gets initialized how and where much easier and faster to debug

Re: Java 21 makes me like Java again

#587
post #366

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.

> The biggest feature in Java 21 is the release of Virtual Threads Is there a good honest writeup on why is this interesting? Very curious. The earliest JVMs had this, green threads. Performance was terrible so it was eventually dropped. I want to fully utilize every CPU and every core I have, why do I want green/virtual threads again?

> I want to fully utilize every CPU and every core I have, why do I want green/virtual threads again?

If your task is CPU bound, then virtual threads don't gain you anything.

On the other hand, if your task is IO bound, e.g. for a webserver, virtual threads make it trivial to spin up a new thread per request, for massive workloads.

https://en.m.wikipedia.org/wiki/C10k_problem

Re: Java 21 makes me like Java again

#588
post #493
post #482

Earlier quoted context omitted.

Gradle, when the daemon is runnning is very fast, people just often fck up their build scripts to include config-time run functionality, which is just all around a stupid thing to do. It only ever runs tasks that actually have to be run, has integration with javac, can work in parallel, and even has cross-company build caches if needed. Also don't forget that Java can do hot reloads with the debugger, or with tools l…

I've never seen Gradle run fast, even with the daemon running. Gradle itself can take multiple seconds to startup. God knows what it's doing.

Gradle is steaming pile of garbage. But since the zoomers are allergic to XML, Maven (actually fast) is slowly dying.

Re: Java 21 makes me like Java again

#589

Earlier quoted context omitted.

Go gives you the illusion of simplicity because it gets rid of guard rails and error checking. If you remove all error checking, of course your code is going to look a lot simpler. It's also going to be a lot more wrong and crashy. Wait until your code base grows, your team grows to >10 developers, and you will understand what I mean. Java (and preferably Kotlin) are a lot more serious about making sure your code is…

Wait, are you implying Go doesn't have error checking? In what way? It has famously verbose error semantics.

well... https://github.com/search?q=%22f%2C+_+%3A%3D+%22+language%3A...

98k results...

Re: Java 21 makes me like Java again

#590
post #519

The "Sealed classes" feature, as described here, just feels all wrong to me. They are saying that if you have a (normal) interface, anyone can create a new class implementing it. So if you do if (x instanceof Foo) { ... } else if (x instanceof Bar) { ... } ... then your code will break at runtime if someone adds a new class, as that code won't expect it. So the article is saying the solution is to use the new "sealed…

I understand what you're recommending, and I've seen Bob Martin talk about it extensively (polymorphic dispatch instead of instanceof), but it's something I disagree with. To do this kind of polymorphic dispatch, objects have to deal with multiple concerns within themselves . In a video game, a Car might have .render(), .collide(), .playSound(). Later on you can add a Dog, which also has those three methods, and you…

The OO solution is to have a PhysicalObject class that dog and car both inherit from (or use via composition).
Post reply on HN