8 ms·

Well put and I agree with most points but > Go is not a fun language to program in Not having to think about how something should be done in the most elegant

Well put and I agree with most points but > Go is not a fun language to program in Not having to think about how something should be done in the most elegant way, instead focus on the problem at hand is a lot of "fun"

throwaway894345 4y ago
Agreed. This was the only nit I was inclined to pick as well. I have a lot of fun writing Go, because it gets out of my way.
- afdbcreid 4y ago
  But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity".
  - throwaway894345 4y ago
    > But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity". Go typically does get in your way when you're doing things wrong, but yes, I'd like to see Go require return values be dealt with or explicitly ignored. That said, there are linters for this, but in practice it's never been a material problem for me so I haven't bothered to wire one into my project. Over time, I've learned not to be so concerned about issues which are mostly just theoretical--there are enough practical problems to deal with first.
    - yencabulator 4y ago
      > I'd like to see Go require return values be dealt with or explicitly ignored. Ever use the return value from fmt.Println?
      - throwaway894345 4y ago
        Not usually, but the correct answer would be to either explicitly ignore the unused return values or use APIs that don't return values you don't care about.
        preseinger 4y ago
        _ = fmt.Println("ok") // 1 fmt.Println("ok") // 2 1 is unambiguously worse than 2.
- reedjosh 4y ago
  I just can't stand taking three lines to unpack a value from a map or to return if error. Why can't I just say `return if err := somefunc(); err != nil` It's mega frustrating on top of the lack of generics and other abstractions. And now that generics are coming about, I'm sure it will take forever until my current project can use them. My current project is in the k8s ecosystem which due to the lack of generics, implemented its own clever but awful type system.
  - preseinger 4y ago
    The problem here is that you think "error handling" is somehow different, and probably less important, than normal logic in your codebase. But Go asserts that the "sad path" is just as important as the "happy path".
  - throwaway894345 4y ago
    I can't relate. Newline characters have never been burdensome to me, and they aid in visual structure (the control flow is represented by the visual structure of the program, not only for "good data" paths, but also for error paths). My programming problems are usually not related to localized keystroke boilerplate, but rather larger issues of abstraction and data modeling. > My current project is in the k8s ecosystem which due to the lack of generics, implemented its own clever but awful type system. The k8s ecosystem's type system is unrelated to generics. It has a concept of user-defined resource types, which means that users can provide an OpenAPI document describing their resource type which Kubernetes will then use to validate new user-provided resources of a given type. From the perspective of the Go compiler, these types are dynamic types--they can't be known at compile time. They aren't a candidate for generics in the host language. That said, it's often tedious to write a controller for these resource types, but that's because Kubernetes' controller frameworks are really complicated. They remind me of enterprise Java code with gratuitous abstraction. Maybe that abstraction serves some purpose, but it wasn't helping me and I ended up rewriting much of it in more standard Go (I didn't release it because it was prototype code and I didn't want to support it) and it was quite a lot simpler. I don't recall seeing many places where I felt that generics would be a significant improvement, but it's been a while.
