[smt88]

Reasoning about generics in TypeScript isn't bad. I'm not totally sure what you meant by that. I just rewrote an API in TypeScript for Node, and I didn't spend most of my time reasoning about meta-anything. TypeScript mostly added amazing, insightful static analysis, and when I ran my code, it almost always worked perfectly at runtime. The debugger in VSCode is great, too!

[spion]

I think its a common meme that started because of the complexity of C++ templates and continues to be perpetuated by the creators (and moreso, users) of Go as an excuse to not implement generics.

Unlike C++ templates, generics in TypeScript are really simple - I'd estimate it would only take a week to get used to them.

[jamra]

I have some experience with C++'s templates, but I'm more comfortable with Generics in C# which I believe are done correctly. I view the code I saw as closer to C#'s approach to generics so I'm not sure your assumption is correct in my case.

I just don't want the extra mental overhead of writing and reading generic parameters whereas I never had to do that with javascript. I really enjoyed the concept of having types for my javascript objects, but am getting frightened at the concept of decreased readability due to generics.

[spion]

I honestly dont see the overhead.

Its impossible to have any sort of typed functional programming without generics. Even the most basic of functions, map, has a type:

  declare function map<T,U>(a:Array<T>, f: (T) => U):Array<U>

Just like functions are parameterised by their arguments, generics are types parameterised by (type) variables. They don't have to be any more complex than that. Whats the mental overhead there?

[mreiland]

C# generics are not the same creature as C++ templates. It isn't a matter of done correctly or incorrectly, it's apples and oranges.

[jamra]

Yes I know. I've done both. Typescript's syntax appears more like C#'s generics.

My issue is that I would like types for when I get data from the server, but I don't really want to deal with casting window to "any".

I personally went through the pains of learning javascript and have come out on the other side comfortable with its dynamic types. I really like the idea of compile time error checking, but I'm not sure I would stand for adding the complexity of generics.

The change in my workflow is not very difficult. For example, when I'm using plain old javascript, I use documentation to find out how to use third party libraries and DOM manipulations. Though it works out for all of my needs, I wouldn't mind adding types. Adding types on top of that would reduce casting and spelling mistakes, but it's not like I can't open up the browser and test my code with a step through debugger. I would personally prefer opening the browser and maintaining readability in my code versus having type safety in my code and giving up readability.

[spion]

I almost forgot: generic type variables are used very little outside of generic libraries. We have a 20KLOC codebase which doesn't use type variables at all and has only a single in-house written dependency [1] that declares functions with type variables.

note: This is about declaring generics, not using them. You'll still have to write Array<string> and Promise<MyType>, thats true. But its hardly any different from ArrayOfString or PromiseOfMyType in terms of readability.

If I may be so bold, I'd really encourage you to give it a spin. You just might find that your fears about readability are exaggerated.

[1]: https://github.com/doxout/promise-observer

[jamra]

I didn't catch this at the time, but I will take a look. Thanks.