[RyanCavanaugh]

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.

[i_s]

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]

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]

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]

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

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

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

[fabian2k]

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