8 ms·

Ok so you can deliver projects. But what about the next guy that has to maintain them? At my work, we use Go extensively on the backend. Yes, it’s capable of b

Ok so you can deliver projects. But what about the next guy that has to maintain them? At my work, we use Go extensively on the backend. Yes, it’s capable of being used by engineers to ship projects - most languages are capable of that. But I do know we write a lot of boilerplate, and repeat ourselves all the time. We still see nil pointers occasionally (in 2018! Why are they still a thing). Even though I work with a bunch of smart engineers, the language has pressured us to write more code than we need to, which means more maintenance will be required in the future. After having worked with it for 2+ years, I wish we had just used Java or even JavaScript.

maxaf 9y ago
Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. It turns out that the verbosity of, for example, Go's error handling is actually simpler to understand and easier to read than any monadic contraption I've seen in the wild. It's also safer and lighter than Java's use of exceptions (checked or otherwise) because of the non-exceptional nature of equality comparisons and multi-valued returns. Lastly, the idea that generics somehow remove the pain of null pointers is simply false. I've done 8 years of Scala before defecting to Go, and still have nightmares about an empty Option[T] that has caused some n-level-deep monadic computation to return nothing. In this case, Go would at least blow up with a helpful stack trace, while the Scala program would continue to run and return erroneous results.
- yen223 9y ago
  The notion that verbose == easy-to-read is a myth that needs to die
  - weberc2 9y ago
    Not as much as the "code golf is easy to read" myth that is popular among language communities that advertise their minimal line counts.
- kasey_junk 9y ago
  I think the argument that ‘Scala is over complex’ is not a compelling argument against the premise that ‘go is too simple’. Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions. Don’t get me started on the golang generics & concurrency problems. I continue to use golang in spite of their language decisions around these items, not because of them.
  - kasey_junk 9y ago
    As an aside, I answered all of these questions in a way that the blog post describes as positive yet am very critical of go in reality.
  - sagichmal 9y ago
    > Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions. This has not been my experience. Idiomatic Go -- that is, not trying to do obtuse, clever, or dumb things to avoid error handling -- results in very clean and error-free code by default. I see unexpected runtime errors maybe a few times a year. I haven't seen unexpected panics in years.
    - kasey_junk 9y ago
      Serious question, when you see non obtuse, clever or dumb things for error handling how do you attribute language?
      - sagichmal 9y ago
        Attribute language? I'm not sure what you mean. In Go there is typically a very restricted set of ways to idiomatically accomplish a given task, often only one. Error management is a prime example. result, err := function() What do you do with err? If it is recoverable, you should try to recover from it. if err == ErrTryAgain { continue } Generally errors aren't recoverable, and should be reported back up the stack with some kind of contextual annotation. if err != nil { return fmt.Errorf("function failed: %v", err) } If you want to provide more context to your caller, to enable a richer set of responses to this error, you can use more structure. if err != nil { return FunctionError{Original: err, ...} } That's really about it. Anything that tries to subvert the very simple/plain `if` checking, or tries to perform some kind of monadic error chaining, or builds an ersatz exception system with panic/recover, is what I mean when I talk about "obtuse, clever, or dumb things". The language and its idioms form these expectations.
- sjellis 9y ago
  "Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written." Yes, it honestly sounds like a taste issue. Go has it's own patterns, so if you instinctively expect your code to be like another language, it will probably feel wrong. I suspect that it is at the root of a lot of the comments about generics: people aren't comfortable with the style of Go, but aren't sure why, so they latch on to "generics".
- flavio81 9y ago
  >Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. Code also needs to be written quickly and cleanly so it can be augmented later. I don't think Go contributes in this regard.
weberc2 9y ago
If null pointers are your problem, Java and JavaScript are not the answer. If overall type safety is your problem, JS is definitely not the answer. If you don't like boilerplate and can accommodate dynamic typing, you can just use interface{} for the generic bits and statically type the other 95% (which is still a 95% improvement over JS--even better since Go catches impossible type assertion errors and gives better messaging for runtime type errors). Generics would be an improvement to Go for sure, but Go is still one of the best overall application development languages available today (greenfield or maintenance mode).

maxaf 9y ago

Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. It turns out that the verbosity of, for example, Go's error handling is actually simpler to understand and easier to read than any monadic contraption I've seen in the wild. It's also safer and lighter than Java's use of exceptions (checked or otherwise) because of the non-exceptional nature of equality comparisons and multi-valued returns. Lastly, the idea that generics somehow remove the pain of null pointers is simply false. I've done 8 years of Scala before defecting to Go, and still have nightmares about an empty Option[T] that has caused some n-level-deep monadic computation to return nothing. In this case, Go would at least blow up with a helpful stack trace, while the Scala program would continue to run and return erroneous results.

yen223 9y ago
The notion that verbose == easy-to-read is a myth that needs to die
- weberc2 9y ago
  Not as much as the "code golf is easy to read" myth that is popular among language communities that advertise their minimal line counts.
kasey_junk 9y ago
I think the argument that ‘Scala is over complex’ is not a compelling argument against the premise that ‘go is too simple’. Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions. Don’t get me started on the golang generics & concurrency problems. I continue to use golang in spite of their language decisions around these items, not because of them.
- kasey_junk 9y ago
  As an aside, I answered all of these questions in a way that the blog post describes as positive yet am very critical of go in reality.
- sagichmal 9y ago
  > Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions. This has not been my experience. Idiomatic Go -- that is, not trying to do obtuse, clever, or dumb things to avoid error handling -- results in very clean and error-free code by default. I see unexpected runtime errors maybe a few times a year. I haven't seen unexpected panics in years.
  - kasey_junk 9y ago
    Serious question, when you see non obtuse, clever or dumb things for error handling how do you attribute language?
    - sagichmal 9y ago
      Attribute language? I'm not sure what you mean. In Go there is typically a very restricted set of ways to idiomatically accomplish a given task, often only one. Error management is a prime example. result, err := function() What do you do with err? If it is recoverable, you should try to recover from it. if err == ErrTryAgain { continue } Generally errors aren't recoverable, and should be reported back up the stack with some kind of contextual annotation. if err != nil { return fmt.Errorf("function failed: %v", err) } If you want to provide more context to your caller, to enable a richer set of responses to this error, you can use more structure. if err != nil { return FunctionError{Original: err, ...} } That's really about it. Anything that tries to subvert the very simple/plain `if` checking, or tries to perform some kind of monadic error chaining, or builds an ersatz exception system with panic/recover, is what I mean when I talk about "obtuse, clever, or dumb things". The language and its idioms form these expectations.
sjellis 9y ago
"Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written." Yes, it honestly sounds like a taste issue. Go has it's own patterns, so if you instinctively expect your code to be like another language, it will probably feel wrong. I suspect that it is at the root of a lot of the comments about generics: people aren't comfortable with the style of Go, but aren't sure why, so they latch on to "generics".
flavio81 9y ago
>Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. Code also needs to be written quickly and cleanly so it can be augmented later. I don't think Go contributes in this regard.

weberc2 9y ago

If null pointers are your problem, Java and JavaScript are not the answer. If overall type safety is your problem, JS is definitely not the answer. If you don't like boilerplate and can accommodate dynamic typing, you can just use interface{} for the generic bits and statically type the other 95% (which is still a 95% improvement over JS--even better since Go catches impossible type assertion errors and gives better messaging for runtime type errors). Generics would be an improvement to Go for sure, but Go is still one of the best overall application development languages available today (greenfield or maintenance mode).