6 ms·

> Why _not_ use Go? Because of its truly primitive type system, and because Microsoft already has a much better language — C#, which is both faster and can be

> Why _not_ use Go? Because of its truly primitive type system, and because Microsoft already has a much better language — C#, which is both faster and can be more high level and more low-level at the same time, depending on your needs. I am a complete nobody to argue with the likes of Hejlsberg, but it feels like AOT performance problems could be solved if tsc needed it, and tsc adoption of C# would also help push C#/.NET adoption. Once again, Microsoft proves that it's a bunch of unrelated companies at odds with each other.

9rx 2y ago
> Because of its truly primitive type system That is the main reason they gave for why they those chose Go. The parent asked "Why _not_ use Go?"
- subarctic 2y ago
  So they like having all the footguns?
  - 9rx 2y ago
    It was stated from the angle of wanting to ship software sometime this century. But there is probably some truth in what you say as well. Footguns are no doubt refreshing after being engrossed in Typescript (and C#) for decades. At some point you start to notice that your tests end up covering all the same cases as your advanced types, and you begin question why you are putting in so much work repeating yourself, which ultimately sees you want to look for better. Which, I suppose, is why industry itself keeps ending up taking that to the extreme, cycling between static and dynamic typing over and over again.
    - nipah 2y ago
      > At some point you start to notice that your tests end up covering all the same cases as your advanced types I don't think this is fair [at all], you use the types precisely to not need to be so overreliable on tests, they either tell some objective truths about your code in compile time (thus reducing the natural need for specific tests) or your type system is simply useless. Either way, I don't think the "industry" is a person that is balancing itself in a pendulum, there are more things under the sun than we can count, and millions of individuals in their everyday projects may not reason things this way, and instead just chose to "well, person X said this language is more maintainable and readable, and I trust X, so I'll use it" (which is a rational thing to do to some extent).
      - 9rx 2y ago
        > I don't think this is fair [at all], you use the types precisely to not need to be so overreliable on tests At the extreme end of the spectrum that starts to become true. But the languages that fill that space are also unusable beyond very narrow tasks. This truth is not particularly relevant to what is seen in practice. In the realm of languages people actually use on a normal basis, with their half-assed type systems, a few more advanced concepts sprinkled in here and there really don't do anything to reduce the need for testing as you still have to test around all the many other holes in the type system, which ends up incidentally covering those other cases as well. In practice, the primary benefit of the type system in these real-world languages is as it relates to things like refactoring. That is incredibly powerful and not overlapped by tests. However, the returns are diminishing. As you get into increasingly advanced type concepts, there is less need/ability to refactor on those touch points. Most seem to agree that a complete type system is way too much (especially for general purpose programming), and no type system is too little; that a half-assed type system is the right balance. However, exactly how much half-assery is the right amount of half-assery is where the debate begins. I posit that those who go in deep with thinking less half-assery is the way eventually come to appreciate more half-assery. > I don't think the "industry" is a person Nobody does.
        nipah 2y ago
        Hmmm, I think this is an interesting discussion. There's many sides I need to respond here, maybe I will not be able to cover everything but here I go. See, I fundamentally disagree that those languages are "unusable beyond very narrow tasks", because I never stated that only a complete and absolutely proven type system can provide those proofs. In fact, even a relatively mid-tier (a little bit above average) type-system like C#'s can already provide enormous benefits in this regard. See, when you test for something like raw JavaScript, you end up testing things that are even about the shape of your objects, in C# you don't have to do this (because the type system dictates the shape). You also have to be very careful around possibly null objects and values, which in a language with "proper" nullable types (and support from it in the type system and static checkers) like C# can be lowered vastly (if you use the resource, naturally). C# is also a language that "brings the types into runtime" through reflection, so it will even bring you things that you don't need to test in your code (only when developing the library) like reflection for example (you will not see things that are meant to assert shapes, like 'zod' or 'pydantic' in C# or other mid-tier typed languages for example). C#'s type system also proves many things about the safety of your code, for example you basically never need to test your usage of Spans, the type system and static analysis will already rule out most problematic usages of those things. You also never need to test if your int is actually a float because some random place in your code it was set to be so (like in JS), you also never need to test against many other basic assumptions even an extremely basic type system would give you (even Go's one). This is to say that, basically, this don't hold true for relatively simple type systems. I'm also yet to see this holding true for more advanced ones, for example: Rust is a relatively well used language for a lot of low-level projects. I never saw someone testing (well bounded safe) rust code for basic shapes of types, nor for the conclusions the type system provides when writing on it. For example, testing if the type system was really able to catch that ownership transference happening here, of it is really safe to assume that there's only one mutable reference to that object after you called that method, or if the destructor of the object is really running in the end of the scope of the function, or even if the overly complex associated type result was actually what you meant it to be (in fact, if you would ever use those complicated types, it would be precisely to have very strong compile-time guarantees that both a test would not be able to cover for -- entirely, and that you would not write unit tests specifically for in the first place). So I don't think it is true that you need a powerful type system to see the reduction in tests that you would need to write in a completely dynamically typed language, nor I think it is true when you start having really powerful type constructs, that you will come to this conclusion """start to notice that your tests end up covering all the same cases as your advanced types""". I also don't think that you need to go to the extreme of this spectrum to see those benefits, they appear gradually and increase gradually as you move towards the end (when you end up with more extremely uncommon things like dependent typing, refinement types or effect systems). I also certainly don't agree that it does matter that "most people" think or don't think about powerful type systems and the languages using them, it matters more that the right people are using them, people that want to be benefitted from this, than the everyday masses (this is another overly complex disccussion tho). And while I can understand the feelings you have towards the "low end of half-assery type systems", and even agree to a certain reasonable degree (naturally, with my own considerations), I don't think glorifying mediocre type systems is the way to go (like many people usually do, for some terrifying reason). It is enough to recognize that a half-assery type-system usually gets the job done and that's it, completely fine and okay, it may even be faster to write, instead of trying to justify that we should "pursue primitive type systems" because of the fact that we can do things well on them. Maybe I'm digressing to much, it's hard to respond to this comment in a satisfactory manner. >> I don't think the "industry" is a person > Nobody does. Yeah, this was not a very productive point of mine, sorry.
  - umvi 2y ago
    Overly expressive type systems have way more potential for footguns than simple type systems. In fact, I would say that overly expressive type systems make it easy to create unmaintainable code (still waiting on this showstopping bug which nobody can debug because it uses overly expressive types in TS: https://github.com/openapi-ts/openapi-typescript/issues/1769 https://github.com/openapi-ts/openapi-typescript/issues/1769)
    - nipah 2y ago
      I don't think TypeScript is an example of what people would call a "properly expressive type system". Sure, it is very expressive, but it is made to cover all the gaps JavaScript as a language has in a generally type safe manner, and this calls for an EXTREMELY complex and open type system, much more than most languages would ever have, so I don't think this is really appliable as an example. The gap between maintainable code and unmaintainable one sits between the chair and the screen, not in the type system of the language the person is using, the language merely makes that person more or less able to encode more things in specific places that can become unmaintenable (and anecdotally, most unmaintenable code I know don't even use complex type system features, it's just plain old messy state mutating things scatered all around).
- nipah 2y ago
  This is not "the main reason", lol, it was never stated as such. The type system could be way more powerful and, having the same general features they would probably had still picked it up.
  - 9rx 2y ago
    What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language. Let's be real: You can absolutely write "Go-style" code in just about any language that might have been considered for this. But you wouldn't want to, as a more advanced type system enables entirely different idioms, and it is in bad faith to other developers (including future you) to stray too far from those idioms. If ignoring idioms doesn't sound like a bad idea on day one, you'll feel the hurt and regret soon enough... Go was chosen because the idioms are generally in alignment with their needs and those idioms are wholly dependent on the shape of its type system.
    - nipah 2y ago
      > What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language. I would say structural typing is very "esoteric" for most strongly typed languages actually, but this is not a problem. And proceeding, the implications of your response is very strange. See, your point is essentially saying that "we should use Go, because it entails writting in only one idiom, and writing in languages that enables you to do more idioms -- more powerful languages -- is bad faith to other developers", but Hejlsberg himself said he chose go because of specific characteristics of the compiler that was already written, not because it is "the ideal one for every single prospect", while your point has implications that are absolutely more general. So I don't think he would agree with you that this was his reasoning for using go (the "don't have other idioms" thing), I also don't think this whole "more idioms" thing even make sense, but this is not needed to respond to this.
      - 2y ago
triceratops 2y ago
I'm inclined to trust the judgement of Hejlsberg, the chief architect of C#, in this matter.
Cthulhu_ 2y ago
"depending on your needs" indeed - does the TSC compiler need a stronger type system? Advanced type systems are guard rails to spot and avoid issues early on, but that role can be fulfilled by tests as well, and Typescript has a LOT of tests and use cases that will be flagged up. Does it need a strong type system for the internal tooling on top of that? I'm not an authority on the matter and know nothing about the compiler's internals, but I'm confident in saying that the type system is good enough for this use case.

9rx 2y ago

> Because of its truly primitive type system That is the main reason they gave for why they those chose Go. The parent asked "Why _not_ use Go?"

subarctic 2y ago
So they like having all the footguns?
- 9rx 2y ago
  It was stated from the angle of wanting to ship software sometime this century. But there is probably some truth in what you say as well. Footguns are no doubt refreshing after being engrossed in Typescript (and C#) for decades. At some point you start to notice that your tests end up covering all the same cases as your advanced types, and you begin question why you are putting in so much work repeating yourself, which ultimately sees you want to look for better. Which, I suppose, is why industry itself keeps ending up taking that to the extreme, cycling between static and dynamic typing over and over again.
  - nipah 2y ago
    > At some point you start to notice that your tests end up covering all the same cases as your advanced types I don't think this is fair [at all], you use the types precisely to not need to be so overreliable on tests, they either tell some objective truths about your code in compile time (thus reducing the natural need for specific tests) or your type system is simply useless. Either way, I don't think the "industry" is a person that is balancing itself in a pendulum, there are more things under the sun than we can count, and millions of individuals in their everyday projects may not reason things this way, and instead just chose to "well, person X said this language is more maintainable and readable, and I trust X, so I'll use it" (which is a rational thing to do to some extent).
    - 9rx 2y ago
      > I don't think this is fair [at all], you use the types precisely to not need to be so overreliable on tests At the extreme end of the spectrum that starts to become true. But the languages that fill that space are also unusable beyond very narrow tasks. This truth is not particularly relevant to what is seen in practice. In the realm of languages people actually use on a normal basis, with their half-assed type systems, a few more advanced concepts sprinkled in here and there really don't do anything to reduce the need for testing as you still have to test around all the many other holes in the type system, which ends up incidentally covering those other cases as well. In practice, the primary benefit of the type system in these real-world languages is as it relates to things like refactoring. That is incredibly powerful and not overlapped by tests. However, the returns are diminishing. As you get into increasingly advanced type concepts, there is less need/ability to refactor on those touch points. Most seem to agree that a complete type system is way too much (especially for general purpose programming), and no type system is too little; that a half-assed type system is the right balance. However, exactly how much half-assery is the right amount of half-assery is where the debate begins. I posit that those who go in deep with thinking less half-assery is the way eventually come to appreciate more half-assery. > I don't think the "industry" is a person Nobody does.
      - nipah 2y ago
        Hmmm, I think this is an interesting discussion. There's many sides I need to respond here, maybe I will not be able to cover everything but here I go. See, I fundamentally disagree that those languages are "unusable beyond very narrow tasks", because I never stated that only a complete and absolutely proven type system can provide those proofs. In fact, even a relatively mid-tier (a little bit above average) type-system like C#'s can already provide enormous benefits in this regard. See, when you test for something like raw JavaScript, you end up testing things that are even about the shape of your objects, in C# you don't have to do this (because the type system dictates the shape). You also have to be very careful around possibly null objects and values, which in a language with "proper" nullable types (and support from it in the type system and static checkers) like C# can be lowered vastly (if you use the resource, naturally). C# is also a language that "brings the types into runtime" through reflection, so it will even bring you things that you don't need to test in your code (only when developing the library) like reflection for example (you will not see things that are meant to assert shapes, like 'zod' or 'pydantic' in C# or other mid-tier typed languages for example). C#'s type system also proves many things about the safety of your code, for example you basically never need to test your usage of Spans, the type system and static analysis will already rule out most problematic usages of those things. You also never need to test if your int is actually a float because some random place in your code it was set to be so (like in JS), you also never need to test against many other basic assumptions even an extremely basic type system would give you (even Go's one). This is to say that, basically, this don't hold true for relatively simple type systems. I'm also yet to see this holding true for more advanced ones, for example: Rust is a relatively well used language for a lot of low-level projects. I never saw someone testing (well bounded safe) rust code for basic shapes of types, nor for the conclusions the type system provides when writing on it. For example, testing if the type system was really able to catch that ownership transference happening here, of it is really safe to assume that there's only one mutable reference to that object after you called that method, or if the destructor of the object is really running in the end of the scope of the function, or even if the overly complex associated type result was actually what you meant it to be (in fact, if you would ever use those complicated types, it would be precisely to have very strong compile-time guarantees that both a test would not be able to cover for -- entirely, and that you would not write unit tests specifically for in the first place). So I don't think it is true that you need a powerful type system to see the reduction in tests that you would need to write in a completely dynamically typed language, nor I think it is true when you start having really powerful type constructs, that you will come to this conclusion """start to notice that your tests end up covering all the same cases as your advanced types""". I also don't think that you need to go to the extreme of this spectrum to see those benefits, they appear gradually and increase gradually as you move towards the end (when you end up with more extremely uncommon things like dependent typing, refinement types or effect systems). I also certainly don't agree that it does matter that "most people" think or don't think about powerful type systems and the languages using them, it matters more that the right people are using them, people that want to be benefitted from this, than the everyday masses (this is another overly complex disccussion tho). And while I can understand the feelings you have towards the "low end of half-assery type systems", and even agree to a certain reasonable degree (naturally, with my own considerations), I don't think glorifying mediocre type systems is the way to go (like many people usually do, for some terrifying reason). It is enough to recognize that a half-assery type-system usually gets the job done and that's it, completely fine and okay, it may even be faster to write, instead of trying to justify that we should "pursue primitive type systems" because of the fact that we can do things well on them. Maybe I'm digressing to much, it's hard to respond to this comment in a satisfactory manner. >> I don't think the "industry" is a person > Nobody does. Yeah, this was not a very productive point of mine, sorry.
- umvi 2y ago
  Overly expressive type systems have way more potential for footguns than simple type systems. In fact, I would say that overly expressive type systems make it easy to create unmaintainable code (still waiting on this showstopping bug which nobody can debug because it uses overly expressive types in TS: https://github.com/openapi-ts/openapi-typescript/issues/1769 https://github.com/openapi-ts/openapi-typescript/issues/1769)
  - nipah 2y ago
    I don't think TypeScript is an example of what people would call a "properly expressive type system". Sure, it is very expressive, but it is made to cover all the gaps JavaScript as a language has in a generally type safe manner, and this calls for an EXTREMELY complex and open type system, much more than most languages would ever have, so I don't think this is really appliable as an example. The gap between maintainable code and unmaintainable one sits between the chair and the screen, not in the type system of the language the person is using, the language merely makes that person more or less able to encode more things in specific places that can become unmaintenable (and anecdotally, most unmaintenable code I know don't even use complex type system features, it's just plain old messy state mutating things scatered all around).
nipah 2y ago
This is not "the main reason", lol, it was never stated as such. The type system could be way more powerful and, having the same general features they would probably had still picked it up.
- 9rx 2y ago
  What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language. Let's be real: You can absolutely write "Go-style" code in just about any language that might have been considered for this. But you wouldn't want to, as a more advanced type system enables entirely different idioms, and it is in bad faith to other developers (including future you) to stray too far from those idioms. If ignoring idioms doesn't sound like a bad idea on day one, you'll feel the hurt and regret soon enough... Go was chosen because the idioms are generally in alignment with their needs and those idioms are wholly dependent on the shape of its type system.
  - nipah 2y ago
    > What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language. I would say structural typing is very "esoteric" for most strongly typed languages actually, but this is not a problem. And proceeding, the implications of your response is very strange. See, your point is essentially saying that "we should use Go, because it entails writting in only one idiom, and writing in languages that enables you to do more idioms -- more powerful languages -- is bad faith to other developers", but Hejlsberg himself said he chose go because of specific characteristics of the compiler that was already written, not because it is "the ideal one for every single prospect", while your point has implications that are absolutely more general. So I don't think he would agree with you that this was his reasoning for using go (the "don't have other idioms" thing), I also don't think this whole "more idioms" thing even make sense, but this is not needed to respond to this.
    - 2y ago

triceratops 2y ago

I'm inclined to trust the judgement of Hejlsberg, the chief architect of C#, in this matter.

Cthulhu_ 2y ago

"depending on your needs" indeed - does the TSC compiler need a stronger type system? Advanced type systems are guard rails to spot and avoid issues early on, but that role can be fulfilled by tests as well, and Typescript has a LOT of tests and use cases that will be flagged up. Does it need a strong type system for the internal tooling on top of that? I'm not an authority on the matter and know nothing about the compiler's internals, but I'm confident in saying that the type system is good enough for this use case.