[electroly]

This is a great response but this is "why is Go better than JavaScript?" whereas my question is "why is Go better than C#, given that C# was famously created by the guy writing the blog post and Go is a language from a competitor?"

C# and TypeScript are Hejlsberg's children; C# is such an obvious pick that there must have been a monster problem with it that they didn't think could ever be fixed.

C# has all that stuff that the FAQ mentions about Go while also having an obvious political benefit. I'd hope the creator of said language who also made the decision not to use it would have an interesting opinion on the topic! I really hope we find out the real story.

As a C# developer I don't want to be offended but, like, I thought we were friends? What did we do wrong???

[fixprix]

Anders answers that question here - https://www.youtube.com/watch?v=10qowKUW82U&t=1154s

Transcript: "But I will say that I think Go definitely is much more low-level. I'd say it's the lowest level language we can get to and still have automatic garbage collection. It's the most native-first language we can get to and still have automatic GC. In contrast, C# is sort of bytecode-first, if you will. There are some ahead-of-time compilation options available, but they're not on all platforms and don't really have a decade or more of hardening. They weren't engineered that way to begin with. I think Go also has a little more expressiveness when it comes to data structure layout, inline structs, and so forth."

[electroly]

This is a great link, thank you!

For anyone who can't watch the video, he mentions a few things (summarizing briefly just the linked time code, it's worth a watch):

- Go being the lowest level language that still has garbage collection

- Inline structs and other data structure expressiveness features

- Existing JS code is in a C-like function+data structure style and not an OOP style, this is easier to translate directly to Go while C# would require OOPifying it.

[WuxiFingerHold]

Thanks for the link. I'm not fully convinced by Anders answer. C# has records, first class functions, structs, span. Much control and I'd say more than Go. I'd even say C# is much closer to TS than Go is. You can use records for the data structures. The only little annoyance is that you need to write the functions as static methods. So an argument for easy translation would lead to C#. Also, C# has advantages over Go, e.g. null safety.

Sure, AOT is not as mature in C# but is this reason enough to be a show stopper? It seems there're other reasons Anders don't want to address publicly. Maybe as simple reasons as "Go is 10 times easier to pick up than C#" and "language features don't matter when the project matters". Those would indeed hurt the image of C# and Anders obviously don't want that.

But I don't see it as big drama.

[mexicocitinluez]

I dont think there are other reasons.

The side-by-sides that show how Go code is closer to the current TS code (visually) than C# would be are pretty compelling. He made it pretty clear they're "porting" not rewriting.

[WuxiFingerHold]

After reading the long Github thread, I think you're right. It's probably just as simple as "what is the easiest way to copy our TS code 1:1 to a faster language". And this case Go wins due to its simplicity.

[mexicocitinluez]

What's funny is that while I understood a chunk about why that made that decision, a ton of things they were talking about went over my head. But then we they showed the side-by-side, I was like "Well that makes sense".

[saturn_vk]

> You can use records for the data structures. The only little annoyance is that you need to write the functions as static methods. So an argument for easy translation would lead to C#. Also, C# has advantages over Go, e.g. null safety.

Wouldn't these things be useful if you are making an actual compiler, that would run TS? Since in this case, the runtime is JS, I don't think any of these things would get any usage, unless they are used in the existing transpiler.

[vips7L]

An unpopular pick that is probably more low level than Go but also still has a GC: D. Understandable why you wouldn't pick D though. Its ecosystem is extremely small.

[999900000999]

I think you D fans need to dogfood a startup based around it.

It's a fascinating language, but it lacks a flagship product.

I feel the same way about Haxe. Someone created an amazing language, but it lacks a big enough community.

Realistically languages need 2 things for adoption. Momentum and ease of use. Rust has more momentum than ease, but arguably can solve problems higher level languages can't.

I'm half imagining a hackathon like format where teams are challenged to use niche languages. The foundations behind these languages can fund prizes.

[vips7L]

Did my post come off as a fan? I directly criticized its ecosystem. It wouldn't be my first pick either. I was just making conversation that there are other options.

And AFAIK Symmetry Investments is that dogfood startup.

[polskibus]

A missed opportunity to improve c# by dogfooding it with TS compiler rewrite.

[geodel]

They are trying to finish their current project and not redo all the projects which their current project may depend upon.

[cxr]

"Finish"?

[mohsen1]

C# is too old to change that drastically, just like me

[Rapzid]

Sounds like C# was too late with dictionary collection expressions.

[jodrellblank]

> "given that C# was famously created by the guy writing the blog post"

What is this logic? "You worked on C# years ago so you must use C# for everything"?

"You must dictate C# to every team you lead forever, no matter what skills they have"?

"You must uphold a dogma that C# is the best language for everything, because you touched it last"?

Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those? Because there is no logic; the person who created hammers doesn't have to use hammers to solve every problem.

