There are already several notes on a similar topic:

I want to rethink it a little bit after a year and describe it in a different way.

Firstly, we are talking about API development. Server-side rendering is no longer relevant (largely due to the popularity of mobile applications), and therefore everything related to it (RubyOnRails/Django and their JS/PHP clones).

Secondly, for microservices, updating / improving the quality of a project often takes the same amount of time, but also with the transition to another language / platform. Therefore, it is important to keep the target architecture in mind and pretty soon most projects will be based on it. It is clear that soon is not a month, it all depends on the number of microservices, but it is unlikely to be more than 2 years.

Next, a more or less up-to-date list:

  • Kotlin + Spring
  • Java + Spring
  • Python + FastAPI
  • JS/TS + …
  • Golang
  • PHP + Yii / Lavarel / Symfony / …

The rest is either legacy or something marginal (a strange decision, just because I wanted to).

Now imagine that you need to start a new project. Or we select/update the target architecture.

What is the most important thing? The presence of programmers and their ability and desire to write on the stack. Why? Yes, the technologies are different, but not by orders of magnitude.

And if you still look at the technical aspects? This is a straight squeeze, the details can be viewed at the links at the beginning of the article.

Node:

  • JS/TS once caused a furore in the backend with their asynchronous approach. Since that time, all platforms have got it.
  • But the problems of JS/TS have not gone away.
    • weak typing, and because of this there are problems with bugs and speed. I have experience when rewriting microservices (not one, several) from JS to Kotlin+Spring led to a significant reduction in latency (about 2x times).
    • a sea of frameworks: 2 projects on TS are likely to be completely different, only the “brand” Node is one.
  • It can be used for serverless (only a separate question is why serverless, but sometimes it is necessary).

Java:

  • She is no better than Kotlin, only worse. Then why? Only for conservative environments where they are afraid to take responsibility for changing any thing.
  • The only technical reason is the development of a library for Java. But it’s like this everywhere: if you want to make a library for Golang, use Golang, for Kotlin, use Kotlin.
  • Plus, you don’t need to translate the entire project at once. It is possible for the 1st class. There are tests in these internets of yours that there are no technical problems (neither in memory nor in performance).

Python:

  • Bad typing, bad work with collections.
  • There are no technical advantages.
  • AI developers love the language (because the university language is in the West), so they release various specific libraries. And in this case it makes sense.

PHP:

  • Extremely weak and strange as a language in 2024, more or less as a platform.
  • There are no technical advantages.

Golang:

  • Extremely weak and strange as a language in 2024, more or less like a platform.
  • Golang can be used in some rare projects (such as Caddy – replacing NGINX with Golang instead of C).
  • In general, people somehow did not understand Golang. This is for NGINX or Kubernetes type applications, for cli utilities, not for business microservices.
  • Is it possible to write business microservices in Golang? Yes, but it is not the best tool due to the peculiarities of the language, not the platform.
  • Maybe some better language will be introduced to this platform (such as TypeScript for JS: so that it works conveniently with collections, and business error handling, and the rest). It’s been a long time: it doesn’t make sense to say that the language is good, but its genius is not understood.

So there is no technical reason to use anything other than Kotlin. Perhaps there is some kind of unique library somewhere, but it is a rare case (you can wrap it in a separate microservice and make it exceptional).

It is clear that many people will be outraged by such a position. Just open the website https://kotlinlang.org and in the section Why Kotlin? look at the examples. And write the same thing in another language. Did it work out better? No. And now imagine how much the difference will accumulate on the size of the project.

PS.: I’m not a Kotlin fan at all, but there are no technically strong alternatives at the moment. At the moment, I am writing microservices in TypeScript, Python and Kotlin. Previously, I wrote at work (for more than a year on each stack) in C++, Java, C#, Ruby. Personally, also in Golang, Basic, Pascal, PHP. My programming experience is about 26 years (since high school), of which I have been officially working for 19 years.