One year after switching from Java to Go

The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author is comparing apples with oranges, with a bit of misunderstanding that java/jvm means spring boot, and while that is true for a lot of people and certainly a lot of stuff on the internet implies that 'this is the way', it's not required. Startup times of ~100ms are absolutely standard for a big program, similarly unit tests taking 1ms. I prefer to write kotlin rather than java, as it's a nicer language ,IMHO, but still those bytecodes run on Jvm and same stuff applies.

Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably.

Just use new() it's pretty fast.

> But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware...

No, people use it because we don't want to reinvent the wheel.

Spring is well documented and Spring Boot gives you a set of dependencies that all work together.

Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

It sounds good but in reality people end up spending time messing around with config files and annotations.

Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase.

In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.

In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own.

In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc.

The extreme difference in basic developer culture causes visible differences in performance outcomes. Can't even blame the JVM - it is a superb beast that is overloaded by Java developers putting Mount Everest atop it.