[whizzter]

Go's structural typing allows for quite a lot of flexibility often otherwise only found in scripting languages (I would suspect that this was the single biggest reason as to why the TypeScript folks started to move to Go for the ported compiler rather than something like dotnet based like C#).

[stpedgwdgfhgdd]

There is an interview with the architect and he explained that Go language maps quite nicely onto the Typescript language (e.g. garbage collector). And of course a lot faster due to concurrency and native binary. 6 times increase iirc.

[pjmlp]

Indeed, and then at BUILD he ended up describing how they needed anyway to redo all data structures due to differences on the type system.

[pjmlp]

Go's strucutural typing already existed in languages of the ML linage, nothing new.

F# can do that just fine, if the team actually cared about using .NET.

[yomismoaqui]

After hearing the explanation about why he picked Go for the Typescript compiler I can only be more of a fan of Anders Hejlsber.

He said that Go was chosen due to its suitability for the workload, offering low-level control, optimized native code, automatic memory management, and concurrency.

And this coming from the same guy that created C#, Typescript, Delphi & Turbo Pascal shows how a real engineer takes a decision of this magnitude.

Is Go the best decision for every SW project? No, but in this case the arguments (and the tests they did during their evaluation) check out.

And no, picking F# simply because you love the language is not a mature decision.

You can check his arguments here:

https://www.youtube.com/watch?v=pNlq-EVld70

[pjmlp]

I know, you are telling the fisher how to fish.

See the BUILD 2025 talk, where he explains the data structures redesign to fit into Go's lesser type system.

[snickerdoodle12]

.net is also a pain to distribute since it typically isn't packaged as a single static binary and requires a separately installed runtime

[pjmlp]

Mono AOT has existed for quite a while, .NET Native also existed, and it isn't .NET fault if people cannot know about Native AOT.

I don't buy any of reasoning why Typescript team adopted Go, first of all the authors are more than knowledgeable about .NET AOT capabilities.

Second as Anders Hejlsberg went through his BUILD 2025 talk, turns out they had to redesign the data structures around Go's weaker type system anyway, as they couldn't easily map what they were doing with TypeScript types.

Third, Azure teams are using AI to convert C++ projects into Rust, as described by Mark Russinovich at RustConf UK 2025, which shows it is up to the challenge at hand.

[snickerdoodle12]

All I know is that, as a user, whenever I encounter a .net project I have to put in more effort to run it versus a golang project.

This matters for these tools because they're usually distributed via npm packages and then invoked by a javascript wrapper. So you want something with a small binary that runs on pretty much every windows/mac/linux system no matter the configuration.

[pjmlp]

I bet those Go projects did not used CGO, and if they did would you blame the users or Go?

[snickerdoodle12]

I don't know what you're hoping to hear, but I have no idea. All I know is that with loads of Go projects I've used I can go to the releases page, download a binary and run it.

And that for every .net project I can remember, which are far more rare, there's been some complicated installer that does a bunch of stuff. Or it fails to launch telling me I need to install some runtime separately.

[trenchpilgrim]

I compile and distribute a Go app using CGO targeted at non-programmers. I hand them a single EXE file and they run it. They don't need to install anything else. It's so easy.