9 ms·

Amen to that. I get super excited about Go releases because they often add useful stuff with zero breakage of anything (just free wins all around). It's not cle

Amen to that. I get super excited about Go releases because they often add useful stuff with zero breakage of anything (just free wins all around). It's not clear that any part of the language is so broken that backward compatible changes can't fix it. Even the few foot guns like loop variable assignment have proposals that mostly preserve compatibility.

sedatk 3y ago
Interesting because I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”, “it becomes harder to learn”. I totally have your perspective on this, but the difference in attitudes is noteworthy.
- sudhirj 3y ago
  I haven't used C# in over a decade, but I was already feeling that way - there's just a lot in there. Go seems to start with a default no to things, so that might be why it has a relatively small surface area.
- jerf 3y ago
  In the past ten years, here's a list of significant feature additions to the Go language itself: * Generics And even that has not been the shocking revolution some people expected; it turns out to overall be a nice little addition rather than something that rewrote what good Go was. Nothing like the Python transition to "new style" classes, or the Python 2 -> 3 transition, or the Python async ecosystem transition, and that's just one language. For the most part a Go 1.4 programmer suddenly transported to today would not find it a terribly difficult task to read code using the generics. And broadly speaking, the language didn't start with a lot of features either. Go has had a lot of library improvements, it's had a lot of tooling improvements, but the language itself is extremely stable. I've seen a few people actually complain about Go moving too fast, to which I wonder what exactly would make them happy if even Go is zooming along too quickly for them, because I honestly don't know a language moving more slowly than Go, for all the advantages and all the disadvantages that incurs. I've honestly sort of wished I could sit down with them for 15 minutes and see if I could figure out what their real problem is, or if they really are upset that there was ever a major change.
  - arp242 3y ago
    The biggest problem has been the GOPATH → modules conversion, which broke lots of (or all?) tooling. For example, I had written a fairly nice program to analyse Go code and generate an OpenAPI document, but when modules came around quite a bit of that broke, and it's non-trivial to fix. It still works in "GOPATH mode", but few people use that these days.
    - xmprt 3y ago
      I'm curious to learn what sort of issues you've seen when trying to use modules instead of GOPATH? Most of the migrations I've done have been pretty seamless and the few that had issues where all easy to resolve with a few replace directives or similar.
      - arp242 3y ago
        Anyone who has written any tooling that works with Go code saw issues because almost everything changed in this regard. I was maintaining vim-go at the time, and quite a few changes were needed there too. I don't have a list of issues at hand because it's been a while, but generally speaking the only reason things went "pretty seamless" is because people spent time updating the tooling.
- neonsunset 3y ago
  C# mostly suffers from having way too many options to do something. The quality of the average codebase written in 10 layer-abstraction-heavy OOP style that does not leverage the language features for writing concise and understandable code does not help either. This is one of the reasons people rave about F# - it's less about the language and more about not suffering from really bad tradition that has settled over the years. Don't get me wrong, the situation improves significantly each year, but the developers who require extensive explanatory work to get any semblance of buy-in to stop doing things the painful and cargo-cult-y way are still in the majority. Otherwise, I think C# is very approachable thanks to it being extremely forgiving language* in general and standard library offering easy-with-pretty-good-defaults shortcut options to do the basics like networking, file io, hashing, creating simple web servers and UI applications, etc. Its both CLI and IDE tooling is also top notch today. * Forgiving as in, mistakes usually tend to decrease otherwise excellent (better than Go) performance rather than cause critical failures.
  - zimpenfish 3y ago
    > The quality of the average codebase written in 10 layer-abstraction-heavy OOP style They did not learn from Perl, it seems.
    - xorcist 3y ago
      Why do you think Perl is abstraction-heavy?
      - zimpenfish 3y ago
        Perl, itself, isn't but if you let lunatics loose on it for 10 years without adult supervision, you'll end up with people writing their own ORMs, their own object models, etc. and you have a fragile tower of abstractions that you can't even look at for fear of it imploding.
        xorcist 3y ago
        As opposed to Java, C++, ..?
