Go was chosen mainly because it aligned more with how the existing compiler is designed. They did not want to redesign the compiler which eliminated C# as a choice. So Go is apparently just a better fit for quickly porting JavaScript code to.
Go was chosen mainly because it aligned more with how the existing compiler is designed. They did not want to redesign the compiler which eliminated C# as a choice. So Go is apparently just a better fit for quickly porting JavaScript code to.
That was the original motivation yes, although they acknowledged later that the weaker type system from Go required redesigning the data structures anyway.
And as proven in the recent announcement, they had to rewrite parcel from C++ into Go, as they didn't found a comparable library in Go ecosystem.
There is also another interview, where again they mention having used AI as tool for code rewriting as well.
Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
They said the prototyped in a few languages before settling on Go. Based on what you said it sounds like they didn't do a great job at that and stuck with their decision anyway.
> Also to note that it was pointed out that Native AOT wasn't up to the job, again something that both Java and C# failed not having done it properly from day one.
It's been working fine for a few years now. The only problem I know is there is little to no reflection allowed (by design) so a lot of code out there is not compatible with it yet. Not sure if that's what turned the TypeScript team away from it.
Yes, see BUILD 2025 talk for example, the section on "extreme refactoring" regarding the ASTs,
https://youtu.be/UJfF3-13aFo?t=1453
As for the AOT part, one would expect that being all Microsoft, they could work together to fix whatever were the issues with Native AOT.