> Pity that they didn't go with AOT compiled .NET, though.

Yeah. It seems to be unfashionable somewhat even within Microsoft.

(edit: it seems to be you and me and barely anyone else on HN advocating for C#)

Also, this is surprising because this was presented and led by Anders Hejlsberg, who is the creator of both C# and Typescript.

If anyone should have picked C# it would be him.

Hejlsberg seemed quite negative when it came to cross platform AOT compiled C# in several comments he's made, hinting at problems with both performance and maturity on certain platforms.

Projects like this are needed to improve C#'s cross platform AOT. Missed opportunity IMO.

Absolutely. Go is where it is because of the parent org's commitment to dogfooding it; strange that Microsoft is wasting this opportunity AND sending a negative message to .NET devs.

Sure, but this team's focus is on Typescript, not C# / cross-platform AOT; there's only so much time in a day. Others can pick it up I'm sure.

But I think it's also an indication that Typescript may be bigger and more important for Microsoft than C#/.NET is at this time. It's definitely much more used than C# is according to this non-representative survey of Stack Overflow (https://survey.stackoverflow.co/2024/technology).

At the same time, if anyone can make a language choice, it's him - the fact he didn't pick his own language is high praise for both himself and his neutrality, and the Go language.

Go compiler tooklit works very well on all the OSes. That would be a consideration.

So does the .NET compiler. That is not the issue.

This was also surprising to me – C# is a really awesome and modern language.

I happened to be doing a lot of C# and .NET dev when all this transition was happening, and it was very cool to be able to run .NET in Linux. C# is a powerful language with great and constantly evolving ideas in it.

But then all the stuff between the runtimes, API surfaces, Core vs Framework, etc all got extremely confusing and off-putting. It was necessary to bring all these ecosystems together, but I wonder if that kept people away for a bit? Not sure.

All Azure contributions to CNCF are using a mix of Go and Rust, mostly.

Here is a kind of weird, given the team.

I think the main thing is that they are porting, not re-writing. Current tsc is functional by nature and that's makes go better fit.

I think the much larger ask C# couldn't answer is the "expressive" access to low level struct layout[1]

[1] https://www.youtube.com/watch?v=10qowKUW82U&t=769s

If I recall in an article from a while back, the idea was originally rust, but the current compiler design had lots of references shared references that would make the port to rust a lot of work.

Personally, Rust only makes sense in scenarios that automatic memory management of any kind is either unwanted, or it is a quixotic battle making the target group think otherwise.

OS kernels, firmware, GPGPU,....

If it is the ML inspired type system, there are plenty of options among compiled managed languages, true Go isn't really on that camp, but whatever.

Or possibly you want to use a language you're familiar with in adjacent spaces (eg tools) or you want to tackle concurrency bugs more directly. There is more to rust than it's

Rust memory management is automatic. Object destructors run when the object exits scope without needing explicit management by the programmer

More like compiler assisted management, with compiler errors when the developer doesn't follow the teacher.

The compiler ensures you are writing memory safe code. Otherwise it rejects that code and helps you see the mistake you made. Why people are so upset when the compiler prevents them from building and shipping unusable code will always baffle me.

There is nothing automatic in that.

Asking a compiler to understand a programmers intent for underspecified mutability is beyond the halting problem.

Theres a huge gap between inefficient and unusable. There’s a lot of usable code out there that leaks memory. I’d argue compilers are hardly pressed by memory usage given the transient nature of their execution.

Saying rust is unusable is pretty extreme. Tons of serious applications and infrastructure have been using it in production for years generating lots of money and preventing CVEs.

Leaking memory is sometimes not a huge issue. Missile allocation is real. Undefined behaviour, seg faults, data races, etc from edge cases slow down development.

The promise of rust isn't that it's super fast to learn but once you have you never deal with a swath of issues ever again.

And that's speaking from a deficit. Rust is an excellent language to do language development. It has arguably the best tooling for it in the ecosystem in my opinion and a vibrant community for it. Some of the most recent languages have foundations in rust. That is likely to continue going forward.

I'd love a language that is a GC'd like go, but with the ML inspired type system, and still an imperative language. OCaml seems to be the closest thing to Rust in that regard, but it's not imperative.

OCaml has if/else, for loops, whiles, mutations, what are you missing?

There are also Swift, F# (Native AOT), Scala (Native, GraalVM, OpenJ9).

Nim is pretty close to that for me. It’s more pascal-ish inherited but has a sophisticated type system including case types similar to ML sum types and compile time.

That language is Swift.

Dealing with references you typically find in a compiler is not a problem for Rust. Arena allocation and indices are your friend.

Flattened asts are also faster than tree/pointer asts.

I wonder if this project can easily be integrated into Deno (built mainly in Rust)?

He also mentioned doing a line-for-line port. Assuming you could somehow manage that, you'd probably end up with something slower than JS (not entirely a joke). I'm a rust fanboy, but have to concede that Go was the be t choice here.

If it was a fresh compiler then the choice would be more difficult.

>Pity that they didn't go with AOT compiled .NET, though.

I was trying ot push .net as our possible language for somehow high performance executables. Seeing this means I'll stop trying to advocate for it. If even this team doesn't believe in it.

They cited code style and porting as reasons to use go over c#, not performance.

I didn't say it was very performance critical, go and c# are both good enough for us in this regard. The problem is that, when evaluating the whole thing, they decided against c#, that is problematic here.

But they not stated it is <because> of C#'s performance, so I don't think this is THAT problematic. But I agree that it would be fine to see them dogfeeding on their language for such a massive project, and a project that is even related to TypeScript (as it inspired it in some features), it is a shame they don't do it, but it is also the case for many of their projects (like, they are even pushing react native for apps nowadays), so I think at some level it's really fine.

> But they not stated it is <because> of C#'s performance

But I just said my point is not about performance at all! It is about the whole package. Performance of c# and go are both enough for my usecase, same for java and c obviously. They just told us that they don't think the whole package makes sense, and disowned the AOT compilation.

But you said: > I was trying ot push .net as our possible language for somehow high performance executables. Seeing this means I'll stop trying to advocate for it. If even this team doesn't believe in it.

Which made me naturally think your point was, indeed, about performance. Although as it appears to be, I'm wrong, so it's fair enough.

Also cross platform support

That makes sense if your project has similar constraints and requirements.

I like that Microsoft doesn't pretend that their technologies are the right answer for every problem.

One unrelated team at Microsoft doesn't 'believe' in .NET is enough to make you change direction?

More specifically, the guy who created C# doesn't believe in it (for this particular project).

But, of course, that is not unusual. There is no language in existence that is best suited to every project out there.

And true wisdom is realising that. I have a lot of respect for this fellow and his decisions.

You can have respect for this and his decisions and still think it is doesn't look good for c#.

I was asking myself the same questions.

ah, answers below: https://news.ycombinator.com/item?id=43333296

It's not just a pity, it's very surprising. In my eyes Go is a direct competitor of C#. Whenever you pick Go for a project, C# should have been a serious consideration. Hejlsberg designed C# and that a team that he's an authority figure in would opt to use Go, a language which frankly I would not consider to build a compiler in is astounding.

Not saying that in a judgemental way, I'm just genuinely surprised. What does this say about what Hejlsberg thinks of C# at the moment? I would assume one reason they don't pick C# is because it's deeply unpopular in the open source world. If Microsoft was so successful in making Typescript popular for open source work, why can't they do it for C#?

I have not opted to use C# for anything significant in the past decade or so. I am not 100% sure why, but there's always been something I'd rather use. Whether that's Go, Rust, Ruby or Haskell. I always enjoyed working in C#, I think it's a well designed and powerful language even if it never made the top of my list recently. I never considered that there might be something so fundamentally wrong with it that not even Hejlsberg himself would use it to build a Typescript compiler.

What's wrong with C#?

Anders Hejlsberg explains here: https://youtu.be/10qowKUW82U?t=1154. TL;DW:

- C# is bytecode-first, Go targets native code. While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it. Go also has somewhat better control over data layout. They wanted to get as low-level as possible while still having garbage collection.

- This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style. This suits Go well while a C# port would have required more restructuring.

This is shockingly out-of-date statement by Anders. I'm not sure what's going on, I guess he's just not involved with the runtime side of .NET at all to actually know where the capability sits circa 2024/2025. But really, it's a terrible situation to be in. Especially just how worse langdev UX in Go is compared to C#, F# or Rust. No one would've batted an eye if either of those was used.

Honest q, which part is out of date and why? Thanks

Pretty much everything:

> While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Only Android is missing from that list (marked as "Experimental"). We could argue about maturity but this is a bit subjective.

> Go also has somewhat better control over data layout

How? C# supports structs, ref structs (stack allocated only structures), explicit stack allocation (`stackalloc`), explicit struct field layouts through annotations, control over method local variable initialization, control over inlining, etc. Hell, C# even supports a somewhat limited version of borrow checking through the `scoped` keyword.

> This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style.

C# has been consistently moving into that direction by taking more and more inspiration from F#.

The only reasonable reason would be extensive usage of structural typing which is present in TS and Go but not in C#.

Chances are it was just personal preference of the team and decades of arguing about language design have worn out Anders Hejlsberg. I don't think structural typing alone is enough of an argument to justify the choice over Rust. Maybe the TS team thought choosing Go would have better optics. Well, they won't have it both ways because clearly this decision in my opinion is short-sighted and as someone aptly pointed on twitter they will be now beholden to Google's control over Go should they ever need compiler to support a new platform or evolve in a particular way. Something they would've gotten easily with .NET.

On the topic of preference, this thread has really shown me that there is a HUGE preference for a native-aot gc language that is _not_ Go. People want AOT because of the startup and memory characteristics, but do not want to sacrifice language ergonomics. C# could fill that gap if Microsoft would push it there.

Just use the fast GC library in C++.

I don't think C++ has good language ergonomics.

I don't think there is anything faster.

I highly doubt that bolting a GC on to C++ is going to be any faster than the equivalent C# or Java code.

Doubt is human, but it isn’t always warranted. In C++ can use a concurrent, completely pause‐free garbage collector, where the programmer decides which data is managed by the GC. This enables code optimizations in ways that aren’t possible in C# and Java.

You realize that is literally not the same thing? I said equivalent code. The whole reason of using a managed language with GC is to not think about those things because they eat up thought and development time. Of course the language that will let you hand optimize every little line will eventually be more performant. I really think you’re discounting both C#’s ability to do those things and just how good Java’s GCs are. Anyway, thats not the point.

The point is C++ sucks dude. There is no way that you can reasonably think that bolting a GC on to C++ is going to be a pleasurable experience. This whole conversation started with _language ergonomics_. I don’t care that it’ll save 0.5 milliseconds. I’d rather dig holes than write C++.

Where performance is paramount, developer convenience takes a backseat. Moreover, C++ has evolved significantly in recent years and is now quite enjoyable to use. We’re also discussing a tool in this thread whose performance is critical for developers. Over-simplifying code will ultimately lead to programmers using such solutions being replaced by AI, while the software itself will demand enormous computational power. That’s not the way forward.

We’re talking about a tool whose performance profile with a managed language is perfectly acceptable as deemed by the choice to use Go. Let alone the fact that this thread you’ve been replying in has never been about achieving the utmost performance.

You’re absolutely delusional if you think C++ is enjoyable compared to any managed language or if you think AI is capable of replacing anything.

You’ve moved this conversation extremely far off topic and I won’t be replying again.

Cheers dude. Good luck with your chat bots and CVE’s from your raw pointers.

I assume that the original performance profile of these tools was satisfactory to their creators, yet they still decided to rewrite them. I admire programmers who claim that their tools don't need to be maximally optimized. This is likely an attempt to justify the fact that their products aren't exceptionally performant either. Just take a look at the TIOBE rankings, and you'll see how many programmers hold a different view than you.

It works for Unreal.

To correct myself, someone pointed out a commit graph which indicates Anders Hejlsberg's heavy involvement with the ongoing port efforts: https://github.com/microsoft/typescript-go/graphs/contributo...

> C# supports structs,

That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory.

Go uses a C-like model. Everything is a value type. Real pointers are in the language. Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. That function can be used for all 3 types, no fuss.

> It couples the type (struct vs class) with allocation

Agree. Where things are allocated is a consumer decision.

> C# is just not ergonomic if you need to care about data layout in memory

I disagree. I work on a public high performance C# code and I don't usually face issues when dealing with memory allocations and data layout. You can perfectly use structs everywhere (value types) and pass references when needed (`ref`).

> Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area.

You can do this perfectly fine in C#, it might not be what some folks consider "idiomatic OOP" but I could not care less about them.

> Especially just how worse langdev UX in Go is compared to C#, F# or Rust.

Can you explain why the DX in Go is "worse"? I've seen the exact opposite during my professional work.

Lack of optionals/enum/sum types is a huge regression from Typescript to go IMHO.

the typing situation in Go is a mess, GADTs are generally a joy to work with, nullability is not.

Isn't the AOT story for F# pretty meh? AOT + System.Text.Json requires source generation as best I can tell, which F# doesn't support yet (to my knowledge).

In a complex projects like this, Go requires manual scripting and build-time code generation. Arguably, writing a small shim project in C# is much easier. You don't exactly do a lot of JSON serialization in a compiler either way. Other than that - F# "just works" and does not require anything extra. It is just IL after all.

The most important part here is that TypeScript at Microsoft is a "first-party" customer. This means if they need additional compiler accommodations to improve their project experience from .NET, they could just raise it and they will be treated with priority. This decision is technically and politically unsound at multiple levels at once. For example, they will need good WASM support. .NET's existing WASM support is considered "decent" and even that one is far from stellar, yet considered way ahead the Go one. All they needed is to allocate additional funding for the ongoing already working NativeAOT-LLVM-WASM prototype to very quickly get the full support of the target they needed. But alas.

I already hinted on BlueSky that they shouldn't wonder why .NET has adoption problems outside the traditional Windows ecosystem, when decisions like these are taken.

The nightmare of Midori never ends. And especially right as the platform, from the technical standpoint, is getting really good(tm).

It seems it's because AOT is a bit of a second fiddle in the dotnet ecosystem and native is a top priority for their case. After hearing the reasoning ( https://youtu.be/ZlGza4oIleY?si=1GKSX61AF20VQr-G&t=1000 ) I don't blame them for choosing Go.

C# needs an interpreter (.NET runtime) while Go compiles down to a binary. And the toolchain allows you to compile for other architectures fairly easily.

So that could be a fundamental reason why.

The grand parent was talking about AOT.

.NET has AOT compilation now. There really is no excuse, especially when you consider that C# has a pretty decent type system and Go has an ad-hoc, informally specified, bug-ridden, slow implementation of half of a decent type system.

> Go has an ad-hoc, informally specified, bug-ridden, slow implementation of half of a decent type system.

It's not lost on me that this is a widely used aphorism. The problem is that it's not true in any way shape or form.

It absolutely is... Go's type system is an abomination.

Let's not assume C#'s type system is THAT much better, it is also a mess in dozens of cases and is hardly pleasant from a DX standpoint.

People using pointers when they want to hack in null values points towards a problem in Go's type system.

C# has become a poor jack of all trades, trying to be Java, Go and F# at the same time and actually being a shity poor version of all of them. On top of that .NET has become a very enterprisey bloatware. In all honesty, I'm not surprised that they went with Go, as it has a clear identity, a clear use-case which it caters for extremely well and doesn't lose focus with trying to be too many other unrelated things at the same time.

Maybe it's time to stop eating everything that Microsoft sales folks/evangelists spoon feed you and wake up to the fact that only because people paid by Microsoft to roll the drum about Microsoft products telling you that .NET and C# is oh so good and the best in everything, maybe it's not actually that credible?

Look at the hard facts. Every single product which Microsoft has built that actually matters (e.g. all their Azure CNCF stuff, Dapr, now this) is using non Microsoft languages and technologies.

You won't see Blazor being used by Microsoft or the 73rd reinvention of ASP.NET Core MVC Minimal APIs Razor Pages Hocus Pocus WCF XAML Enterprise (TM) for anything mission critical.

If not for Microsoft's backing, C# would have died a long time ago. It's just another D, but with a lot more money behind it. It had its chance/momentum, but it failed, and its time has passed. Resurrecting the language now would be very difficult.

There are some external projects that have tried to port tsc to native. stc[0], for instance, was one. Iirc it started out in Go since it had a more comparable type system (they both use duck typing) making it easier to do one-to-one conversions of code from one language to the other. I’m not totally sure why it ended up pivoting to rust.

[0]: https://github.com/dudykr/stc

Hejlsberg discusses the decision not to use C# here: https://www.youtube.com/watch?v=10qowKUW82U&t=1154s

> I love that they picked Go instead of the fashion to go Rust

This seems super petty to me. Like, if at the end of the day you get a binary that works on your OS and doesn’t require a runtime, why should you “love” that they picked one language over another? It’s exactly the same outcome for you as a user.

I mean, if you wanted to contribute to the project and you knew go better than rust, that would make sense. But sounds like you just don’t like rust because of… reasons, and you’re just glad to see rust “fail” for their use case.

> that seems to be the norm now.

According to whom?