VP Of Engineering at 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.

READ LESS
18 upvotes·2 comments·650.2K views
Prasanth Vaaheeswaran
Prasanth Vaaheeswaran
·
November 13th 2020 at 4:41PM

Have you considered migrating to TypeScript over JS? I found the TS ecosystem quite cumbersome and slow -- with sound linting and code style (and tests), JS scales quite well.

·
Reply
Timm Stelzer
Timm Stelzer
·
November 16th 2020 at 7:52AM

Hey, I shared our decision to stick with TypeScript here: https://stackshare.io/tstelzer/decisions/104127714472608961. Personally, I found TypeScript scales much better than JavaScript. I believe its a "dynamic vs static" thing, you need a very disciplined and mature team to make any dynamic language scale beyond a certain point without it all breaking apart at the seams. Scaling a codebase of a dynamic language _needs_ strict conventions, and a solid architecture, well documented boundaries, etc. A codebase of a static language obviously needs those too, but I found, the static types carry you longer, even if you don't have them.

Simple example: have a module with a function `f`, without documentation, without tests. What does it do? Well, in dynamic land, you pray that you understand it purely by looking a it, hoping that it works. You have to run it, to make sure that it does, and get further insight into it. In static land, the language server could likely, at the very least, tell you about the types, and could tell you if you are breaking any major rules.

Now, with TypeScript and JavaScript, those lines blur a bit, since the latter can be checked by the former, but only to a certain point, without helping the compiler with added hints.

I'm curious though, why you found the TS ecosystem slow and cumbersome? Which libraries, specifically?

Cheers.

·
Reply
Avatar of Timm Stelzer

Timm Stelzer

VP Of Engineering at Flexperto GmbH