3 ms·

Not a fan of Go, but I'll give credit where it's due: This is a good feature for the language to afford.

mettamage 5y ago
Why are you not a fan? Asking as someone who likes a few things and dislikes a few things about it. So basically asking out of curiosity.
- mseepgood 5y ago
  Probably something about generics, which is no longer an issue if you use the Go 1.18 Release Candidate today or the final release in four weeks.
  - vsnf 5y ago
    It's about a lot more than just generics, at least for me. I'm not interested in derailing this thread to into one bashing Go, but there's a bunch of things that are distasteful about the language. Go appeals to certain kinds of programmers, and is actively repulsive to different kinds. This division breeds animosity when the kind of programmers who are repulsed are forced to interact with it. Also, the community has a big attitude problem.
    - zibzab 5y ago
      I think that is a good thing. Most people trying to "fix" go are basically trying to make it into that other language they are more comfortable with. If I wanted to use ruby, I would use ruby. I use go because even its presumed limitations are an advantage (for me).
- ParetoOptimal 5y ago
  Enums and iota weirdness made my love for Go start to crack. I learned about abstract data types and discriminated unions, then wondered why Go didn't have those. The prevalence and overuse of interface{} undermined type safety at jobs I had writing Go and errors from this apparently popular style of Go programming filled the logs. Then I saw someone say "Go's error handling on values is good, but it's better in a language with Either". I looked up examples, and indeed it seemed nicer and retained the value proposition of errors as values. I wish Go had either. Then bugs started happening in code that was copy pasted... but why was it copy pasted? Lack of generics were the final straw and I started playing with Haskell in the evenings. It gave me the type safety I wanted and more. It's not perfect, but it's based on a philosophy I believe is more correct than the worse is better values of Go that seek micro-level simplicity at the cost of macro-level complexity.
  - Groxx 5y ago
    >micro-level simplicity at the cost of macro-level complexity That pretty succinctly covers a lot of my not-fond-about-Go reasons too. There's a lot to like about Go for small projects - I've replaced a lot of my CLI-writing languages/tools with Go code and it's a dramatic improvement and I'm quite happy with it for that. But it falls apart badly when you're trying to do highly-stable, highly-correct, or highly-complex things. Not being able to know what errors can be returned is a HUGE source of missing error handling. Fatal errors containing only "not found" after passing through dozens of calls wastes a ridiculous amount of troubleshooting time. Not-so-minor mismatches between reality and Go's SDK are covered up in awkward, error-prone ways with no real alternatives (because the core library can and does do things you cannot). https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... for a much more detailed decline into madness because of all this. If you are sufficiently careful, almost none of this is a problem, true. Experts are consistently able to write safe C code, right? ........right? --- Honestly I expect generics to be a pretty significant improvement. E.g. intrusive concurrency control is unbelievably error-prone in bulk, and generics will let us finally have safe and easy higher level constructs for most code. I also know of a few projects I've touched that will likely be able to remove 10-20% of the codebase just because we won't have to go to great lengths to maintain (or check after abandoning) type safety. It's a simple and reasonable implementation of generics, especially since there's no inheritance to worry about. I'm looking forward to it... but I probably still won't like Go.

Why are you not a fan? Asking as someone who likes a few things and dislikes a few things about it. So basically asking out of curiosity.

mseepgood 5y ago
Probably something about generics, which is no longer an issue if you use the Go 1.18 Release Candidate today or the final release in four weeks.
- vsnf 5y ago
  It's about a lot more than just generics, at least for me. I'm not interested in derailing this thread to into one bashing Go, but there's a bunch of things that are distasteful about the language. Go appeals to certain kinds of programmers, and is actively repulsive to different kinds. This division breeds animosity when the kind of programmers who are repulsed are forced to interact with it. Also, the community has a big attitude problem.
  - zibzab 5y ago
    I think that is a good thing. Most people trying to "fix" go are basically trying to make it into that other language they are more comfortable with. If I wanted to use ruby, I would use ruby. I use go because even its presumed limitations are an advantage (for me).
ParetoOptimal 5y ago
Enums and iota weirdness made my love for Go start to crack. I learned about abstract data types and discriminated unions, then wondered why Go didn't have those. The prevalence and overuse of interface{} undermined type safety at jobs I had writing Go and errors from this apparently popular style of Go programming filled the logs. Then I saw someone say "Go's error handling on values is good, but it's better in a language with Either". I looked up examples, and indeed it seemed nicer and retained the value proposition of errors as values. I wish Go had either. Then bugs started happening in code that was copy pasted... but why was it copy pasted? Lack of generics were the final straw and I started playing with Haskell in the evenings. It gave me the type safety I wanted and more. It's not perfect, but it's based on a philosophy I believe is more correct than the worse is better values of Go that seek micro-level simplicity at the cost of macro-level complexity.
- Groxx 5y ago
  >micro-level simplicity at the cost of macro-level complexity That pretty succinctly covers a lot of my not-fond-about-Go reasons too. There's a lot to like about Go for small projects - I've replaced a lot of my CLI-writing languages/tools with Go code and it's a dramatic improvement and I'm quite happy with it for that. But it falls apart badly when you're trying to do highly-stable, highly-correct, or highly-complex things. Not being able to know what errors can be returned is a HUGE source of missing error handling. Fatal errors containing only "not found" after passing through dozens of calls wastes a ridiculous amount of troubleshooting time. Not-so-minor mismatches between reality and Go's SDK are covered up in awkward, error-prone ways with no real alternatives (because the core library can and does do things you cannot). https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... for a much more detailed decline into madness because of all this. If you are sufficiently careful, almost none of this is a problem, true. Experts are consistently able to write safe C code, right? ........right? --- Honestly I expect generics to be a pretty significant improvement. E.g. intrusive concurrency control is unbelievably error-prone in bulk, and generics will let us finally have safe and easy higher level constructs for most code. I also know of a few projects I've touched that will likely be able to remove 10-20% of the codebase just because we won't have to go to great lengths to maintain (or check after abandoning) type safety. It's a simple and reasonable implementation of generics, especially since there's no inheritance to worry about. I'm looking forward to it... but I probably still won't like Go.