How difficult is Go for Java programmers? - JVM Weekly #118

1. Is it easy to switch from Java to Go?

Every year I have fun with Advent of Code (and as every year I get off a bit at the end right before Christmas, with a strong resolution to catch up in the post-Christmas period). This year I decided to give myself an extra challenge and started learning GoLang in parallel with solving tasks in it. That was probably too ambitious plan – especially considering – as I mentioned – that each year I have problems finishing every task on time in Kotlin. However, thanks to this I gulped down some Go. I was even going to share my experiences with you, but I was late. It turned out that Christopher Berger created a text that very well captures what I would like to know – as a JVM dev – before trying to Go.

From Moving from Java to Go? What you need to know you will thus learn about the philosophy of the language (as a supplement here I also recommend the official FAQ of the language – long yet succinct), how to think about its concurrency, and the specifics of the language’s paradigm, which is quite elusive and challenging to grasp (neither object-oriented, nor functional, nor procedural). And if you end up needing even more, there’s also the java2go.dev course, which explained many things to me and made me likely to make another “go” at GoLang, despite my initial failure.

It’s as if someone wants to add something to their New Year’s resolutions list.

Here, I’d like to add one more library, which for me personally was a big game changer and allowed me to prototype solutions in Go more easily. It is kamstrup/fn, which, as the author himself writes,

was inspired by Clojure and the Java Streams APIs that were introduced back in Java 8, and want to provide something of similar spirit that makes it even more fun to write Go code.

I confirm the above, and don’t let the sheer amount of Stars project has to fool you – my brain, thanks to the addition of fn to the project, has become much more compatible with Go. It has helped me start writing (for now… a tad) more idiomatically.

Go programmers probably hate such libraries, but for rest they are lifesavers.

Anyone had fun at this year’s Advent of Code? If so, you still have one last chance to join our Facebook group and leaderboard (join code: 2276325-be92402e) before the whole competition is over 🎄.

Sources

2. How CDI 4.0 Lite fits into recent JDK trends

Lately, everyone has been trying to overcome the slow Java application warm-up. We’ve just had AWS Lambda SnapStart, based on CRaC, and earlier with the announcement of the GraalVM joining OpenJDK, there was a lot of fuzz about the Leyden project. It turns out that there are moves happening in the Jakarta EE world as well.

Along with the Core Profile introduced in Jakarta EE 10 came an entity known as CDI Lite. This is a new variant of the Jakarta dependency injection container, this time having a rather interesting twist. When running applications based on the original CDI, it is necessary to scan the entire codebase at startup, stemming from the need to locate all variants of a given dependency. CDI Lite introduces BuildCompatibleExtension, enabling operations such as validations or bean extensions to execute at the build level, before the whole application is run.

Of course, there’s nothing for free and migrating to the new variant isn’t quite so seamless. But if you want to get a taste of what CDI looks like going with the spirit of the JVM, CDI 4.0 Lite and Potential Pitfalls will introduce you to both the concept itself and highlight what to watch out for. Also, a good analysis of the standard itself was released by TheServerSide, where they made a comparison between different versions of CDI.

PS1: the new GlassFish version 7.0 was recently released. It includes full support for the Jakarta EE 10 API.

PS2: Going back a bit to the Project Galahad topic I wrote about recently – GraalVM (as a whole) has announced changes to its release cycle. So not only will the Java part of GraalVM CE be in sync with Java releases, but the entire project is also facing this. New releases of both the Community and Enterprise editions will thus appear every six months, along with new editions of the JDK.

Sources

Bonus: Our Favorite Show – Java Dies (Again!): episode 2137

This is just to wrap it up completely, as we started with the transition to GoLang. Those wishing to “rationalize” such a decision should take a peek at the latest TIOBE reading. For the first time (or at least for the first time in a veery long time) Java disappeared from the top three, and it was replaced by C++ there. The Tiobe index ranks languages based on searches on Google, Bing, Yahoo, and other sources – so this means that Java has begun to be searched less frequently.

I share this more as a curiosity, as I don’t think I need to convince any reader of these reviews that Java still has a lot of vigor and verve in it, so it’s probably not time for language to die yet. And while fully remote offerings aren’t as easy to come by in Java as they are in, say, the once again referenced GoLang, Java is an incredibly prolific ecosystem. Anyway, just recently in Software Craftsmanship Weekly, I shared text about pitfalls that “trendy” languages can easily fall into – using Rust as an example. I recommend reading the original publication What killed Haskell, could kill Rust, too, written in the Futurospective format.

And just to cheer your heart – Sander Mak, Director Of Technology at Picnic, a Dutch shopping delivery app, shared the reasons why they decided to get into “dying” Java. The entire discussion is conducted rather in opposition to Kotlin and Node.js, but most of the arguments are valid.

Sources

Well, Happy Holidays! And let’s read each other in the New Year!

How difficult is Go for Java programmers? – JVM Weekly #118

1. Is it easy to switch from Java to Go?

Sources

2. How CDI 4.0 Lite fits into recent JDK trends

Sources

Bonus: Our Favorite Show – Java Dies (Again!): episode 2137

Sources

Discover more great content!