Don’t call it a comeback: Java is still champ

That's a common wisdom, but there is little if any evidence to support it. True GC costs are simply more hidden and harder to measure. A malloc/free pair might be slightly slower than Java's new (not by much really - go measure), but invoking `new` is not the only cost of GC.

https://arxiv.org/abs/2112.07880

Also modern low pause GCs have way higher CPU overhead than the old STW ones. Try to set a low pause GC pause target to 0.1 ms or set the heap limit to 110% of live memory and see what happens to CPU consumption. Last time I tried, the app didn't even start - got OOM nearly instantly. There is a reason the study above measures at 3x oversized heap.

The cost of GC is lower than malloc/free only if you give it a lot more memory than you actually need. Which in many cases is a good tradeoff to make, but it is good to know such tradeoff between memory and CPU exists.

And finally there is one more thing that's not particularly a trait of GC, but rather a limitation of current Java - it is much easier to write a C++/Rust program with low number of heap allocations than in Java. The fact that malloc is slightly slower does not matter if you invoked it 10x less frequently.

JVM is a masterpiece. Java improved, but legacy is there. I now prefer and use whenever possible Kotlin, I can do more writing less code and still retaining JVM performance.

> I think it depends a lot on where you work and what sorts of projects you work on.

Agreed, even if my experience has been the exact opposite of yours. I've seen Spring be used in my country a lot, although recently Spring Boot.

On one hand, I really dislike how code is sometimes exchanged for annotations that cannot be debugged with breakpoints easily (unless you dig in to the code where the breakpoint is defined and then come up with breakpoint conditions that are triggered exactly for your code, but not the other 500 places in your app where that annotation is used) and don't allow for easy customization (vs just changing a few lines of code in the actual method body), or sometimes just don't work altogether (e.g. trying to log method execution times with something like AOP, which didn't work with Spring calls sometimes).

On the other, it's better than some of the in-house frameworks that I've seen, with sparse comments written in Lithuanian (which I really don't speak) and just bad in most respects. Honestly, most off the shelf open source frameworks/libraries that are actively supported should be good enough, be it Quarkus, Dropwizard, or something else entirely. Though at least something that's widely known and has lots of questions and answers surrounding common use cases in places like the documentation and StackOverflow. Otherwise, you're in for a bad time.

But even race conditions are well-defined in Java: you can’t get so called out-of-thin-air values. Some updates may not be visible from another thread, and of course dead/live locks are on the table (but they are everywhere, even the actor model doesn’t solve those).

> Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem.

I couldn't disagree more. I can understand disliking the fact that we need getters/setters in the first place, or perhaps dynamic things like annotations which aren't "normal" code, but static code generation is something that the industry absolutely should embrace.

Model driven development should be more common.

For example, if you can just draw a few ER diagrams and have MySQL Workbench forward engineer SQL migrations for you to check them over (especially if you need to change 20 tables), why shouldn't you take advantage of that? Having a model of your schema that you can generate from the live schema and then transform it into either a set of fresh migrations or just a delta for bringing an older schema version up to date.

I've actually used these two approaches to save bunches of time for personal projects in the past, even though I took the SQL output and put it into dbmate migration tool.

  Reverse engineer: https://dev.mysql.com/doc/workbench/en/wb-reverse-engineer-create-script.html
  Forward engineer: https://dev.mysql.com/doc/workbench/en/wb-forward-engineering-sql-scripts.html

But databases are just one example. Remember SOAP?

Despite being hard to use, one of the best points of SOAP was WSDL - Web Services Definition Language files which allowed you to have a fully functional description of a particular API contained in a single file. Back when REST started replacing it, there was also WADL, but that didn't really go anywhere. The claim that web service endpoints (REST or otherwise) should be largely dynamic/schemaless is basically a lie, because in most languages you'll indeed want to work with particular fields for the objects that you expect to be returned, or domain classes that shouldn't be that different in practice from what you expect.

The beauty of WSDL was that you could get the file from a live version of an API, feed it into something like SoapUI and get a fully working API client, upon which you could build a test suite. Or even better, generate client code for your language of choice, so instead of making HTTP calls and wondering about how to initialize the client, you could start using library code much sooner, with parameters and methods already created for you.

Some time later, OpenAPI came along, but the wisdom of SOAP was basically lost, since it took a while for projects like OpenAPI Generator to pop up and even now the approach of generating client (or even server!) code based on some specification seems to be utterly lost on the industry.

  WSDL: https://en.wikipedia.org/wiki/Web_Services_Description_Language
  WADL: https://en.wikipedia.org/wiki/Web_Application_Description_Language
  SoapUI: https://www.soapui.org/
  OpenAPI: https://en.wikipedia.org/wiki/OpenAPI_Specification
  OpenAPI Generator: https://openapi-generator.tech/

Want more examples? What about database schemas and mapping them to your ORM/other persistence layer solution? I think if you're writing your own model code, you're doing something wrong, regardless of the language that you use. You'll probably mess up or miss relation mapping with something like Hibernate, will miss out on some comments for autocomplete in Laravel and just generally will have an inconsistent persistence layer that will make you waste time.

In most cases, starting with the schema first and using one of the available generation solutions to fill in the application side of the persistence layer seems like the only sane options. Sure, some might prefer to handle migrations in the app side, like Ruby's Active Record Migrations, or something like Liquibase, which are also passable approaches, as long as you don't create a bad schema just so it fits your application.

  Java JPA entity generator example: https://github.com/smartnews/jpa-entity-generator
  Java generator to get DDL from JPA: https://github.com/Devskiller/jpa2ddl
  PHP (Laravel) generator to get models from schema: https://github.com/krlove/eloquent-model-generator
  Ruby Active Record Migrations: https://guides.rubyonrails.org/active_record_migrations.html

In most cases, when you integrate two systems, APIs or just bits of code, one side should be the source of truth and the other should match it as closely as possible (problems with data types aside). Somehow the industry doesn't really know how to do this well, though thankfully projects like gRPC prove that it's perfectly doable in a modern setting.

When this isn't done, you end up with either technologies that are a bit too green to be used successfully (e.g. picking GraphQL to supposedly deal with dynamic data and then being a month late with actually shipping), or having to waste your own time writing "boilerplate" that you will actually need, because although it could and should be generated, it is actually needed (to query that API, access that database, migrate that schema).

I do agree in regards to the pointless Spring XML boilerplate, which is indeed useless.