One year after switching from Java to Go

Java is really good. Java developer culture is awful.

If you instead of spring boot just pick a few dependencies you really need, you don't throw the whole Design Patterns book at it just because you can, and you don't try to make everything changeable without recompiling or redeploying, it's pretty nice to work with

It is not inherent in Java though, and the Kotlin "developer culture" seems to be much more annotation averse (as we all should be).

Annotations are declerative shorthands. How is a trivial spring boot endpoint with methods with a single @GET line above them denoting the endpoint verbose?

What about a single SQL query in an annotation above an interface method's name? Will your whole implementation of connect to db, execute query, iterate over the resulting rows, and convert them to some native object/struct shorter than.. 2 lines?

First we shape our tools, then our tools shape us.

Ever looked into Kubernetes source code?

OR. Are annotations a crutch for something that should be in the language.

Just generally, if some tool has to use annotations, then that is indicator of something that should be in the language.

Like, this is just standard metaprogramming, if you don't have it you will just reach for dumber tools like non-language aided code generation.

On other end

Type annotations in JavaScript. Just use a language with Types.

I mean... https://en.wikipedia.org/wiki/List_of_Great_Old_Ones

Truth to be told, there isn't much difference between Gradle and Gwarloth

I once asked the founders why they chose java; it was because it was 2015ish and they had an existing product in java and they knew it. Which makes sense to me. I think there's a lot of path dependence to language choice.

I also think the domain matters. For database based webapps, Java can be great. Lots of tooling and knowledge around it. And modern java is pretty friendly to write. Plus, if you are interacting with something over an API and deploying it via a container, who really cares what it is written in?

For kubernetes operators? Seems like a natural fit for golang. Anything kube really. I had a friend who ran a k8s consultancy for a while and said that they'd prototype stuff in python because it was easy, then implement in golang because that was what was consistent with the rest of the ecosystem.

0: https://github.com/prime-framework/prime-mvc

I have some issues with the Java language (though Java 21? Actually pretty ok!), but there's no question that there's a lot of great stuff in regards to libraries in Java land.

A lot of the stuff that's just built into the JDK is already very good, for example. NIO can be a bit hard to work with, but is generally very good, fast, and reliable. A lot of the concurrency abstractions (e.g. BlockingQueues) are really pleasant to work with for most concurrent programs, the different types of mutexes/locks give access to most of the patterns you want, and the thread-safe collections like ConcurrentHashMaps are very boring, in that they work pretty much exactly as I want them to.

If we extend to third party libraries, it's even better. Vert.x and Disruptor, for example, are downright excellent tools for wrangling concurrency.

The issue is that it feels like a lot of Java developers are stuck in 1999; it can be like pulling teeth to even use NIO, which isn't exactly "new" at this point. When I wrote some stuff using BlockingQueues instead of throwing `synchronized` everywhere, people acted like I was grabbing this was some exotic code from a distant land that had never been tried before, When I imported Vert.x into my project because I needed to run a lot of non-blocking concurrent tasks, it required a lot of justification for using it instead of using threads everywhere.

Vert.x is a lot of fun, and I've gotten pretty decent performance with its SQL libraries in particular, though I'm not sure I'm a huge fan of the EventBus. I've had better luck with LMAX Disruptor, at least for the data-processey stuff that I do.

But as I said, there's a ton of really great libraries in Java. The language isn't perfect, but Java 21 fixes a lot of my gripes, and it's nice to have a ton of really well-tested libraries to minimize how often you have to reinvent the wheel.

I might agree if you're speaking about Java since ~11 or so.

One of my biggest complaints about Java, especially before the lambda syntax caught on, was how many extra files it made me create. I felt like every project had lots of wrapper classes, and people would make a make a file for each class.

You could argue that that was "bad" Java and they should have nested the classes, and that's fair enough, but it certainly wasn't uncommon Java. It artificially makes the language feel way too verbose if you have ten files more than would be necessary in a comparable language.

Once people started to embrace the lambda syntax, I feel that Java got immediately more fun to write; you weren't constantly creating one-off instantiations of interfaces or classes (well, at least not explicitly anyway), and the language felt considerably more streamlined.

Java 21 is actually one of the most pleasant surprises I've had in quite awhile in the tech world, in that I'm actually having fun writing Java. Sealed interfaces and record patterns make some code considerably more pleasant, and I actually have been writing Java in my free time, which is something that I would have said would never happen if you had asked me five years ago.

ETA:

https://youtu.be/jgkEHoc3YUw?t=288 See! I even said I would never enjoy writing Java!

Sometimes --in Spring Boot-- they hook different systems up with eachother: this makes the framework very "magic". I really dont like that: I want to be able to CTRL-click my way to understand how everything works!

I think a lot of people are noticing the changes Java has had in the previous years. The language has made a lot of improvements, and I feel that the mind set of the community has changed. The old enterprise way of factories and unnecessary abstractions have lost a lot of popularity, and is mostly still alive in legacy software/teams and universities who have not yet caught up.

Even Spring Boot is now a valid approach for getting sh*t done for startups. There are of course frameworks that are more light weight, or you can start from scratch and choose your own libraries to keep the size down. But SB is simply good enough for most use cases, and even supports native compilation now.

But that’s obviously not the language’s fault. There are frameworks in Java that I think are great, like Vert.x; hell even going super low-level with NIO is straightforward enough if I really need control of HTTP stuff.

The stuff I really have the most fun working with is concurrent and distributed programs, and I think Java (or at least the JVM) is pretty hard to beat with that. Vert.x, Disruptor, and even the built-in JVM concurrency libraries (other than synchronized) are excellent; they have a Just Works quality to them.

And nowadays, GraalVM is good enough with its native compilation that you can avoid the long startup times and keep the memory under control, so it even is reasonably ok for custom command line tools.

> It is not inherent in Java though

"Coupling by annotation" culture (which diminishes many of the benefits of using a typed language, as it pushes coupling to runtime and by means of reflection) IS inherent to SpringBoot. Hence my distaste for it.

Java's okay, prefer Kotlin though these days.

Where are you working that you encounter these people? I've been doing Java for about 15 years now (C++ before that) and as the years have gone by I just don't encounter this stuff. I do work in finance technology, so we're not doing crud apps, maybe that makes a difference. Granted, there is a lot of "C in Java" code around in this industry.

Isn't async unnecessary now? Threads are now cheap enough that its much easier to write sync'd calls on a thread.