I'm at a company that's transitioning to TypeScript, and the reality is that you can't just flip a switch and have a well-typed codebase: if we just turn `strict` on, `tsc` gives us thousands and thousands of errors. And as we've gone through trying to annotate things, it's clear that in order to get various components to a state where they're properly type-safe, we'll need to almost completely rewrite them.
Compared to Rakuten, our codebase isn't even that huge or legacy - it's often very poorly written, but it's less than 50K lines and less than a couple of years old. No doubt the situation for Rakuten would be even worse; I'm sure huge swaths of their code would need to be trashed anyway.
If TypeScript is ultimately going to force you to rewrite - and still leave you with a less-robust solution - I could see why starting with a clean-slate with Elm would be appealing.
Also TS is just part of a potential solution while Elm comes with all batteries included. You still have to set up your code formater, liner, decide on a framework, state management library and so on and so on. With Elm, you just use elm-format. No arguing about code style, not arguing about how structure your code. There is only way to do it. It is not only a language but a framework. You get everything you need out need out of the box.
> You get everything you need out need out of the box.
This is specious. There's lots of comments about how you don't get everything out of the box and for the parts that are missing it's a pain. Perhaps your particular use cases are covered, that's great.
edit: Ah, hold on; I just got to where they comment on this. “TypeScript, which adds optional static typing to JavaScript and is probably one of the best things to happen to JavaScript, can partially mitigate the issues with the JavaScript dynamic type system. But being a superset of JavaScript it needs to compromise on elegance and simplicity. It also has several ‘blind spots.’” etc. I don’t know that I’m 100% convinced.