8 ms·

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 consid

by tinco 2y ago

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#?

dimgl 2y ago
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.
- rat9988 2y ago
  The grand parent was talking about AOT.
  - deleted 2y ago
    [deleted]
- bitwize 2y ago
  .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.
  - dimgl 2y ago
    > 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.
    - mervz 2y ago
      It absolutely is... Go's type system is an abomination.
      - nipah 2y ago
        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.
    - madeofpalk 2y ago
      People using pointers when they want to hack in null values points towards a problem in Go's type system.
duckerude 2y ago
Anders Hejlsberg explains here: https://youtu.be/10qowKUW82U?t=1154 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.
- neonsunset 2y ago
  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.
  - dimgl 2y ago
    > 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.
    - madeofpalk 2y ago
      Lack of optionals/enum/sum types is a huge regression from Typescript to go IMHO.
    - whimsicalism 2y ago
      the typing situation in Go is a mess, GADTs are generally a joy to work with, nullability is not.
  - whatthemick 2y ago
    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).
Guillaume86 2y ago
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 https://youtu.be/ZlGza4oIleY?si=1GKSX61AF20VQr-G&t=1000 ) I don't blame them for choosing Go.
dustedcodes 2y ago
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.
- lossolo 2y ago
  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.

by tinco 2y ago

dimgl 2y ago

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.

rat9988 2y ago
The grand parent was talking about AOT.
- deleted 2y ago
  [deleted]
bitwize 2y ago
.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.
- dimgl 2y ago
  > 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.
  - mervz 2y ago
    It absolutely is... Go's type system is an abomination.
    - nipah 2y ago
      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.
  - madeofpalk 2y ago
    People using pointers when they want to hack in null values points towards a problem in Go's type system.

duckerude 2y ago

Anders Hejlsberg explains here: https://youtu.be/10qowKUW82U?t=1154 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.

neonsunset 2y ago
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.
- dimgl 2y ago
  > 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.
  - madeofpalk 2y ago
    Lack of optionals/enum/sum types is a huge regression from Typescript to go IMHO.
  - whimsicalism 2y ago
    the typing situation in Go is a mess, GADTs are generally a joy to work with, nullability is not.
- whatthemick 2y ago
  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).

Guillaume86 2y ago

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 https://youtu.be/ZlGza4oIleY?si=1GKSX61AF20VQr-G&t=1000 ) I don't blame them for choosing Go.

dustedcodes 2y ago

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.

lossolo 2y ago
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.