6 ms·

Big difference is that Go is stable and conservative, net core keep adding a billion features every release. Looking at some net core 2/3 stuff and now to see h

by Thaxll 3y ago

Big difference is that Go is stable and conservative, net core keep adding a billion features every release. Looking at some net core 2/3 stuff and now to see how many things changed. Good luck with your code base in 5 years when someone decide to add all the new stuff.

deleted 3y ago
[deleted]
chrisandchris 3y ago
I don't know Go that much, but the part about .Net is so untrue. First, C# was published in 2001, while Go was released in 2009. So there's 8 years of "more stuff". Also (see in comments too), upgrading .Net is very easy. There are man not-to-small codebases can be "easily" upgraded from .Net Core 3 to 8 without any hassle. Backwards comptability was always baked into Microsofts thinking. .Net 7 and 8 did also (IMHO) not contain that many groundbreaking features, just some "smaller" stuff.
- Thaxll 3y ago
  Do you want to compare the number of features added between go and c# in the last 15 years? Just a single major release of C# added more stuff than probably the last 15 years of Go. I'm not saying Go is 100% right in that, but it's much more conservative about stuff added into the language.
  - HackerThemAll 3y ago
    Of course, they conservatively added the most idiotic way of formatting dates as strings (while knowing other methods exist). And, while the whole bunch of other languages would call a method string.startsWith("a"), they use hasPrefix. This language is a mix of half-baked concepts and utter trolling. If I have to learn a lang with an awkward syntax, I'd prefer Rust, Julia, Erlang, Elixir or Haskell. Go is no-go. It's not even widely used at Google, its creator. So no, thanks.
    - WorldMaker 3y ago
      Also, why would force error returns without also including some sort of nice Monadic do-notation or Monad-inspired combinator syntax sugar in the 2020s? We've known for decades now how do that better. I also think that Go looks like a practical joke that escaped some INTERCAL-like satire committee in the 1970s.
      - hollerith 3y ago
        You probably mean sum types and convenient syntax for testing and de-structuring sum types.
        WorldMaker 3y ago
        No I specifically meant what is often called the Either or Result Monad. These are often implemented as Sum types, but they also follow the Monad laws and supports things like monadic binding/transformation/combination and benefit from syntax sugar like Haskell's "do-notation"/OCaML family's "computation expressions"/the "async/await" pattern of so many other languages now. Good sum types destructuring would probably also be useful in more languages like Go, but many languages today provide "async/await" pattern syntax benefits without anything at all like "proper" sum types. Sum types are "merely" a possible implementation detail of the Monad and it's the Monad laws that empower some things beyond just sum types.
        hollerith 3y ago
        Why pick on Golang, then? Rust doesn't have a monadic interface to side effects and "errors" either. Nor do the vast majority of the other newer languages.
        WorldMaker 3y ago
        Rust uses a sum type for most errors (Result<T, Error>) and there are common macros such as "error-chain" that apply a monadic approach to binding/combining them (or chaining them, as the preferred nomenclature in that case). Exception-based languages don't look monadic at first blush, they definitely aren't Sum types, but try/catch is one of the earliest and oldest of the monadic binding/combining approaches, even if it isn't often thought as such (and is barely considered more than goto/switch). It's far more obvious when you start to realize the intersection of async/await and try/catch is a working monad (and how that is reflected in Task/Promise monad instances). Golang is the obvious odd one out where every other line of "best practice" code is `if err != nil` and the only other advice is "well you could just ignore errors". try/catch doesn't ignore errors, it just looks like it. Rust error chaining doesn't ignore errors, it just looks like it. Golang gives you the choice between micro-managing errors or BASIC-style "ON ERROR RESUME NEXT" and I cannot get anyone to convince me why this isn't either a practical joke or an intentional throwback to writing code like it is the 1970s all over again (even VB6 had better options than "ON ERROR RESUME NEXT", even if they maybe weren't used as often as they should be in some legacy 1990s/2000s codebases).
- jen20 3y ago
  The real problem was upgrading from .NET Framework, or Mono, to .NET Core, which has been stable since. That comparison is not a fair comparison to Go, which has a much stricter guarantee around source and library compatibility within the 1.x series.
