Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 21 makes me like Java again

wscp.dev

Post reply on HN
Print view View original

261–270 of 777 posts

Re: Java 21 makes me like Java again

#261

Post by bcrosby95 »

Thaxll wrote: post #246
arein3 wrote: post #208

Earlier quoted context omitted.

By enterprise I mean a lot of features related to data consistency, scalability and integrations. I do not know about go ecosystem, but java and spring have mature solutions that cover the most advanced use cases.

Kubernetes is what I would call very advanced use case. But that's the thing with Java, yes there are libraries for everything and one could see that as a problem actually. Spring was mentioned before, but it's the perfect example of an overengineered/ heavy library that does a lot of black magic.

Java is strange because it can be both verbose and magical at the same time.

Just the other day I ran across an issue where spring was wiring things up correctly on Linux but not Windows.

Re: Java 21 makes me like Java again

#262

Post by synergy20 »

impulser_ wrote: post #187
northern-lights wrote: post #31

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.

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 as Golang, and not as static-link friendly as Golang.

Re: Java 21 makes me like Java again

#263

Post by segfaltnh »

imbnwa wrote: post #151
mdaniel wrote: post #54

Earlier quoted context omitted.

Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you But, yes, namespaces are still mapped to paths, it's not like they rewrote the JVM to use blockchain or something

>Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you I don't think that's quite it when Ruby is also from the 90s and figured out not to tie namespace resolution to the directory tree

Let's not hold ruby up as a poster child for modularity.

Re: Java 21 makes me like Java again

#264

Post by speedgoose »

totallywrong wrote: post #218
impulser_ wrote: post #187

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 is simple. It's easy to understand, read, and maintain. Matter of taste I guess, to me Go code looks ugly, it's too verbose with all that error handling every other line which hurts readability. Also the docs are often so cryptic and unhelpful, one needs to rely on examples elsewhere. I do use it though, when I need something fast in a single binary.

My main pet peeve with Golang is to use single letter or very short abbreviations when naming variables. The Golang documentation recommends what is considered a bad practice by most programmers communities.

Re: Java 21 makes me like Java again

#265

Post by foolfoolz »

insanitybit wrote: post #79
northern-lights wrote: post #31

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`

go will always lose vs java when it comes to code verbosity

Re: Java 21 makes me like Java again

#266

Post by housemusicfan »

rcme wrote: post #204
arein3 wrote: post #197

Earlier quoted context omitted.

Exception handling and generics are missing key pieces from go. But adding them will make go look like java. I just wish java would add null safety in the type system in a first citizen way. For enterprise use java has no competitors. You have c# which is microsoft trying to estabilish nash equilibrium fu*ing the developers. I am a bit worried about ever increasing complexity and a steep learning curve, but seems lik…

What is “enterprise” use? Plenty of enterprises use Go.

By enterprise he means non-webshit industry.

Re: Java 21 makes me like Java again

#267

Post by adamsb6 »

northern-lights wrote: post #31

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.

Will that also make existing Sway developers go?

Re: Java 21 makes me like Java again

#268

Post by caconym_ »

belter wrote: post #113
insanitybit wrote: post #35

Earlier quoted context omitted.

No, there's a lot wrong with inheritance. It leads to all sorts of issues and while theoretically one can keep the tree 1 level deep, in practice it's too tempting to expand the hierarchy. This is one of Java's big issues. The other is reference equality as a default, pretty horrible. Records help but records are also limited in when they can be used.

You don't like code reuse?

Composition > inheritance.

Re: Java 21 makes me like Java again

#269

Post by foolfoolz »

kaashif wrote: post #100
leapis wrote: post #34

Earlier quoted context omitted.

Nullable is a huge issue in Java, but annotation-based nullability frameworks are both effective and pervasive in the ecosystem (and almost mandatory, IMO). I'm really excited about https://jspecify.dev/ , which is an effort by Google, Meta, Microsoft, etc to standardize annotations, starting with @Nullable.

This can never be as effective as changing the default reference type to be not nullable, which would break backwards compatibility, so you can never really relax. I know Kotlin is basically supposed to be that, it has a lot of other stuff though, and I haven't used it much.

they won’t change the default reference type to non null. might take a few years but you can see their planned syntax here: https://openjdk.org/jeps/401

Re: Java 21 makes me like Java again

#270

Post by unlikelytomato »

imbnwa wrote: post #151
mdaniel wrote: post #54

Earlier quoted context omitted.

Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you But, yes, namespaces are still mapped to paths, it's not like they rewrote the JVM to use blockchain or something

>Only if you're using vim like someone from the 70s, otherwise any sane IDE handles those things for you I don't think that's quite it when Ruby is also from the 90s and figured out not to tie namespace resolution to the directory tree

I am not sure why this is a problem. Looking at the organization of the resources directory of every project I've ever worked on, I am not sure I want more opportunity for physical and logical concepts to unnecessarily diverge.
Post reply on HN