You learn by comparing to what you already know. I was recently bitten by assuming Rust worked as Java regarding transitive dependency version resolution. In this post, I want to compare the two. Dependencies, transitivity, and version resolution Before diving into the specifics of each stack, let’s describe the domain and the problems that come with it. When developing any project above Hello World level, chances are you’ll face problems that others have faced before.

Pattern matching is a major feature in software development. While pattern matching applies in several locations, its current usage is limited to switch case blocks. I want to compare the power of pattern matching across a couple of programming languages I’m familiar with in this post. I assume that every reader is familiar with the switch case syntax inherited from C.

Last week, I was at the FOSDEM conference. FOSDEM is specific in that it has multiple rooms, each dedicated to a different theme and organized by a team. I had two talks: Practical Introduction to OpenTelemetry Tracing, in the Monitoring and Observability devroomWhat I miss in Java, the perspective of a Kotlin developer, in the Friends of OpenJDK devroom The second talk is from an earlier post.

Java has been my bread and butter for almost two decades. Several years ago, I started to learn Kotlin; I never regretted it. Though Kotlin compiles to JVM bytecode, I sometimes have to write Java again. Every time I do, I cannot stop pondering why my code doesn’t look as nice as in Kotlin. I miss some features that would improve my code’s readability, expressiveness, and maintainability. This post is not meant to bash Java but to list some features I’d like to find in Java.

I’ve tried Go in the past, and the least I could say is that I was not enthusiastic about it. Chief among my griefs was how the language handled errors, or more precisely, what mechanism it provided developers with to manage them. In this post, I’d like to describe how a couple of popular languages cope with errors. A time before our time I could probably go back a long time, but I needed to choose a baseline at some point. In this post, the baseline is C.

In the first post of this series, we described the concept behind a Kubernetes controller. In short, it’s just a plain control loop that reconciles the desired state of the cluster with its current state. In the second post, we implemented a sidecar controller in Java. This third and last post will be focused on where to deploy this Java controller and how to improve it to be on par with a Go one. Running outside the cluster or inside?

In the previous post, we laid out the foundations to create our own custom Kubernetes controller. We detailed what a controller was, and that its only requirement is to be able to communicate with HTTP/JSON. In this post, we are going to finally start developing it. The technology stack can be Python, NodeJS or Ruby. Because this blog is named 'A Java Geek', it’s normal to choose Java.