5 ms·

I'm really surprised by this visceral reaction to not choosing Rust. Go is a great language and I'd choose it for a majority of projects over Rust just based of

by dimgl 2y ago

I'm really surprised by this visceral reaction to not choosing Rust. Go is a great language and I'd choose it for a majority of projects over Rust just based off of the simplicity of the language and the ability to spin up developers on it quickly. Microsoft is a big corporation. Why _not_ use Go?

homebrewer 2y ago
> 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
    - 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.
dmix 2y ago
Do we need to have these conversations weekly?
- dimgl 2y ago
  I wouldn't be asking if there wasn't a visceral reaction from Rust devs. I must have missed previous discussions on other threads.
  - J_Shelby_J 2y ago
    Is this visceral reaction in the room with us now? Edit: I have reached the bottom of the thread and still have not seen this visceral reaction mentioned by the OP.
    - dimgl 2y ago
      https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 There's more reactions here. I think devs have lost the plot, tbh.
      - gauge_field 2y ago
        I am not sure if we see the same thread. There is one reaction from "Rust" dev (who seems have a very new account on github) on why not rust. Most of the others seem to be from C# side. The pattern also seems to be the same on reddit thread. There is one post about why not rust, equally (or more depending how you weigh) is how other people react to this news. What is weird is how much people talk about how other people react. Modern social media is weird
        hitekker 2y ago
        There's at least 3 top-level threads criticizing the decision not to rewrite in Rust. Including a RIR banner ad posted in the replies. Holy Language Wars are a spectator sport as old as the internet itself. It's normal to comment on one side fighting another. What's weird is pretending not to see the fighting

by dimgl 2y ago

homebrewer 2y ago

> 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
  - 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.

dmix 2y ago

Do we need to have these conversations weekly?

dimgl 2y ago
I wouldn't be asking if there wasn't a visceral reaction from Rust devs. I must have missed previous discussions on other threads.
- J_Shelby_J 2y ago
  Is this visceral reaction in the room with us now? Edit: I have reached the bottom of the thread and still have not seen this visceral reaction mentioned by the OP.
  - dimgl 2y ago
    https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411 There's more reactions here. I think devs have lost the plot, tbh.
    - gauge_field 2y ago
      I am not sure if we see the same thread. There is one reaction from "Rust" dev (who seems have a very new account on github) on why not rust. Most of the others seem to be from C# side. The pattern also seems to be the same on reddit thread. There is one post about why not rust, equally (or more depending how you weigh) is how other people react to this news. What is weird is how much people talk about how other people react. Modern social media is weird
      - hitekker 2y ago
        There's at least 3 top-level threads criticizing the decision not to rewrite in Rust. Including a RIR banner ad posted in the replies. Holy Language Wars are a spectator sport as old as the internet itself. It's normal to comment on one side fighting another. What's weird is pretending not to see the fighting