- kaba0 3y ago
  Which are valid fears -- C# has become a language with an insanely big surface area, almost comparable to C++'s. This surface area will get rough, unforeseen edges when multiple different features are used together (no matter how generally good C#'s design is), so on the end-user dev it is not even a linear-only weight to learn. Java is a common butt of jokes among C# devs, but in my opinion its addition of features to the language while committing to backwards compatibility is simply the best in the industry and should be copied by every language pertaining to a similar status (not for research languages obviously, they should be the ones experimenting) -- they seldom add new features, only those that have been proven by others and trying to kill multiple birds with a single stone in each case. Also, .NET does have a dubious past regarding backwards comp. from what I gathered, "its" frontend churn alone is remarkable, the only thing more spectacular is their renamings.
  - pjmlp 3y ago
    > Java is a common butt of jokes among C# devs.... And those of us Polyglot devs, have positive and negative arguments that go both ways.
    - kaba0 3y ago
      Indeed, both languages have plenty positives and quite a few warts as well. While I do prefer Java personally, I consider C# an absolutely fine choice for almost every usecase. Go on the other hand, I'm much less forgiving about.
      - pjmlp 3y ago
        C# is getting some strange design decisions of lately, see inline arrays, and interceptors. Yeah, they had plenty of hindsight, and still....
        zigzag312 3y ago
        Why are they strange? Interceptors seem to enable migration away from reflection, for better support of AOT compilation. For example: https://github.com/DapperLib/Dapper/issues/1909 https://github.com/DapperLib/Dapper/issues/1909
- zigzag312 3y ago
  I've seen this repeated a few times in online forums, but that's not my experience. Language itself has gotten bigger, but code has become much less bloated and elegant. To me, it's easier to read new C# code than the old one. I'm probably biased as I use C# a lot. But I think that with advent of GPT tools, larger languages have become much less of an issue that they were in the past. They make it really easy to get explanation of code or feature you don't understand right there on the spot.
- 0xDEF 3y ago
  >I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”, I don't recognize this sentiment at all and I think it's almost non-existent among developers who use ReSharper or Rider that will both introduce useful new language features as a refactoring suggestion that is one shortcut away. .Net developers can easily get away with not keeping up with new C# language features. A .Net developer who went into coma in 2012 after having learned async/await and ASP.NET MVC can return to a hypermodern ASP.NET Core 7 codebase and be almost instantly productive.
ilyt 3y ago
I'd like to see sum types and some better way to deal with error verbosity.
afavour 3y ago
> It's not clear that any part of the language is so broken that backward compatible changes can't fix it Broadly I agree but the future is kind of unknowable. For example Rust’s 2018 edition introduced the async keyword, a breaking change because you could have made a variable or function named “async” in the 2015 edition. Async functions weren’t something the first version of Rust and they were introduced with a breaking chance. I like backwards compatibility but am unsure about a future where Go can’t do innovation X because it would break compatibility.
- monocasa 3y ago
  FWIW async was only sort of a breaking change. The edition system meant that no crates would stop compiling, even with newer compilers, and you can mix crates of different editions in the same build product.
TheDong 3y ago
Just to throw in my 2c, I've had significant breakages with most Go upgrades. I've had far fewer issues with rust upgrades, and gcc upgrades. C and Rust compiler updates feel actually backwards compatible to me. I posted a list of a few breakages I've run into before, though of course I've run into more since, and far more I didn't mention there: https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324 I think the main reason I've had more issues with Go upgrades than with Rust upgrades or C upgrades is because for rust/gcc, I'm upgrading the compiler and getting language features, but most of the complex libraries don't change, and I can upgrade them separately from the compiler (i.e. hyper for http in rust, or libcurl in C). For go, whenever I upgrade the compiler, I get a mix of language features (generics, embed, other toolchain features), but also a set of library updates (tls and security libraries yet again dropping support for something I use, http client or server changes, etc). I think go would have been much better served by making 'http', 'tls', 'crypto', and other large chunks of the standard library their own separate libraries. Even if you kept the exact same go1 promise for those (which is to say "we sometimes break http and tls, but we tell you it's backwards compatible"), it would be far better because I could then actually fearlessly upgrade the go compiler version, and then later upgrade those libraries at my own pace. Or, when the tls upgrade breaks my code for the nth time, I could roll it back without also having to roll back the entire compiler version and revert any code changes which used new compiler features. It also really makes no sense for libraries like 'http' and 'archive/*' to be part of the standard library. Presumably they're just there because the Go team wanted to release 1.0 before figuring out a good dependency system (though golang.org/x/ was a really quick follow-on, and that would have been enough for these), but that has led to the "go 1 compatibility promise" really meaning "enough go upgrades break my code that I'm scared to update, but not because the compiler has a breaking change, but because some part of the stdlib that doesn't even need to be bundled with the compiler breaks me".

