Hacker News Reader

Hacker News

Comment by pier25 | Hacker News Reader

Parent Full thread

pier25

Anders explain why Go in this podcast:

https://youtu.be/ZlGza4oIleY?t=1005

View on HN

There’s also an FAQ discussion about the language choice: https://github.com/microsoft/typescript-go/discussions/411

TL:DR;

- Native executable support on all major platforms

- He doesn't seen to believe that AOT compiled C# can give the best possible performance on all major platforms

- Good control of the layout of data structures

- Had to have garbage collection

- Great concurrency support

- Simple, easy to approach, and great tooling

So wild that most of these points were something C# was supposed to be good at, and they all boil down to "its just not as good in C# as in Go"

Yea, sounds like cross platform AOT compiled C# not being mature and performant was a big reason that C# was rejected.

One other thing I forgot to mention was that he talked about how the current compiler was mostly written as more or less pure functions operating on data structures, as opposed to being object oriented, and that this fits very well with the Go way of doing things, making 1:1 port much easier.

> sounds like cross platform AOT compiled C# not being mature and performant was a big reason

I don't think it was the performance. C# is usually on par or faster than Go.

Could be the lack of maturity but also that I believe Go produces smaller binaries which makes a lot of sense for a CLI.

I never heard C# being fasted than Go, except on certain batched jobs and even there Go can be better.

For example, look at the Techempower benchmarks.

I benchmarked HTML rendering and Dotnet was 2-3x faster than Go using either Templ or html/template.

Etc.

The c# benchmarks where they didn't use the framework to do any of the actual templating?

those hardcoded byte arrays are how everyone does templating everywhere right?

or are you talking about after they changed back their "platform" test to not do that and is substantially slower than go

https://dusted.codes/how-fast-is-really-aspnet-core

This is sorely outdated. Although for anyone with an axe to grind dustin’s articles are convenient enough.

The HTML benchmarks I did myself with Razor pages.

The link your provided is severely outdated using data from Round 21 and .NET 6.

Immaturity of native AOT sounds like a likely culprit here. If they're after very fast startup times running classic C# is out. And native AOT is still pretty new.

You can write pure functions operating on data structures in C#, it's maybe not as idiomatic as in Go, but it should not cause problems.

it's maybe not as idiomatic as in Go, but it should not cause problems.

Based on interviews, it seems Hejlsberg cares a lot about keeping the code base as idiomatic and approachable as possible. So it's clearly a factor.

I don't really get the OOP arguments from Anders. You don't need to do OOP stuff in C# - just write a bunch of static functions if you want. However, I totally get the AOT aspect. Creating a simple cli app meant for wide distribution in .NET isn't great because you either have to ship the runtime or try to use AOT which is very much a step out. I have come to the same conclusion and used Go on some occasions for the same reason despite not knowing it very well.

If doing a web server, on the other hand, these things wouldn't matter at all as you would be running a container anyway.

A “step out” is a single flag passed to “dotnet publish” or set in the project manifest.

That, and then deal with all the gotchas.

There are none in new projects. There are few in existing ones. I guess it is difficult to have a conversation with someone who is committed to looking for the aforementioned "gotchas".

I generally agree that C# == Java == Go in most aspects and have far more and generally think C# is nicer to use and probably faster for many use cases. But, it is not the same as Go at all in terms of AOT. In golang that is just the default and always works - basically on all platforms, in C#, that is not the case. Do you really want to find out that a popular library uses some reflection and therefore doesn't work half way through the project?

In my opinion, using C# for this use case isn't a practical choice on a greenfield project.

You may want to read the documentation first before responding.

Where in the documentation does it state that everything just works (as it would in go)? I see a list of incompatibilities / limitations etc., that not only apply to your own code but any 3rd party library.

Read on the trimming warnings (i.e. there are none? it means everything just works) and try out a couple projects :)

Very specific areas require reflection which is not analyzable with the main user being serialization and serialization just happens to be completely solved.

The OP is a troll. He just claims everyone else is out to get him and .NET if they point out some inconvenient non-ideal on display in the ecosystem.

Every tooling has its faults.

I'm happy to see it to be honest; at this point C# is 25 years old, and since then there's been a lot of innovation and development in programming languages and ecosystems (as well as 10x more software developers, at least - I am guessing at this number). Current-day programming languages, including Go and Typescript, will have had a lot of learnings from C#, including in things like generics and the like.

Go is a step back in key areas: generics, nullability, functional constructs, concurrency. The praise of the latter in particular is egregious. Surely we can do better than having to wire the transfer of data and forking/joining the logical flows manually in 2025? The concept of virtual threading in Go, despite having nice implementation, did not progress much from what we’ve had 10 or even 20 years ago either. It can be more convenient than async/await with hot-started tasks/futures if you predominantly are dealing with sequential code. But for highly concurrent logic working with goroutines is more ceremonious.

Communicating Sequential Processes (CSP) makes it a lot easier to reason about concurrency. It may be old (1978) but is foundational.

"Go is not meant to innovate programming theory. It’s meant to innovate programming practice.”

Reply on news.ycombinator.com