[uticus]

Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course).

So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages.

If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?

[_bin_]

funny you bring up this analogy. tons of auto manufacturers these days will license other mfgs' engines and use them in your cars. e.g. a fair number of Ford's cars have had Mazda engines and a fair number of Mazdas have had Ford engines.

[nindalf]

Could you give some examples of both? Also, why did they choose to do this?

[_bin_]

Sure. Mazda’s CX-3/5/9 in the aughts and early teens often had licensed Ford engines. The current Ford Tourneo Connect has a wholly VW-manufactured engine.

It’s probably most common when an automaker introduces a new make and wants to save time and capital on developing and getting into production a new engine.

[sellmesoap]

The last model of ford ranger and Mazda B series light pickup trucks were mostly the same except for the badges.

The Toyota matrix and Pontiac vibe used a lot of the same parts shared an engine and drivetrains if I'm not mistaken.

[kcrwfrd_]

Toyota 86 and Subaru BRZ are basically the same car. The car was designed by Toyota while Subaru supplied the engine. Just one example.

[sellmesoap]

I think Toyota also owns a significant amount of Subaru, probably other mfgs. as well, Toyota is the 600lb gorilla of the car industry.

[jodrellblank]

> "So it's not just that the lead architect of C# is involved in the TypeScript changes."

Anders Hejlsberg hasn't been the lead architect of C# for like 13 years. Mads Torgersen is:

https://dotnetcore.show/episode-104-c-sharp-with-mads-torger... - "I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And then when he and I had a little side project with others to do TypeScript, he stayed over there. And I got to take over as lead designer C#. So for the last, I don’t know, nearly a decade, that’s been my job at Microsoft to, to take care of the evolution of the C# programming language"

Years later, "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird; he's a person with a job, not a religious cult leader.

> "If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?"

Like these? https://www.slashgear.com/1642034/fords-powered-by-non-ford-...

[cxr]

> "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird

It's also not what anyone said.

> It's best not to use quotation marks to make it look like you're quoting someone when you're not. <https://news.ycombinator.com/item?id=21643562>

[jodrellblank]

Why is that "best" ?

> "An indirect quote lets you capture or summarize what someone said or wrote without using their exact words. It helps to convey the tone or meaning of your source without quoting them directly." - https://www.grammarly.com/blog/punctuation-capitalization/qu...

I'm distilling and exaggerating multiple the comments to convey the tone and meaning of the bit I want to focus on. Asking "why not C#?" has the implicit framing "it should be C# by default and you have to justify why not" and calling out that bias to show it to be unreasonable is the intent.

[uticus]

> Like these...

Nope. None of those are even close to Ford + Chevy. (Ford + Mazda is well known of course).

I chose the analogy carefully.

[jodrellblank]

The analogy missed because I am not American or a car enthusiast.

[andy81]

F# isn't in the running for third either.

Maybe top ten behind MSSQL, Powershell, Excel Formulae, DAX etc.

[sterlind]

hey, there are dozens of us F# users! dozens!

I do love F#, but its compiler is a rusty set of monkey bars. It's somehow single pass, meaning the type checker will struggle if you don't reorder certain expressions - but also dog slow, especially for `inline` definitions (which work more like templates or hygienic macros than .net generics, and are far more powerful.) File order matters, bafflingly! Newer .net features like spans and ref structs are missing with no clear path to implementation. Doing moderately clever things can cause the compiler to throw weird, opaque, internal errors. F# is built around immutability but there's no integration with the modern .net immutable collections.

It's clearly languishing and being kept alive by a skeleton crew, which is sad, because it deserves better, but I've used research prototypes less clunky than what ought to be a flagship.

[throw234234234]

There's more than a dozen - I should know. I've seen quite a few large systems built in it. Most of the time however it isn't well advertised (finance, insurance, etc).

- I don't think the compiler is actually that bad, and yes - inline definitions I think once you are going on the "templating route" are going to be slower. Spans and ref structs are there - I think the design of them is more intuitive actually - the C# "ref struct" at first glance sounds like an oxymoron to me.

- modern .net immutable collections - in testing these are significantly slower than some of the F# options especially when you go away from the standard lib and use some of the other collection libraries. The algorithms within the C# immutable libs were not as optimal for some common collection types. They didn't feel modern last time I used them and I was forced to switch to the F# ones and/or others in the F# ecosystem to get the performance I needed. Immutable code felt MUCH more idiomatic with F#.

- "Doing moderately clever things can cause the compiler to throw weird, opaque, internal errors" - happened with init fields for me; can't recall another time.

Don't mind the file order bit - I thought OCAml and a few other languages also do this. Apps still scale OK, and when I was coding in it got me out of a few spaghetti code issues as the code scaled up to about the 500,000+ LOC mark.