Capricorn2481 3y ago
People can write dumb, inconsistent code anywhere. A stable library will not protect you from a lack of PR reviews
pjmlp 3y ago
Thankfully .NET folks are confident that their audience has the skills to manage those features.
The_Colonel 3y ago
.NET / C# seems to be following C++ by including... everything. I wonder if they're just not worried about feature bloat or what's their thinking...
- Metasyntactic 3y ago
  Hi there, C# Lang Designer here. :) We're always thinking about the bloat concern when it comes to language development. However, our philosophy on it is that bloat primarily comes when you add replacement systems that are expected to supersede the previous mechanisms, not compliment them. So we try to do the former sparingly. In the history of C# there are very few times we've actually done this, and we do view those times as unfortunate cases where we likely rushed a feature too early and then regret having to live with those features forever. To help combat this, we tend to go through long periods of design and experimentation, where we propose features, create prototypes of them, and then interact with a large set of diverse community groups to try things out. The feedback from this is tightly bound into our design process and allows us to refine (or even jettison) designs rapidly. We also normally will both break up work into lots of smaller pieces (composing large language changes into small orthogonal, complimentary, composable blocks), and do designs over many years if appropriate. We think this approach has helped us create a language that is 25 years old, while being both very rich, and still very cohesive. There are a few mistakes we've made along the way ("anonymous-delegates", i'm looking at you), but we're very happy that our ratios here are very good given our continued investment in this space.
  - terandle 3y ago
    The new array literals seem to supersede some previous syntaxes like new[] { 1, 2, 3 } goes to [1, 2, 3] in a lot of cases. But overall they are a _great_ addition to the language playing around with them now so bravo. Still not really sure how I feel about class primary constructors on the other hand, will give them some time to marinate.
    - oaiey 3y ago
      Share the exactly same worries. Let us see.
Kwpolska 3y ago
.NET is stable, they very rarely remove things. Code written for .NET Framework 2.x will probably work fine on .NET 8 (unless it uses the things that didn't make the jump, like WCF, but there are libraries that provide SOAP support.) Can a single developer remember all of .NET? No, but that applies to most languages/ecosystems. But if you encounter something you've never seen, you can always check the docs. And the thing hasn't been named ".NET Core" for 4 consecutive releases now.
- merb 3y ago
  Actually most wcf code does run on .net 7+ they open sourced it into corewcf. (At least a lot of the things) Webforms however is dead.
- starik36 3y ago
  > Code written for .NET Framework 2.x will probably work fine on .NET 8 WebForms would like a word.
  - Kwpolska 3y ago
    Hence “probably”. WebForms should die in a dumpster fire.
    - WorldMaker 3y ago
      I worry that Blazor is that dumpster fire sometimes.
      - custard42 3y ago
        I'm curious, why do you say that?
        WorldMaker 3y ago
        The mixture of client-side and server-side code that Blazor can allow in the same files gives me a very gut instinct feeling that "those who have forgotten the WebForms history, or worse the ASP Classic history, are doomed to repeat it". It's obviously different from both WebForms and ASP Classic and its use of Wasm is certainly a brand new idea that WebForms only wishes it had access to. It seems like a brand new mistake to me, because I still remember debugging ASP Classic and WebForms and Silverlight and "now even the client side JS of ~~WebForms~~ Blazor is no longer JS but a mini-.NET runtime in a Wasm box" doesn't sound like a good time in the long term maintenance future to me when Blazor apps become legacy apps. But some of that gut instinct may just be cynicism at this point.

by Thaxll 3y ago

deleted 3y ago

[deleted]

chrisandchris 3y ago

I don't know Go that much, but the part about .Net is so untrue. First, C# was published in 2001, while Go was released in 2009. So there's 8 years of "more stuff". Also (see in comments too), upgrading .Net is very easy. There are man not-to-small codebases can be "easily" upgraded from .Net Core 3 to 8 without any hassle. Backwards comptability was always baked into Microsofts thinking. .Net 7 and 8 did also (IMHO) not contain that many groundbreaking features, just some "smaller" stuff.

Thaxll 3y ago
Do you want to compare the number of features added between go and c# in the last 15 years? Just a single major release of C# added more stuff than probably the last 15 years of Go. I'm not saying Go is 100% right in that, but it's much more conservative about stuff added into the language.
- HackerThemAll 3y ago
  Of course, they conservatively added the most idiotic way of formatting dates as strings (while knowing other methods exist). And, while the whole bunch of other languages would call a method string.startsWith("a"), they use hasPrefix. This language is a mix of half-baked concepts and utter trolling. If I have to learn a lang with an awkward syntax, I'd prefer Rust, Julia, Erlang, Elixir or Haskell. Go is no-go. It's not even widely used at Google, its creator. So no, thanks.
  - WorldMaker 3y ago
    Also, why would force error returns without also including some sort of nice Monadic do-notation or Monad-inspired combinator syntax sugar in the 2020s? We've known for decades now how do that better. I also think that Go looks like a practical joke that escaped some INTERCAL-like satire committee in the 1970s.
    - hollerith 3y ago
      You probably mean sum types and convenient syntax for testing and de-structuring sum types.
      - WorldMaker 3y ago
        No I specifically meant what is often called the Either or Result Monad. These are often implemented as Sum types, but they also follow the Monad laws and supports things like monadic binding/transformation/combination and benefit from syntax sugar like Haskell's "do-notation"/OCaML family's "computation expressions"/the "async/await" pattern of so many other languages now. Good sum types destructuring would probably also be useful in more languages like Go, but many languages today provide "async/await" pattern syntax benefits without anything at all like "proper" sum types. Sum types are "merely" a possible implementation detail of the Monad and it's the Monad laws that empower some things beyond just sum types.
        hollerith 3y ago
        Why pick on Golang, then? Rust doesn't have a monadic interface to side effects and "errors" either. Nor do the vast majority of the other newer languages.
        WorldMaker 3y ago
        Rust uses a sum type for most errors (Result<T, Error>) and there are common macros such as "error-chain" that apply a monadic approach to binding/combining them (or chaining them, as the preferred nomenclature in that case). Exception-based languages don't look monadic at first blush, they definitely aren't Sum types, but try/catch is one of the earliest and oldest of the monadic binding/combining approaches, even if it isn't often thought as such (and is barely considered more than goto/switch). It's far more obvious when you start to realize the intersection of async/await and try/catch is a working monad (and how that is reflected in Task/Promise monad instances). Golang is the obvious odd one out where every other line of "best practice" code is `if err != nil` and the only other advice is "well you could just ignore errors". try/catch doesn't ignore errors, it just looks like it. Rust error chaining doesn't ignore errors, it just looks like it. Golang gives you the choice between micro-managing errors or BASIC-style "ON ERROR RESUME NEXT" and I cannot get anyone to convince me why this isn't either a practical joke or an intentional throwback to writing code like it is the 1970s all over again (even VB6 had better options than "ON ERROR RESUME NEXT", even if they maybe weren't used as often as they should be in some legacy 1990s/2000s codebases).
