Hacker News Reader

Comment by pjmlp | Hacker News Reader

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.

View on HN

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.

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

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.

The point is that when you happen to compile yourself Go projects, and CGO is used, you better have the C or C++ compiler toolchain installed that is compatible with Go, with the related dependencies they rely on, otherwise the build will break.

But you won't be blaming Go for that, rather the devs that decided to use CGO.

Likewise, when downloading some .NET project, it isn't .NET to blame, if the devs have decided they wouldn't be making use of Mono AOT, Native AOT, or single-file deployment package (with ReadyToRun).

> The point is that when you happen to compile yourself...

He made it pretty clear that he doesn't compile himself, he downloads pre-built binaries. In one case he finds that once the binary is downloaded, it just runs. In the other he finds it requires additional steps, like needing to go through an arduous installation process, before it runs.

Sure, better devs can figure out how to avoid things like the aforementioned installation process. Great devs aren't limited by their tools. But pointing out that the devs attracted to that ecosystem are not very good doesn't change much. That it requires one to be good echos the "pain" assertion. If it weren't painful, even the poor devs would do it.

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.

Great news, .NET Native AOT is exactly the same.

Reply on news.ycombinator.com