However I do agree with you on it being kept alive by skeleton crew - I think the creators and tooling staff have moved on to the next big thing (AI and specifically Github Copilot). Which the way things are moving will raise some interesting questions about all coding languages in general potentially.

[debugnik]

> Newer .net features like spans and ref structs are missing with no clear path to implementation

Huh? They're already implemented! It took years and they've still got some rough edges, yes, but they've been implemented for a few years now.

Agreed with the rest, though. As much as I love working with F#, I've jumped ship.

[jay_kyburz]

It's a bad look for both C# and TypeScript. Anybody starting a new code base now would be looking for ways to avoid both and jump right to Go.

[sethaurus]

I'm struggling to understand how this is a bad look for Typescript. Do you mean that the specific choice of Go reflects poorly on Typescript, or just the decision to rewrite the compiler in a different non-TS language?

If it's the latter, I think the pitch of TS remains the same — it's a better way of writing JS, not the best language for all contexts.

[jay_kyburz]

I think a lot of folks downplay the performance costs for the convenience of a shared code-base between the front and backend.

If the TS team is getting a 10x improvement moving from TS to Go, you might imagine you could save about 10x on your server cpu. Or that your backend would be 10x more responsive.

If you have dedicated team for front and back anyhow, is a 10x slow down really worth a shared codebase?

[bdangubic]

if I had to use Go I’d change my career and go do some gardening :)

[bbkane]

