Yeah, Typescript is a complete no-brainer as a pick - even if you're only picking a backend language. The type system is better than anything this side of Haskell, while still letting you write boring imperative code without getting in your way for every little thing if you just need to pipe some data around.

Performance is really not an issue unless you're doing very CPU-intensive work which you can't offload to a native library for some reason, or you need to scale vertically rather than horizontally (which is even rarer). Compute cost only really starts being a worthwhile optimization target at the "hundreds of billions of requests per day" level, and even then you're not gonna see much of an improvement from moving to Java unless you're actually very good at tuning threadpools (and it might still not be enough of a win compared to whatever else your developers could be doing with that time).

Rust's type system is also better than Typescript, and I would say Dart is slightly better too. But I agree Typescript is very very good, and you get access to such an enormous ecosystem it's worth it in most cases, and it's only a few times slower than C++/Rust. Not 50 times like Python or Ruby.

I'll grant that Rust could make a solid argument for itself with traits and such (though I haven't had a chance to use it myself). What's the five-second rundown on Dart's type system being better than Typescript's? I take a look every couple years and back in the day I remember thinking it was a solid alternative to C#/Java simply for its better null handling but Typescript solved that problem and many others besides.

I think the main issue with TypeScript’s type system is that most of the time, there’s no runtime types. You know something matches an interface, but if you have some untyped object (like say a thrown error from some lib that you caught), and you need to check if it’s a X, often it’s pretty awkward and hacky to do so. Obviously this issue is inherited from JS, but it’s still an issue.

Great type system and language otherwise, though.

That's not an issue if you code properly. Most statically typed languages only have run-time type information as a sort of "ok fine if you're desperate you can use it, but please don't" feature.

Exceptions are a special exception in Typescript because they can come from pretty much anywhere so it can't realistically know the type at compile time.

For everything else you are probably want discrimination unions.

Yeah, for your own code it’s not really an issue, as long as you’ve got decent team-wide discipline. But when integrating with external libraries, especially JS ones with type definitions tacked on later, it can be an annoyance.

Yeah, the story for handling thrown errors is much worse than it is in Java, and arguably worse than e.g. C#. But it's not a total loss:

1) 99.9%+ of the time, it'll be an instance of `Error` or some child class.

2) There's a recent compiler flag that's been added which defaults caught errors to `unknown` rather than `any`.

3) You still have access to the same tools to inspect unknown errors as you do everything else - `instanceof`, checking the presence/absence of properties, etc.

It's not great but it's something.

I would actually say the propensity of libraries to use exceptions as control flow and then _fail to document anything about those totally expected outcomes_ is a much bigger headache; that truly is an artifact of its JS inheritance.