sedatk 3y ago

Interesting because I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”, “it becomes harder to learn”. I totally have your perspective on this, but the difference in attitudes is noteworthy.

sudhirj 3y ago
I haven't used C# in over a decade, but I was already feeling that way - there's just a lot in there. Go seems to start with a default no to things, so that might be why it has a relatively small surface area.
jerf 3y ago
In the past ten years, here's a list of significant feature additions to the Go language itself: * Generics And even that has not been the shocking revolution some people expected; it turns out to overall be a nice little addition rather than something that rewrote what good Go was. Nothing like the Python transition to "new style" classes, or the Python 2 -> 3 transition, or the Python async ecosystem transition, and that's just one language. For the most part a Go 1.4 programmer suddenly transported to today would not find it a terribly difficult task to read code using the generics. And broadly speaking, the language didn't start with a lot of features either. Go has had a lot of library improvements, it's had a lot of tooling improvements, but the language itself is extremely stable. I've seen a few people actually complain about Go moving too fast, to which I wonder what exactly would make them happy if even Go is zooming along too quickly for them, because I honestly don't know a language moving more slowly than Go, for all the advantages and all the disadvantages that incurs. I've honestly sort of wished I could sit down with them for 15 minutes and see if I could figure out what their real problem is, or if they really are upset that there was ever a major change.
- arp242 3y ago
  The biggest problem has been the GOPATH → modules conversion, which broke lots of (or all?) tooling. For example, I had written a fairly nice program to analyse Go code and generate an OpenAPI document, but when modules came around quite a bit of that broke, and it's non-trivial to fix. It still works in "GOPATH mode", but few people use that these days.
  - xmprt 3y ago
    I'm curious to learn what sort of issues you've seen when trying to use modules instead of GOPATH? Most of the migrations I've done have been pretty seamless and the few that had issues where all easy to resolve with a few replace directives or similar.
    - arp242 3y ago
      Anyone who has written any tooling that works with Go code saw issues because almost everything changed in this regard. I was maintaining vim-go at the time, and quite a few changes were needed there too. I don't have a list of issues at hand because it's been a while, but generally speaking the only reason things went "pretty seamless" is because people spent time updating the tooling.
neonsunset 3y ago
C# mostly suffers from having way too many options to do something. The quality of the average codebase written in 10 layer-abstraction-heavy OOP style that does not leverage the language features for writing concise and understandable code does not help either. This is one of the reasons people rave about F# - it's less about the language and more about not suffering from really bad tradition that has settled over the years. Don't get me wrong, the situation improves significantly each year, but the developers who require extensive explanatory work to get any semblance of buy-in to stop doing things the painful and cargo-cult-y way are still in the majority. Otherwise, I think C# is very approachable thanks to it being extremely forgiving language* in general and standard library offering easy-with-pretty-good-defaults shortcut options to do the basics like networking, file io, hashing, creating simple web servers and UI applications, etc. Its both CLI and IDE tooling is also top notch today. * Forgiving as in, mistakes usually tend to decrease otherwise excellent (better than Go) performance rather than cause critical failures.
- zimpenfish 3y ago
  > The quality of the average codebase written in 10 layer-abstraction-heavy OOP style They did not learn from Perl, it seems.
  - xorcist 3y ago
    Why do you think Perl is abstraction-heavy?
    - zimpenfish 3y ago
      Perl, itself, isn't but if you let lunatics loose on it for 10 years without adult supervision, you'll end up with people writing their own ORMs, their own object models, etc. and you have a fragile tower of abstractions that you can't even look at for fear of it imploding.
      - xorcist 3y ago
        As opposed to Java, C++, ..?
