4 ms·

Would you say C# AOT could have been competitive in startup time and overall performance, and the decision came down to the other factors you've noted? I think

Would you say C# AOT could have been competitive in startup time and overall performance, and the decision came down to the other factors you've noted? I think everyone would have expected C# AOT to be the default choice so it might be nice to see some more concrete examples of where Go proved itself more suitable for your use-case.

RyanCavanaugh 2y ago
C# AOT is quite strong and would be a great choice in a lot of contexts. Go was just very, very strong on port-friendliness when coming from the TS codebase in particular. If you pull up both codebases side-by-side, it's hard to even tell which is which. C# is more class-oriented and the core JS checker uses no classes at all, so the porting story gets quite a bit more difficult there.
- fabian2k 2y ago
  Idiomatic C# is typically quite different and heavily class-based, but then a compiler would usually look very different than an Enterprise C# application anyway. You can use C# more in a functions and data structures way, I don't think there is something fundamental blocking this. But I guess there are many more subtle differences here than I can think of. Go is still quite a bit lower level than C#.
- i_s 2y ago
  Couldn't you just use static classes? I don't see how that would be a factor at all, seems like a very superficial reason that would be easy to work around.
  - 9rx 2y ago
    Remember, code is written for humans. It is not so much a technical limitation as it is a social limitation. Working in a codebase that does not adhere to the idioms of a language will quickly become a pain point. The Go code is not that far off how one would write it even if it were being written from scratch. A C# project littered with static classes is not at all how one would write it from scratch.
    - neonsunset 2y ago
      Static methods and classes are commonplace and a normal practice in C#, particularly as extension methods (which, quite often, you guessed it, act on data). There isn't that much difference between a type defining simple instance methods and defining extension methods for that type separately if we look at codebases which need to have specific logic grouped in a single multi-KLOC file like, apparently, TS compiler does. There are other issues you could argue about but I think it's more about perception here and structuring the code would've been the smallest issue when porting. The ship has sailed so not much can be done at this point.
      - 9rx 2y ago
        > Static methods and classes are commonplace and a normal practice in C# Certainly. The feature is there for a reason. That does not mean that you would write the codebase in that way if you were starting from scratch. You would leverage the entire suite of features offered by C# and stick to the idioms of the language. You would not constrain yourself to writing Go code that just happens to have C# syntax. > The ship has sailed so not much can be done at this point. It has been ported to a new language before. It can be ported to a new language again. But there wasn't a compelling reason to choose C# last time, and nothing significant has changed since to rethink that.
        neonsunset 2y ago
        > It has been ported to a new language before. It can be ported to a new language again. But there wasn't a compelling reason to choose C# last time, and nothing significant has changed since to rethink that. Edited and responded in the follow-up comment.
        9rx 2y ago
        > This sounds a bit like being phrased in bad faith in my opinion. Why? That certainly wasn't the intent, but I am happy to edit it if you are willing to communicate where I failed. > I do not understand why Go community feels like it has to come up with new lies (e.g. your other replies) every time. I don't know anything about this Go community of which you speak, but typically "community" implies a group. My other replies are not of that nature. But if you found a lie in there that I am unaware of, I am again happy to correct. All I've knowingly said is that Go was chosen because its idioms most closely resemble the original codebase and that C# has different idioms. Neither are a lie insofar as it is understood. There is an entire FAQ entry from the Typescript team explaining that. If the Typescript team is lying, that is beyond my control. To pin that on me is, well, nonsensical.

RyanCavanaugh 2y ago

C# AOT is quite strong and would be a great choice in a lot of contexts. Go was just very, very strong on port-friendliness when coming from the TS codebase in particular. If you pull up both codebases side-by-side, it's hard to even tell which is which. C# is more class-oriented and the core JS checker uses no classes at all, so the porting story gets quite a bit more difficult there.

fabian2k 2y ago
Idiomatic C# is typically quite different and heavily class-based, but then a compiler would usually look very different than an Enterprise C# application anyway. You can use C# more in a functions and data structures way, I don't think there is something fundamental blocking this. But I guess there are many more subtle differences here than I can think of. Go is still quite a bit lower level than C#.
i_s 2y ago
Couldn't you just use static classes? I don't see how that would be a factor at all, seems like a very superficial reason that would be easy to work around.
- 9rx 2y ago
  Remember, code is written for humans. It is not so much a technical limitation as it is a social limitation. Working in a codebase that does not adhere to the idioms of a language will quickly become a pain point. The Go code is not that far off how one would write it even if it were being written from scratch. A C# project littered with static classes is not at all how one would write it from scratch.
  - neonsunset 2y ago
    Static methods and classes are commonplace and a normal practice in C#, particularly as extension methods (which, quite often, you guessed it, act on data). There isn't that much difference between a type defining simple instance methods and defining extension methods for that type separately if we look at codebases which need to have specific logic grouped in a single multi-KLOC file like, apparently, TS compiler does. There are other issues you could argue about but I think it's more about perception here and structuring the code would've been the smallest issue when porting. The ship has sailed so not much can be done at this point.
    - 9rx 2y ago
      > Static methods and classes are commonplace and a normal practice in C# Certainly. The feature is there for a reason. That does not mean that you would write the codebase in that way if you were starting from scratch. You would leverage the entire suite of features offered by C# and stick to the idioms of the language. You would not constrain yourself to writing Go code that just happens to have C# syntax. > The ship has sailed so not much can be done at this point. It has been ported to a new language before. It can be ported to a new language again. But there wasn't a compelling reason to choose C# last time, and nothing significant has changed since to rethink that.
      - neonsunset 2y ago
        > It has been ported to a new language before. It can be ported to a new language again. But there wasn't a compelling reason to choose C# last time, and nothing significant has changed since to rethink that. Edited and responded in the follow-up comment.
        9rx 2y ago
        > This sounds a bit like being phrased in bad faith in my opinion. Why? That certainly wasn't the intent, but I am happy to edit it if you are willing to communicate where I failed. > I do not understand why Go community feels like it has to come up with new lies (e.g. your other replies) every time. I don't know anything about this Go community of which you speak, but typically "community" implies a group. My other replies are not of that nature. But if you found a lie in there that I am unaware of, I am again happy to correct. All I've knowingly said is that Go was chosen because its idioms most closely resemble the original codebase and that C# has different idioms. Neither are a lie insofar as it is understood. There is an entire FAQ entry from the Typescript team explaining that. If the Typescript team is lying, that is beyond my control. To pin that on me is, well, nonsensical.