jen20 3y ago
The real problem was upgrading from .NET Framework, or Mono, to .NET Core, which has been stable since. That comparison is not a fair comparison to Go, which has a much stricter guarantee around source and library compatibility within the 1.x series.

Capricorn2481 3y ago

People can write dumb, inconsistent code anywhere. A stable library will not protect you from a lack of PR reviews

pjmlp 3y ago

Thankfully .NET folks are confident that their audience has the skills to manage those features.

The_Colonel 3y ago

.NET / C# seems to be following C++ by including... everything. I wonder if they're just not worried about feature bloat or what's their thinking...

Metasyntactic 3y ago
Hi there, C# Lang Designer here. :) We're always thinking about the bloat concern when it comes to language development. However, our philosophy on it is that bloat primarily comes when you add replacement systems that are expected to supersede the previous mechanisms, not compliment them. So we try to do the former sparingly. In the history of C# there are very few times we've actually done this, and we do view those times as unfortunate cases where we likely rushed a feature too early and then regret having to live with those features forever. To help combat this, we tend to go through long periods of design and experimentation, where we propose features, create prototypes of them, and then interact with a large set of diverse community groups to try things out. The feedback from this is tightly bound into our design process and allows us to refine (or even jettison) designs rapidly. We also normally will both break up work into lots of smaller pieces (composing large language changes into small orthogonal, complimentary, composable blocks), and do designs over many years if appropriate. We think this approach has helped us create a language that is 25 years old, while being both very rich, and still very cohesive. There are a few mistakes we've made along the way ("anonymous-delegates", i'm looking at you), but we're very happy that our ratios here are very good given our continued investment in this space.
- terandle 3y ago
  The new array literals seem to supersede some previous syntaxes like new[] { 1, 2, 3 } goes to [1, 2, 3] in a lot of cases. But overall they are a _great_ addition to the language playing around with them now so bravo. Still not really sure how I feel about class primary constructors on the other hand, will give them some time to marinate.
  - oaiey 3y ago
    Share the exactly same worries. Let us see.

Kwpolska 3y ago

.NET is stable, they very rarely remove things. Code written for .NET Framework 2.x will probably work fine on .NET 8 (unless it uses the things that didn't make the jump, like WCF, but there are libraries that provide SOAP support.) Can a single developer remember all of .NET? No, but that applies to most languages/ecosystems. But if you encounter something you've never seen, you can always check the docs. And the thing hasn't been named ".NET Core" for 4 consecutive releases now.

merb 3y ago
Actually most wcf code does run on .net 7+ they open sourced it into corewcf. (At least a lot of the things) Webforms however is dead.
starik36 3y ago
> Code written for .NET Framework 2.x will probably work fine on .NET 8 WebForms would like a word.
- Kwpolska 3y ago
  Hence “probably”. WebForms should die in a dumpster fire.
  - WorldMaker 3y ago
    I worry that Blazor is that dumpster fire sometimes.
    - custard42 3y ago
      I'm curious, why do you say that?
      - WorldMaker 3y ago
        The mixture of client-side and server-side code that Blazor can allow in the same files gives me a very gut instinct feeling that "those who have forgotten the WebForms history, or worse the ASP Classic history, are doomed to repeat it". It's obviously different from both WebForms and ASP Classic and its use of Wasm is certainly a brand new idea that WebForms only wishes it had access to. It seems like a brand new mistake to me, because I still remember debugging ASP Classic and WebForms and Silverlight and "now even the client side JS of ~~WebForms~~ Blazor is no longer JS but a mini-.NET runtime in a Wasm box" doesn't sound like a good time in the long term maintenance future to me when Blazor apps become legacy apps. But some of that gut instinct may just be cynicism at this point.