xigoi 4y ago
Having to write the same code several times with minor changes because of a lack of abstraction is a lot of fun.
- LandR 4y ago
  I don't know how people can say go "gets out of the way". Go makes me write dozens of lines of code to do something simple that in an any modern language takes a few. It doesn't get out of the way, it gets in the way constantly. I'm constantly thinking in any modern language I can just do X, but in Go with its myriad missing features I have to sit and think about how I'm going to do it with just loops and if statements. It's the exact opposite of getting out the way, don't even get me started on the syntactic verbosity.
  - throwaway894345 4y ago
    Most programmers aren't bottlenecked by keyboard proficiency, but rather by dealing with poor tooling or gratuitously complex programs ("terse" doesn't entail "simple", and very often it's the inverse).
    - xigoi 4y ago
      That's a strawman. We're not advocating for terseness in character count (otherwise we'd be using languages like APL and Jelly), but for better abstractions. There are other benefits than character count. * Having a lot of repetitive code makes it easy to make a mistake when you edit one copy and forget about the others. * A lack of abstraction can obscure intent, making you focus on implementation details. * Having less code overall makes it easier to keep track of it in your head.
  - sangnoir 4y ago
    > Go makes me write dozens of lines of code to do something simple that in an any modern language takes a few. "Getting out of the way" doesn't mean it takes fewer keystrokes - it just means that you don't have to think about it / there are no surprises. It took me a while to grok what pythonic code is and looks like, and I feel the bar for Go is even lower. Even if you're browsing an unfamiliar codebase, code is exactly where you expect it to be, and you don't have to ponder on where to make your changes. To me, that is how a language moves out of the way; it fades into the background and you mostly concern yourself with the logic.
mjr00 4y ago
True, fun is certainly different for everyone! I also enjoy being able to just focus on a real world problem, but I also programmed Scala professionally for many years, and I found it a lot more fun purely from the point of view of writing code. Writing a really elegant for comprehension or using currying in clever ways to make your code "elegant" was just enjoyable in and of itself, regardless of what problem you were actually trying to solve. Rust is pretty similar to me in that regard.
- eweise 4y ago
  Same. I use Go for work because that's what the company uses, but I can't imagine coding in it for "fun". Elm + Scala feel much better to me.

throwaway894345 4y ago

Agreed. This was the only nit I was inclined to pick as well. I have a lot of fun writing Go, because it gets out of my way.

afdbcreid 4y ago
But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity".
- throwaway894345 4y ago
  > But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity". Go typically does get in your way when you're doing things wrong, but yes, I'd like to see Go require return values be dealt with or explicitly ignored. That said, there are linters for this, but in practice it's never been a material problem for me so I haven't bothered to wire one into my project. Over time, I've learned not to be so concerned about issues which are mostly just theoretical--there are enough practical problems to deal with first.
  - yencabulator 4y ago
    > I'd like to see Go require return values be dealt with or explicitly ignored. Ever use the return value from fmt.Println?
    - throwaway894345 4y ago
      Not usually, but the correct answer would be to either explicitly ignore the unused return values or use APIs that don't return values you don't care about.
      - preseinger 4y ago
        _ = fmt.Println("ok") // 1 fmt.Println("ok") // 2 1 is unambiguously worse than 2.
reedjosh 4y ago
I just can't stand taking three lines to unpack a value from a map or to return if error. Why can't I just say `return if err := somefunc(); err != nil` It's mega frustrating on top of the lack of generics and other abstractions. And now that generics are coming about, I'm sure it will take forever until my current project can use them. My current project is in the k8s ecosystem which due to the lack of generics, implemented its own clever but awful type system.
- preseinger 4y ago
  The problem here is that you think "error handling" is somehow different, and probably less important, than normal logic in your codebase. But Go asserts that the "sad path" is just as important as the "happy path".
- throwaway894345 4y ago
  I can't relate. Newline characters have never been burdensome to me, and they aid in visual structure (the control flow is represented by the visual structure of the program, not only for "good data" paths, but also for error paths). My programming problems are usually not related to localized keystroke boilerplate, but rather larger issues of abstraction and data modeling. > My current project is in the k8s ecosystem which due to the lack of generics, implemented its own clever but awful type system. The k8s ecosystem's type system is unrelated to generics. It has a concept of user-defined resource types, which means that users can provide an OpenAPI document describing their resource type which Kubernetes will then use to validate new user-provided resources of a given type. From the perspective of the Go compiler, these types are dynamic types--they can't be known at compile time. They aren't a candidate for generics in the host language. That said, it's often tedious to write a controller for these resource types, but that's because Kubernetes' controller frameworks are really complicated. They remind me of enterprise Java code with gratuitous abstraction. Maybe that abstraction serves some purpose, but it wasn't helping me and I ended up rewriting much of it in more standard Go (I didn't release it because it was prototype code and I didn't want to support it) and it was quite a lot simpler. I don't recall seeing many places where I felt that generics would be a significant improvement, but it's been a while.

xigoi 4y ago

Having to write the same code several times with minor changes because of a lack of abstraction is a lot of fun.

LandR 4y ago
I don't know how people can say go "gets out of the way". Go makes me write dozens of lines of code to do something simple that in an any modern language takes a few. It doesn't get out of the way, it gets in the way constantly. I'm constantly thinking in any modern language I can just do X, but in Go with its myriad missing features I have to sit and think about how I'm going to do it with just loops and if statements. It's the exact opposite of getting out the way, don't even get me started on the syntactic verbosity.
- throwaway894345 4y ago
  Most programmers aren't bottlenecked by keyboard proficiency, but rather by dealing with poor tooling or gratuitously complex programs ("terse" doesn't entail "simple", and very often it's the inverse).
  - xigoi 4y ago
    That's a strawman. We're not advocating for terseness in character count (otherwise we'd be using languages like APL and Jelly), but for better abstractions. There are other benefits than character count. * Having a lot of repetitive code makes it easy to make a mistake when you edit one copy and forget about the others. * A lack of abstraction can obscure intent, making you focus on implementation details. * Having less code overall makes it easier to keep track of it in your head.
- sangnoir 4y ago
  > Go makes me write dozens of lines of code to do something simple that in an any modern language takes a few. "Getting out of the way" doesn't mean it takes fewer keystrokes - it just means that you don't have to think about it / there are no surprises. It took me a while to grok what pythonic code is and looks like, and I feel the bar for Go is even lower. Even if you're browsing an unfamiliar codebase, code is exactly where you expect it to be, and you don't have to ponder on where to make your changes. To me, that is how a language moves out of the way; it fades into the background and you mostly concern yourself with the logic.

mjr00 4y ago

True, fun is certainly different for everyone! I also enjoy being able to just focus on a real world problem, but I also programmed Scala professionally for many years, and I found it a lot more fun purely from the point of view of writing code. Writing a really elegant for comprehension or using currying in clever ways to make your code "elegant" was just enjoyable in and of itself, regardless of what problem you were actually trying to solve. Rust is pretty similar to me in that regard.

eweise 4y ago
Same. I use Go for work because that's what the company uses, but I can't imagine coding in it for "fun". Elm + Scala feel much better to me.