4 ms·

At first I've avoided Go like the plague because it lacks generics. A couple of years ago, I happened to pick up Go for a work project, and managed to ship it

by maxaf 9y ago

At first I've avoided Go like the plague because it lacks generics. A couple of years ago, I happened to pick up Go for a work project, and managed to ship it despite the lack of generics in Go. I realized that this was some of the most fun work I've ever done because of Go's various properties. I decided to take what is given and kept Go-ing. (Pun intended...) Having just passed my 2nd anniversary as a Gopher (a Gopherversary?) I still manage to ship projects despite Go's glaring lack of generics. Based on my own personal experience I can thus conclude that the non/availability of generics has very little to do with how strongly a programming language enables engineers to deliver projects.

thatswrong0 9y ago
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?
- 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).
pjmlp 9y ago
I have been coding since 1986, of course I was able to ship software into production despite the lack of generics in the languages I was using. Even Oberon, one of my favourite languages and influence to Go, which I had the pleasure to spend one year using during the mid-90's lacks generics. That doesn't mean in 2018 I should be happy when forced to use a language whose concept of generics is to manually generate code like we used to do on those days (//go:generate).

by maxaf 9y ago

thatswrong0 9y ago

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?
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).

pjmlp 9y ago

I have been coding since 1986, of course I was able to ship software into production despite the lack of generics in the languages I was using. Even Oberon, one of my favourite languages and influence to Go, which I had the pleasure to spend one year using during the mid-90's lacks generics. That doesn't mean in 2018 I should be happy when forced to use a language whose concept of generics is to manually generate code like we used to do on those days (//go:generate).