Flexperto GmbH

We have a lot of experience in JavaScript, writing our services in NodeJS allows developers to transition to the back end without any friction, without having to learn a new language. There is also the option to write services in TypeScript, which adds an expressive type layer. The semi-shared ecosystem between front and back end is nice as well, though specifically NodeJS libraries sometimes suffer in quality, compared to other major languages.

As for why we didn't pick the other languages, most of it comes down to "personal preference" and historically grown code bases, but let's do some post-hoc deduction:

Go is a practical choice, reasonably easy to learn, but until we find performance issues with our NodeJS stack, there is simply no reason to switch. The benefits of using NodeJS so far outweigh those of picking Go. This might change in the future.

PHP is a language we're still using in big parts of our system, and are still sometimes writing new code in. Modern PHP has fixed some of its issues, and probably has the fastest development cycle time, but it suffers around modelling complex asynchronous tasks, and (on a personal note) lack of support for writing in a functional style.

We don't use Python, Elixir or Ruby, mostly because of personal preference and for historic reasons.

Rust, though I personally love and use it in my projects, would require us to specifically hire for that, as the learning curve is quite steep. Its web ecosystem is OK by now (see https://www.arewewebyet.org/), but in my opinion, it is still no where near that of the other web languages. In other words, we are not willing to pay the price for playing this innovation card.

Haskell, as with Rust, I personally adore, but is simply too esoteric for us. There are problem domains where it shines, ours is not one of them.

We're still using JavaScript and Node.js, but try to stick with TypeScript for new services and modules. About the benefits of static typing much has been written, in short it:

• offers better maintainability and discoverability of existing code bases
• provides reasonable type safety, which frees us from writing a huge chunk of unit tests and mitigates a large set of problems that are caught in compilation
• affords a new level of expressiveness via types

Nothing is without trade offs; we are aware of, and accept that:

• fighting the compiler can be frustrating
• it adds to the already large list of skills a web developer has to learn
• it adds another piece to the already large set of tools necessary to get code from development to production

We run our services on bare-metal servers instead of using IaaS providers like AWS. The reason to choose Docker Swarm over a tool as complex as Kubernetes for us was to keep the cost of operating such a tool low.