TypeScript is in a unique position. It's basically a set of extensions to JavaScript, and with a very short list of exceptions, those extensions only affect the type system. You can mostly just convert TypeScript to JavaScript by going through your source files, selecting various ranges of text, and pressing "delete" on your keyboard. This is more or less how the TypeScript compiler compiles your code anyway.

The exception I can think of is enum types. These always result in some amount of generated code.

TypeScript can also apply some other transformations to your code during compilation, but as far as I know that's just so you can use newer JavaScript language features and target older JavaScript runtimes.

I don't want to stretch metaphors too far here but there's some truth in what you're saying. TypeScript usage is a tiny minority of JavaScript usage but it's climbing and I'm sure it's much higher than CoffeeScript ever was.

But I see TypeScript as a different beast altogether because of its aims. CoffeeScript and Kotlin were both created to make a complicated messy language more straightforward and powerful. TypeScript aims to make JavaScript safer by introducing types. If anything it slows development down, not makes it faster (and before someone jumps on me for saying that: yes, I think it's worth the price). IMO that makes comparisons difficult.

> TypeScript usage is a tiny minority of JavaScript usage

shudders at the thought

After using TypeScript for almost 5 years now, I can not imagine a scenario where I would write JavaScript without type safety - other than a 5 minute POC to test something out.

I look forward to the day when TypeScript can be compiled to wasm binaries and it can be a language all on it's own rather than a superset/wrapper of JavaScript.

I like TypeScript but I think there's a complexity threshold — if you have a massive collection of other people's code, types are essential. If you're building a basic web app which is using the built-in behaviour and have a reasonably modern editor + linter + test setup, type safety is still good but it buys you less than it does when your baseline complexity level is higher.

Since modern browsers and JavaScript give you a lot of functionality out of the box which people used to use libraries for, there are quite a few projects which are under that threshold.

For smaller projects, I find that the value is less the type safety (still valuable) and more the much stronger control of intellisense. Yeah, if you have a language server that's able to deal with typings your JS code will still be a lot better than without it, but starting with TypeScript just makes that way more fluid. I find that I write TypeScript much more quickly, and more correctly, than I do JavaScript, both for small and large projects.

I agree that TS is a good pragmatic choice for any non trivial amount of code but I am still surprised how bad it is.

Error messages in TypeScript are quite cryptic for a modern language. Compiling it is super slow. Type safety, well they are doing their best considering the very dynamic nature of JavaScript but now if we compare it to other languages that compile to JS like Elm, it is just not that huge of a step.

With Elm you get a guarantee of no runtime exceptions at all in productions plus the most helpful compiler ever written. Even compilation time feels much faster. Similiar for competitors like ReScript, Purescript and the like.

Of course TypeScript is the easiest to learn for established JS Developers. And I am quite grateful that the option exists but I just wish it would be better considering how much money is put into it.

Typescript is completely different from Elm.

Elm is an entirely different language. Typescript is little more than a typing layer on top of JavaScript.

As such, your typescript should look almost exactly like your JS would, with the only difference being that all your variables are now typed.

That's fair, though I will say Kotlin's type system having nullability built-in is something I doubt Java will ever fully add (instead of the annotations it currently uses). So in that respect, it's making it more type safe, but the delta between Kt and Java isn't near as big as TS and JS.

It can’t have it built-in without breaking backwards compatibility. NullAway adds this feature by enforcing sane use of @Nullable annotations.

> If anything it slows development down, not makes it faster

It doesn't really "slow development down", it just forces you to explicitly specify the data structures that exist whether you decide to acknowledge them or not. Eschewing types is just a form of technical debt that every developer has to repay as they deduce the application data structures through trial and error, often times in production.

My guess is that people who feel that types "slow development down" just haven't become sufficiently familiar with the type system.

In languages I am familiar with, types are just muscle memory. If anything, development is faster because of code completion.

In languages I am learning, yes there tends to be some fumbling with the type system. But that fades with experience.

Indeed, and Type-Driven Development is also a thing.

Given a great type system and editor/IDE types can even be used to derive implementations.

Scala still has a reasonably strong following :) I think largely as a result of Spark.

That strong following might not last. My company made the decision to have PySpark be the default for training and future greenfield Spark projects, and they're only really making official what's been the reality for the past few years. A shame, as Scala seems like a nice language but I've never really gotten into it as Python is always the preferred option.

It's true that PySpark probably is overtaking (or already has overtaken) Spark with Scala. I still personally like Scala over Java in general for non-Spark projects as it's much less verbose which is my main problem with Java. However, I also haven't used all the new Java features to see how that would adjust the comparison for me.