Learning Java in 2024

During the last 10 years or so I learned many programming languages in my spare time. These include Rust, Elm, Typescript, Elixir and more. And for 2024 I was wondering which technology I should learn in 2024, if any.

Breaking changes and frustration

I recently wanted to update a web application I wrote in Rust a few years ago. This turned out to be a very frustrating experience due to all the changes in Rust’s futures and async/await implementation in addition to countless breaking changes in Gotham, reqwest, dashmap and other dependencies. I had the same experience in Elm a few years ago which was also very frustrating. And most people are aware of the amount of rewrites that are caused by the ever-changing frontend ecosystem.

My goal is not to complain about these things, but it made me think about the question of “stable” programming stacks. With stable I mean stable APIs and a small number of breaking changes.

Taking a step back it seems like Rust, especially for Web and Elm and many JS frameworks are usually very young or even “bleeding edge”. And other languages like Lisp, Java or Erlang or even Ruby and the Rails framework are already pretty stable and change muss less frequently. I used “bleeding edge” loosely here, because that is somewhat subjective but “immature” has a negative sentiment.

So let’s instead refer to the technology adoption curve and say I was an early adopter for the given stack for these projects.

Risks of being an early adopter

So it turns out that I built many of my projects I used tech stacks where I was an early adopter. This naturally comes with a risk. At that is fine for toy projects that we don’t care much about. If something breaks over time, we just rebuild it because the migration is too hard and no fun. I think this is also the mistake I made, because these projects have real users. They were deployed to production and users used them and cared about the downtime and updates.

So maybe if we build projects to learn a stack or language, those should be “throw away” and not have the intention to be maintained over time. Maybe we should not even deploy them to production. So there are no future security risks.

From that perspective, we might want to be more conservative with any projects that we expect real users to use and really stick to dummy projects or simple things when we explore new technologies. Unless you want to really dedicate your time to them and you won’t have a multi-year break of using them.

Decide if a project is for learning OR for real users. If it is for learning, don't even deploy it to production.

What to learn

I usually tend to learn new technologies. Elm when it came out. I also build web apps for fun in Rust and Go instead of Ruby. So when I want to learn something new, I usually look at things that were new. I think we easily overlook established solutions. A friend of mine recently started to learn or improve his Common Lisp, a language that is not exactly “new” or trendy.

Sometimes we hesitate to adopt older technologies because their projects seem less active, but I think that is often a misconception once a certain maturity is reached. Think Common Lisp or Erlang or Java.

My choice for 2024

This let me think: What are mature languages that will not change to frequently but still are likely to have modern features like HTTP/2 support, etc. One of these language that also evolved quite a lot is Java. If you have think I totally lost it, just take a minute to read this short post about Modern Java.

I learned the Java Syntax during University and learned about the JVM and GC optimization while I was learning Clojure and some Scala. … but I never learned the normal Java ecosystem and all the improvements to the language in recent years convinced me, that I should at least give it a try.

So I decided that the next programming language / stack I am going to learn in 2024 will be Java (and Spring). Let’s see how this will go and if “modern Java” can actually compete with modern languages like Ruby, Elixir, Rust and Go, when it comes to tooling and “developer happiness”, while still providing a mature and stable ecosystem.