4 ms·

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 majo

• ramon156 2y ago
  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"
  • dagw 2y ago
    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.
    • pier25 2y ago
      > 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.
      • xandrius 2y ago
        I never heard C# being fasted than Go, except on certain batched jobs and even there Go can be better.
        • pier25 2y ago
          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.
          • tacticus 2y ago
            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 https://dusted.codes/how-fast-is-really-aspnet-core
            • neonsunset 2y ago
              This is sorely outdated. Although for anyone with an axe to grind dustin’s articles are convenient enough.
              • yahoozoo 2y ago
                [dead]
            • pier25 2y ago
              The HTML benchmarks I did myself with Razor pages. The link your provided is severely outdated using data from Round 21 and .NET 6.
    • fabian2k 2y ago
      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.
      • dagw 2y ago
        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.
  • osigurdson 2y ago
    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.
    • neonsunset 2y ago
      A “step out” is a single flag passed to “dotnet publish” or set in the project manifest.
      • osigurdson 2y ago
        That, and then deal with all the gotchas.
        • neonsunset 2y ago
          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".
          • osigurdson 2y ago
            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.
  • Cthulhu_ 2y ago
    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.
    • neonsunset 2y ago
      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.
      • commandersaki 2y ago
        Communicating Sequential Processes (CSP) makes it a lot easier to reason about concurrency. It may be old (1978) but is foundational.
      • desumeku 2y ago
        "Go is not meant to innovate programming theory. It’s meant to innovate programming practice.”