No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.
I think TS on the server is a great choice for all the reasons that make TS interesting -- esp. the expressive structural typing system which is not found in the other languages. What is missing is a better runtime that supports true shared-memory (w/o serialization overhead between workers) multi-threading (for async thread pools or true parallel workloads) like other modern servers. This would be ideal for me at the moment.
I like the structural type system, but it's not my experience that the power of it is unquestionably a good idea to use for long lived projects. The simpler something is, the easier it is to maintain.
Agree, but I think it excels at it's intended purpose, as a "gradually typed" system where types can be added at the various places, and inferred types that "meet in the middle" will structurally type as intended. If you want to simulate nominal typing in places, you can always use tagged unions, as TS now offers several different ways to do this. (However, this info will typically not get erased at run-time, so you get reflection whether you like it or not :))
I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions.
Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switching. It's even better now that we have TypeScript to perform instant type-checking across the client-server boundary.
I can see the benefit, but the context switch overhead of having two different languages in the same repository is not a productivity issue in my experience.