I actually really enjoy Go. Sure it has a type system I wish was more powerful with lots of weird corners ( https://100go.co/ ), but it also has REALLY GOOD tooling- lots of nice libraries, the compiler is fast, the editor tooling is rock solid, it's easy to add linters to warn you about many issues (golangci-lint), and releasing binaries and updating package repositories is super nice (Goreleaser).

[ricardobeat]

I'd probably have said the same 5 years ago, it's surprising how easy you change sides once you actually use it in a team.

[bdangubic]

I was mostly joking… some of the most amazing shit code-wise I have seen in “non-mainstream” languages (fortran leads the way here)

[keyle]

I had to, and I do think a lot about gardening these days...

[zeroc8]

I like Anders'answer there. "But you can achieve pretty great things with it".

[saturn_vk]

Because it's so easy that you'd have a lot more time for gardening?

[moogly]

If they're writing (actually porting) a _compiler_, perhaps.

[osigurdson]

Go doesn't run in the browser however (except WASM but that is different).

[Hello71]

> Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those?

as you know full well, Delphi and Turbo Pascal don't have strong library ecosystems, don't have good support for non-Windows platforms, and don't have a large developer base to hire from, among other reasons. if Hejlsberg was asked why Delphi or Turbo Pascal weren't used, he might give one or more of those reasons. the question is why he didn't use C#, for which those reasons don't apply.

[whattidywhat]

I'm not saying this to start a language war but. Look at the cognitive complexity and tooling complexity involved in a c# project. Seriously, every speed bump you hit in your ide think about how many pieces of knowledge you assemble to solve it. Similarly think about the overhead in designing both the software and tests. Think about cross platform builds and the tooling required to stand up ops infrastructure. Measure the compilation time. Think about the impedance mismatch between ts and c#.

Compare that to go. It's not even close. I see comments bickering about the size of executable files... Almost no major product cares about that within order of magnitude.

Go is a wild choice to write a compiler in. Literally in my top 10 things I never want to do. Everything else about it drove them to do it.

[cryptonector]

GP's answer is a great answer to why Go instead of Rust, which u/no_wizard asked about. And the answer to that boils down to the need to traverse data structures in ways which Rust makes difficult, and the simplicity of a GC.

[almosthere]

.NET executables requires a runtime environment to be installed.

Go executables do not.

TSC is installed in too many places for that burden to be placed all of a sudden. It is the same reason why Java has had a complicated acceptance history too. It's fine in the places that it is pre-installed, but no where else.

Node/React/Typescript developers do not want to install .net all of a sudden. If you react that poorly, pretend they decided they decided to write it in Java and ask if you think Node/React/Typescript developers WANT to install Java.

[afavour]

FYI this hasn’t been the case with C# for a very long time now.

[vips7L]

.NET has been able to build a self contained single file executable for both the JIT and AOT target for a quite some time. Java also does not require the user to install a runtime. JLink and JPackage have both been around for a long time.

[mytec]

Yes, but they may not always work. While generally true there are still some edge cases.

SQL Server connections are one example where I do get .exe with the .pdb in the publish directory but the .exe won't run correctly without the "Microsoft.Data.SqlClient.SNI.dll" file.

Another example are any libraries that have "RequiresDynamicCodeAttribute" requirements.

[yakz]

Maybe some other runtimes do this or it has been changed, but in the past self-contained singe-file .NET deployment just meant that it rolled all the files up during publishing and when you run it, it extracted them to a folder. Not really like a single statically linked executable.

[webprofusion]

You can indeed produce a compiled native executable with minimal bloat: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

[vips7L]

It hasn't done that in years.

[estebarb]

C# AOT filesizes are huge compared to Go.

[MStrehovsky]

Do you have data backing that up? Per https://github.com/MichalStrehovsky/sizegame:

C#: 945 kB Go: 2174 kB

Both are EXEs you just copy to the machine, no separate runtime needed, talks directly to the OS.

[estebarb]

Sadly yes, we have data. We are migrating our C# SDK to Rust in part because customers want a much smaller dependency. And the AoT compiler didn't trimmed as much as we wanted.

[neonsunset]

(regarding size - there are tools like sizoscope to understand what is taking space, sometimes it’s something silly like rooting a lot of metadata with reflection referencing many assemblies or because of abusing generic virtual members with struct parameters in serialization, obviously if you can use Rust without productivity loss it’s fine, but usually problems like that take an hour or two to solve, or less)

But in either case binary sizes are smaller and more scalable than what Go produces. The assumption that Go is good at compact binaries just does not replicate in reality. Obviously it’s nice to be able not touch it at all and opting into Rust for distributing native SDKs. Go is completely unfit for this as it has even more invasive VM interaction when you use it as dynamically linked library. NativeAOT is “just ok” at this and Go is “way more underwhelming than you think”.

[vessenes]

It’s a political anti-benefit in most of the open-source world. And C# is not considered a high quality runtime once you leave Windows.

[electroly]

This is Anders Hejlsberg, the creator of C#, working on a politically important project at Microsoft. That's what I mean by political benefit. The larger open source world doesn't matter for this decision which is why this is a simple announcement of an internal Microsoft decision rather than an invitation for comments ahead of time.

[vessenes]

I’m sure Microsoft’s strategy department would disagree with you. As a c# devotee - I get that you’re upset. And you may want to update your priors on where c# sits in Microsoft’s current world. But I think it’s a mistake to imagine this isn’t a well reasoned decision.

[electroly]

They can disagree if they want but as a career-long Microsoft developer they can't fool me that easily. I'm not even complaining, I'm just stating a fact that high-level steering decisions like this are made in Teams meetings between Microsoft employees, not in open discussion with the community. It's the same in .NET, which is a very open source project whose highest-level decisions are, nonetheless, made in Teams meetings between Microsoft employees and then announced to the public. I'm fine with this but let's not kid ourselves about it.

That said, I must have misstated my opinion if it seems like I didn't think they have a good reason. This is Anders Hejlsberg. The guy is a genius; he definitely has a good reason. They just didn't say what it is in this blog post (but did elsewhere in a podcast video linked in the HN thread).

[IshKebab]

> The larger open source world doesn't matter for this decision

It obviously does because the larger open source world are huge users of Typescript. This isn't some business-only Excel / PowerBI type product.

To put it another way, I think a lot of people would get quite pissed if tsc was going to be rewritten in C# because of the obvious headaches that's going to cause to users. Go is pretty much the perfect option from a user's point of view - it generates self-contained statically linked binaries.

[dlahoda]

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

[thayne]

It would have a substantial risk for the typescript project. Many people would see it as an unwanted and hostile push of a Microsoft technology on the typescript community.

And there would be logistical problems. With go, you just need to distribute the executable, but with c#, you also need a .net runtime, and on any platform that isn't Windows that almost certainly isn't already installed. And even if it is, you have to worry if the runtime is sufficiently up to date.

If they used c# there is a chance the community might fork typescript, or switch to something else, and that might not be a gamble MS would want to take just to get more exposure for c#.

[dlahoda]

csharp single file for a while https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

[smooth_criminal]

Okay, not to be petty here but, it's important to note that on his GitHub he did not star the dotnet repository but has starred multiple go repos and multiple other c++ and TS repos

[fabian2k]

Modern C# (.NET Core and newer) works perfectly fine on Linux.

[naasking]

> And C# is not considered a high quality runtime once you leave Windows.

By who?

[cyral]

Usually by someone who hasn't used C# since 2015 (when this opinion was fairly valid)

[WD-42]

It’s always the same response, c# was crappy but it’s not crappy anymore. Well guess what, Go has been not crappy for a lot longer than C# has been not crappy, maybe that’s part of the reason people like it more.

[naasking]

> Well guess what, Go has been not crappy for a lot longer than C# has been not crappy, maybe that’s part of the reason people like it more.

Nobody said anything about who likes what more, nor does that even matter in the context of the original claim that .NET doesn't have a good runtime outside of Windows.