This is why I have been cautious about TypeScript. Quite often it leaves me with impression that it's a language that enables the same kind of type astronaut developer that also hurts Rust. Except in TS this truly has no benefit besides superficial perception of improved type safety.
Please, if you have powerful type system, it does not mean it warrants pushing it to its limits, and strikes me as the behavior everyone tends to suffer from in the middle of a learning process of a new tool.
> Except in TS this truly has no benefit besides superficial perception of improved type safety.
You know the saying that everyone who drives slower than you is a moron, and everyone who drives faster than you is a lunatic? You seem to be in a mode of "every type system more powerful than what I'm used to is unnecessary", and I'm sure you believe the other half: "every type system weaker than what I'm used to is for morons".
Keep in mind, this article is about a detail inside the compiler that makes type inference "just work" seemingly magically. It's not a detail you need to worry about. If you think powerful type inference and mapped types are just for the "perception of improved type safety", you are revealing that you have simply never attempted to learn them.
> if you have powerful type system, it does not mean it warrants pushing it to its limits, and strikes me as the behavior everyone tends to suffer from in the middle of a learning process of a new tool.
These kinds of features are more for library developers. You should be very glad that the people who make the libraries you rely on every day have access to these kinds of features, because when they do their job well, things "just work" so invisibly that you have no way of appreciating what's actually going on in the background. These "astronaut developers" that you disrespectfully deride are the entire reason you're able to do your job at all. Have a little respect.
If you pay attention to phrasing "hurts Rust", you may notice that this isn't a criticism of TS by itself but rather the misuse of its type system, and the certain set of commonly adopted norms that I personally happened to get presented with when interacting with it in the past, examples in this article being a continuation of the trend.
It isn't about expressivity or lack of thereof but unnecessary steps taken to achieve point B from point A.
Is pretty great if these features are constrained to a utility function or library though.
Being able to put your types in as an arg and keep the other parts in sync in the editor without having to write a bunch of boilerplate just to define one-off types. I find it speeds up dev and reduces the amount of application code that needs testing overall.
There is no such thing, typescript has features like inferred type params and conditional types. I dont see the point of writing a fancy article just to give them a new name.
Actually I re read the article, not what I thought and this indeed was one thing that puzzled me that turns out to be an undocumented typescript feature.
While technically used like types, TypeScript "types" are really compile-time values that happen to be also usable for constraining usual run-time values like types. These compile-time values themselves do not have much types, so you can easily get errors from compile-time evaluations (which is different from compile-time type errors!). Likewise, most TypeScript type-level constructs are really long-winded methods to do the compile-time computation and have no straightforward equivalents in type systems that do guarantee the soundness and coherence (which have specific definitions).
TypeScript has a very different set of axiomatic operations than conventional type theory.
It incorporates concepts from set theory, you have unions T|U, intersections T&U, comprehensions { [T in U]: e(T) }, conditionals (T extends U ? A : B ), pattern matching (infer T), and the typeof operator is like a poor man’s dependent typing.
While you could certainly express all of these concepts in a language with dependent types, you can’t emulate the inference rules (the subject of TFA), so it can be said that TypeScript’s type theory is unique.
> This is the lingo used in the compiler's source code, in the PRs and in the issues on GitHub.
> When you have to infer the T from a MappedType<T>, you are inverting the action of the MappedType. There is a dedicated part in the compiler for doing that.
Alternative title: how to write unmaintainable, unreadable code that nobody understands and cannot be fixed or modified without introducing compiler errors for code that just works.
These features are why I don’t like Typescript. It is too complicated.
1) the destructive yet not helpful nature of your post. What are better alternatives to write JavaScript than TS? Elm and flow are not.
2) not realizing that any powerful type system (or language) has advanced concepts, this isn't exclusive to TypeScript
3) Not realizing this is mostly a tool for library authors to provide better inference to API consumers
4) Last but not least, 99% of TypeScript users can't even tell what a mapped type is (it's in the docs) nor define it or say when to use it, people don't even bother to read the docs fundamentals so attitudes like yours are unsurprising
5) Typescript is verbose, but very simple to follow and read if you know the basics. It's unmaintainable only because people don't bother to master any topic
> What are better alternatives to write JavaScript than TS? Elm and flow are not.
Why do you want to write javascript ? Most self-respecting programming languages have a javascript backend (Let's list a few pretty ones: Rust, OCaml, Haskell). There's no need to manually generate javascript and you can treat it like you would treat assembly language: something you don't want to touch 99% of the time.
None of the languages you list allow a small team to move ahead web, native and server code with ease.
None of the languages you list make hiring easy, at all.
None of the languages you list are easy to setup across platforms/cloud environments.
None of the languages you list make handling a monorepo simple.
I am most certain (I know Haskell, lisps, Elm, C, Java, Scala) that there are different good tools for different use cases, but I ain't picking any of those 9 times out of 10 without a solid reason to do so in the context of web development.
I wouldn't say this. It can bring complications, yes: but only because like a lot of expressive tools people will over-engineer things with them (probably like this sentence)
To me, Typescript saved JavaScript from under-constraining. It's bringing me some peace of mind.
A common convention I've seen is using T at the start of a type parameter, [1] for example. TKey, TData, TError, TSuccessCallback, etc. I always liked T at the end, but I've not seen that as often.
Please, if you have powerful type system, it does not mean it warrants pushing it to its limits, and strikes me as the behavior everyone tends to suffer from in the middle of a learning process of a new tool.