kaba0 3y ago
Which are valid fears -- C# has become a language with an insanely big surface area, almost comparable to C++'s. This surface area will get rough, unforeseen edges when multiple different features are used together (no matter how generally good C#'s design is), so on the end-user dev it is not even a linear-only weight to learn. Java is a common butt of jokes among C# devs, but in my opinion its addition of features to the language while committing to backwards compatibility is simply the best in the industry and should be copied by every language pertaining to a similar status (not for research languages obviously, they should be the ones experimenting) -- they seldom add new features, only those that have been proven by others and trying to kill multiple birds with a single stone in each case. Also, .NET does have a dubious past regarding backwards comp. from what I gathered, "its" frontend churn alone is remarkable, the only thing more spectacular is their renamings.
- pjmlp 3y ago
  > Java is a common butt of jokes among C# devs.... And those of us Polyglot devs, have positive and negative arguments that go both ways.
  - kaba0 3y ago
    Indeed, both languages have plenty positives and quite a few warts as well. While I do prefer Java personally, I consider C# an absolutely fine choice for almost every usecase. Go on the other hand, I'm much less forgiving about.
    - pjmlp 3y ago
      C# is getting some strange design decisions of lately, see inline arrays, and interceptors. Yeah, they had plenty of hindsight, and still....
      - zigzag312 3y ago
        Why are they strange? Interceptors seem to enable migration away from reflection, for better support of AOT compilation. For example: https://github.com/DapperLib/Dapper/issues/1909 https://github.com/DapperLib/Dapper/issues/1909
zigzag312 3y ago
I've seen this repeated a few times in online forums, but that's not my experience. Language itself has gotten bigger, but code has become much less bloated and elegant. To me, it's easier to read new C# code than the old one. I'm probably biased as I use C# a lot. But I think that with advent of GPT tools, larger languages have become much less of an issue that they were in the past. They make it really easy to get explanation of code or feature you don't understand right there on the spot.
0xDEF 3y ago
>I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”, I don't recognize this sentiment at all and I think it's almost non-existent among developers who use ReSharper or Rider that will both introduce useful new language features as a refactoring suggestion that is one shortcut away. .Net developers can easily get away with not keeping up with new C# language features. A .Net developer who went into coma in 2012 after having learned async/await and ASP.NET MVC can return to a hypermodern ASP.NET Core 7 codebase and be almost instantly productive.

ilyt 3y ago

I'd like to see sum types and some better way to deal with error verbosity.

afavour 3y ago

> It's not clear that any part of the language is so broken that backward compatible changes can't fix it Broadly I agree but the future is kind of unknowable. For example Rust’s 2018 edition introduced the async keyword, a breaking change because you could have made a variable or function named “async” in the 2015 edition. Async functions weren’t something the first version of Rust and they were introduced with a breaking chance. I like backwards compatibility but am unsure about a future where Go can’t do innovation X because it would break compatibility.

monocasa 3y ago
FWIW async was only sort of a breaking change. The edition system meant that no crates would stop compiling, even with newer compilers, and you can mix crates of different editions in the same build product.

TheDong 3y ago

Just to throw in my 2c, I've had significant breakages with most Go upgrades. I've had far fewer issues with rust upgrades, and gcc upgrades. C and Rust compiler updates feel actually backwards compatible to me. I posted a list of a few breakages I've run into before, though of course I've run into more since, and far more I didn't mention there: https://news.ycombinator.com/item?id=29763324 https://news.ycombinator.com/item?id=29763324 I think the main reason I've had more issues with Go upgrades than with Rust upgrades or C upgrades is because for rust/gcc, I'm upgrading the compiler and getting language features, but most of the complex libraries don't change, and I can upgrade them separately from the compiler (i.e. hyper for http in rust, or libcurl in C). For go, whenever I upgrade the compiler, I get a mix of language features (generics, embed, other toolchain features), but also a set of library updates (tls and security libraries yet again dropping support for something I use, http client or server changes, etc). I think go would have been much better served by making 'http', 'tls', 'crypto', and other large chunks of the standard library their own separate libraries. Even if you kept the exact same go1 promise for those (which is to say "we sometimes break http and tls, but we tell you it's backwards compatible"), it would be far better because I could then actually fearlessly upgrade the go compiler version, and then later upgrade those libraries at my own pace. Or, when the tls upgrade breaks my code for the nth time, I could roll it back without also having to roll back the entire compiler version and revert any code changes which used new compiler features. It also really makes no sense for libraries like 'http' and 'archive/*' to be part of the standard library. Presumably they're just there because the Go team wanted to release 1.0 before figuring out a good dependency system (though golang.org/x/ was a really quick follow-on, and that would have been enough for these), but that has led to the "go 1 compatibility promise" really meaning "enough go upgrades break my code that I'm scared to update, but not because the compiler has a breaking change, but because some part of the stdlib that doesn't even need to be bundled with the compiler breaks me".