What about Kotlin make it a step above typescript in terms of productivity?
* TypeScript's lack of runtime types and stable reflection APIs make it hard to have any guarantees of type soundness without either code generation (e.g. schemats) or complex type programming to convert a runtime representation of a type to a static type (e.g. io-ts). I find this very frustrating when doing web backend programming, where you are constantly doing i/o with external services (whether HTTP APIs, or input from client requests, or database interaction).
This is particularly maddening because there's no de facto standards (seriously, there are a lot of these libraries: https://github.com/moltar/typescript-runtime-type-benchmarks), so it's not easy to e.g. find a DB library that will let you define an io-ts schema that a query should match without re-wrapping things yourself.
Basically: if TypeScript had runtime types, and an `as` cast threw an exception when a value doesn't match the specified type, I'd be much more inclined to keep using it. I genuinely think that's table stakes for a type safe language.
(and lest you think this has to be how TS works given the nature of how it's compiled to vanilla JS, I suggest you take a peek at Sorbet, which knew this was necessary: https://sorbet.org/docs/runtime)
* The TS ecosystem is generally underwhelming. I don't think any HTTP framework for it is particularly good, nor any ORM/query builder. I think there are a lot of really neat experiments still happening in this space, and it seems like every day GitHub's little "explore repositories" sidebar shows me another cool library someone's built for TS trying to solve some of these problems, but it's all early stage stuff with a bus factor of 1 and a long todo list.
To be fair, _Kotlin's_ ecosystem actually has a lot of these problems; the semi-official Jetbrains-maintained Kotlin web framework and DB access library both have a ton of untriaged issues and seemingly little production use. The good news is, at least on the server, you can completely ignore the "Kotlin" ecosystem in favor of the Java ecosystem, and this is _shockingly_ effective. Just about every JVM framework I've seen has some kind of officially-maintained Kotlin adapter, presumedly because it's not hard to sell Java developers on "what if you could keep using the exact same tools with a nicer language." These adapters aren't even needed, mind you, they just provide nicer APIs that can use Kotlin language features. Javalin + JDBI is infinitely nicer out of the box than trying to turn Express and Knex into a production-ready API with anything approaching type safety.
* This isn't a make-or-break thing, but Kotlin is just generally _nicer_ than JS or TS in a lot of ways, while still having a very similar programming style. For example, the collection types are far more robust than something like Lodash (let alone the absolute joke that is the ES6 Map/Set API).
* Agreed with the problem, although I've found io-ts to be great. For incoming client requests: GraphQL is helpful if you're using that, but it's also relatively trivial to create an io-ts middleware for express that will get you similar guarantees. For database interaction, assuming you're talking about relational data stores, this is a challenge. Personally, I'm using Mikro ORM and it has been great so far. The one blessing here is that you're probably not dealing with unknown data types when talking to a data store, so it hasn't felt like as much of a concerning surface area for me personally. HTTP is valid, but I actually like io-ts as an approach here possibly more than using Jackson with static types due to its failure model - but again I acknowledge this is a personal choice.
* I guess it depends on your needs here, but base express can be great for simple apps, and NestJS is fantastic for more complex ones. You're 100% on point with ORMs, though, where I've been incredibly dissatisfied generally. As mentioned above, I've recently stumbled on Mikro ORM which takes a unit of work pattern similar to Hibernate, without the painful startup time. You can tell it's not perfect, and certainly not as feature rich as Hibernate, but also feels safe enough. I imagine if you tried to do everything through the ORM it could get painful, but most of my apps are structured as multiple modules where each module only controls the entities within that module. It keeps the reach of the ORM limited and abstracted behind "services" (in the modular monolith sense, not remote services).
* Yeah I see both ends of this one. Historically been a JVM user and have a ton of appreciation for it, but also like TS's approach more than Kotlin in several ways. You're right about collections though, ES6 is a joke there.