5 ms·

I wish developers of TypeScript would learn from Go. TypeScript is awesome, but it is getting larger and larger and larger with every release. Soon it will beco

I wish developers of TypeScript would learn from Go. TypeScript is awesome, but it is getting larger and larger and larger with every release. Soon it will become like the US tax code, and no one person will know the entire language.

sek 7y ago
I think the situation with TypeScript is a little different. JavaScript is a very powerful language and you can do a lot of "hacky" things with it. It feels to me like most new features are an improvement, I use :any very rarely now and can model almost everything with it. I you would design TypeScript from scratch, you might have a point.
erokar 7y ago
No wonder, since the man behind Typescript, Anders Hejlsberg, is also the man behind C#. The goal seems to be to include as much as possible and constantly evolve the language. Some people appreciate that, others not so much.
- thomasz 7y ago
  Typescript utilizes black magic to help building large systems based on the shaky foundations of javascripts type system. C# is very conservative in comparison. It only adds concepts that have been implemented by (often times several) other languages before, and are therefore well understood.
frou_dh 7y ago
The armchair psychologist in me considers there to be two camps of programmer in this regard. One that gets distressed by something like not having the entire language in their head, and the other that doesn't ponder that kind of quandary in the first place.
- deleted 7y ago
  [deleted]
- phamilton 7y ago
  I've shifted toward the latter as I've embraced type systems that can substitute for having the entire language in my head. At the end of the day, I rarely care about the language. I usually just care about my data morphisms. And a good type system helps me immensely in that regard.
- tfha 7y ago
  That's really not it. The more complex a language is, the more ways there are to approach a problem. The more things to have to learn and adapt to when reading code another engineer wrote. You want code to be obvious. The senior engineer smiles when the junior engineer reads his code and says in just seconds "I know exactly what this does and have high confidence that it has no bugs." Simpler languages facilitate simpler codebases.
- deleted 7y ago
  [deleted]
TorbjornLunde 7y ago
TypeScript's complexity comes from trying to model typical JavaScript patterns using a compile-time type system. It turns out trying to model a dynamic language's typical usage at compile-time is lead to some complicated stuff. Personally I think it's mostly worth it since most of that is hidden behind API-boundries or (more commonly) in type-definition files and your own code typically either has really simple type annotations or is inferred (i.e. not explicitly type annotated). But I see your point and it does sorta feel a bit C++-like in this respect sometimes.
implicit 7y ago
For what it's worth, I get the feeling that the reason TypeScript is growing so much complexity is not because the language designers expect you personally to use it all. It's there primarily so that your development environment can give you accurate feedback when you're using your favourite JS libraries.
- thomasz 7y ago
  Exactly. The <title> of typescriptlang.org is "javascript that scales". All those features in TypeScript exists to express common js idioms in terms of a static type system, which in turn enables stuff that makes programming in the large easier.
aikah 7y ago
Typescript's goal is to represent the complexity of a dynamically typed language with type annotations so you can run static type analysis and verification. Typescript shouldn't learn anything from Go, because their goals are completely different. The great thing with Typescript is that you don't have to use all its spec to benefit from it, so no user has to know the entire spec. But you can't complain that Typescript does exactly what it was invented for. Blame Javascript.

sek 7y ago

I think the situation with TypeScript is a little different. JavaScript is a very powerful language and you can do a lot of "hacky" things with it. It feels to me like most new features are an improvement, I use :any very rarely now and can model almost everything with it. I you would design TypeScript from scratch, you might have a point.

erokar 7y ago

No wonder, since the man behind Typescript, Anders Hejlsberg, is also the man behind C#. The goal seems to be to include as much as possible and constantly evolve the language. Some people appreciate that, others not so much.

thomasz 7y ago
Typescript utilizes black magic to help building large systems based on the shaky foundations of javascripts type system. C# is very conservative in comparison. It only adds concepts that have been implemented by (often times several) other languages before, and are therefore well understood.

frou_dh 7y ago

The armchair psychologist in me considers there to be two camps of programmer in this regard. One that gets distressed by something like not having the entire language in their head, and the other that doesn't ponder that kind of quandary in the first place.

deleted 7y ago
[deleted]
phamilton 7y ago
I've shifted toward the latter as I've embraced type systems that can substitute for having the entire language in my head. At the end of the day, I rarely care about the language. I usually just care about my data morphisms. And a good type system helps me immensely in that regard.
tfha 7y ago
That's really not it. The more complex a language is, the more ways there are to approach a problem. The more things to have to learn and adapt to when reading code another engineer wrote. You want code to be obvious. The senior engineer smiles when the junior engineer reads his code and says in just seconds "I know exactly what this does and have high confidence that it has no bugs." Simpler languages facilitate simpler codebases.
deleted 7y ago
[deleted]

TorbjornLunde 7y ago

TypeScript's complexity comes from trying to model typical JavaScript patterns using a compile-time type system. It turns out trying to model a dynamic language's typical usage at compile-time is lead to some complicated stuff. Personally I think it's mostly worth it since most of that is hidden behind API-boundries or (more commonly) in type-definition files and your own code typically either has really simple type annotations or is inferred (i.e. not explicitly type annotated). But I see your point and it does sorta feel a bit C++-like in this respect sometimes.

implicit 7y ago

For what it's worth, I get the feeling that the reason TypeScript is growing so much complexity is not because the language designers expect you personally to use it all. It's there primarily so that your development environment can give you accurate feedback when you're using your favourite JS libraries.

thomasz 7y ago
Exactly. The <title> of typescriptlang.org is "javascript that scales". All those features in TypeScript exists to express common js idioms in terms of a static type system, which in turn enables stuff that makes programming in the large easier.

aikah 7y ago

Typescript's goal is to represent the complexity of a dynamically typed language with type annotations so you can run static type analysis and verification. Typescript shouldn't learn anything from Go, because their goals are completely different. The great thing with Typescript is that you don't have to use all its spec to benefit from it, so no user has to know the entire spec. But you can't complain that Typescript does exactly what it was invented for. Blame Javascript.