4 ms·

> There is a cost to introducing an abstraction layer. Go code is usually rather clear, at the cost of being a bit repetitive at times. Go programmers say this

> There is a cost to introducing an abstraction layer. Go code is usually rather clear, at the cost of being a bit repetitive at times. Go programmers say this a lot and every time I see it I wince. We've had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chance there is for bugs. And so it's so confusing to me why Go programmers simply discard this information, universally accepted as it has come to be. "The repetition is simple," they reply, "and of course abstractions have cost." So what is the cost? Because I can tell you the state of affairs right now. I find Go code exhausting to debug, because there is effectively no universal way to handle errors other than to copy-paste if-nil statements. Occasionally, slightly different error handling logic creeps in and it's so tempting to start pattern matching the whole block of code and miss these subtleties. This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes. Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible. As such, it is quick to learn the syntax. It's not really any quicker to learn how to write good robust multi-threaded code though. I still think the Java standard library consistently delivers a better result for equivalent work, at the cost of learning and extra (standard) library. I just don't understand why anyone appreciated go's design space outside of engineers-turned-architects trying to staff a massive tech org with engineers they don't think very much of and have no desire to train.

treehau5 9y ago
As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." After a decade of OOP indoctrination and misuse, we see the results of this. > Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible This lends me to believe you actually haven't written any go code for yourself. This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. I came from those languages, and this statement is categorically false and completely unfounded in reality.
- KirinDave 9y ago
  > After a decade of OOP indoctrination and misuse, we see the results of this. Sure, but that's OO's fault and the lesson is not "abstractions are bad" but rather, "OO's good at domain abstractions and bad at universal abstractions." The takeaway should not be to discard the last 12 years of advances in computer science and call it quits with a bad copy of Erlang's concurrency model and a weak version of C. > This lends me to believe you actually haven't written any go code for yourself. I've written about 5000 lines. So not a ton, but enough to have shipped Go to prod and be capable of reading it. > This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. Go is more OOP-focused with its weak interface{} methodology than anything I promote or have used joyfully in the last 6 years. Even the most cursory examination of my presence will reveal that. Please don't put words in my mouth to tidy your argument.
  - deleted 9y ago
    [deleted]
- camus2 9y ago
  > As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." like writing 500 * if err != nil { return err } is an average Go app? A little yes, but this isn't a little.
  - treehau5 9y ago
    like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching. Sorry, the if err != nil horse has been beaten to death already.
    - camus2 9y ago
      > like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? What is insane is believing returning errors is actually handling them, it is not, you're just passing the burden on the caller. Second, Go isn't free of all the bullhshit you described so I'm not sure what is your point, that you don't have to write getters and setters in Go? lol, off course you do have to. > Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching Who cares, go back playing Pokemon since apparently that's the only thing you can think off and stop being an hypocrite. What do you think panics are? yes, it's an half-baked exception system, like everything in Go, a language designed by people who clearly didn't know what they are doing, for people who don't. > Sorry, the if err != nil horse has been beaten to death already Yes, and don't worry, people will keep on beating that horse, because it was designed by people that clearly don't know what they are doing.
thesmallestcat 9y ago
Regarding your last paragraph, it's a reflection of the state of the industry. The vast majority of "software engineers"/"full stack developers" can't be bothered to learn new skills or improve their existing ones, so any popular programming tool is stuck catering to the least common denominator. Do you carefully review your own code? Do you voluntarily learn any new skill beyond "blog post intro tutorial" level? Do you think about the consequences of a change you make beyond the immediate need it addresses? Congratulations: Regardless of talent, you're already better than ~90% of professional programmers. You're a "10x developer" by virtue of the fact that by a reasonable baseline of quality the remainder are "0.1x developers" or worse. I don't think that Google is wrong to focus on mitigating the damage that the majority of engineers will inflict on a codebase. In fact it's depressing how right they are, and what the realities of software engineering look like at scale. It confuses me though that small teams select tools built to solve those problems.
- figgis 9y ago
  > Do you carefully review your own code? Do you have any resources for getting better at this? I don't get a lot of chances for other people to review what I write (yeah believe me I know..) and am looking into better ways to make sure I don't release shit. I have a decent amount of testing automated for a majority of my projects but that's turning into an extra job on-top of my already demanding job.
  - thesmallestcat 9y ago
    It sounds like you're already doing a good job of trying to not ship garbage.
  - tjalfi 9y ago
    Here are some of the techniques that I use for C, C++, and C#. Read every checkin twice before committing it. I find and fix many bugs by doing this. Keep a log of errors and problematic APIs. Periodically review your code for methods and idioms that you tend to misuse. I find it easier to spot one incorrect call to an API when looking at all uses of it. Enable all compiler warnings and use warnings as errors. It is easier to spot regressions when the build is normally silent. If a project has a noisy build then use the normal warning level and enable additional warnings over time.
Xeoncross 9y ago
I love the error handling in Go. Every other language I've used led to the inevitable and useless "An error was encountered" message. Go is the first language where I can actually access the original socket permission error because it was actually passed up.
- thesmallestcat 9y ago
  You just described exceptions.
- wyager 9y ago
  > Every other language I've used led to the inevitable and useless "An error was encountered" message. I can't think of a single language except C where this has been a problem for me. What are you referring to?
  - KirinDave 9y ago
    What's weird is that what they're describing is actually really tricky to do reliably in Go unless you totally understand every library beneath you. Much bad can be said about checked exceptions, but they certainly helped with that problem...
- camus2 9y ago
  > Go is the first language where I can actually access the original socket permission error because it was actually passed up. Now try to trace them as easily as exceptions. Oh wait, you can't unless you wrap Go errors into some struct from a library that isn't in the std lib therefore everybody has different systems to trace errors /s i'll take exceptions over this (which go has, panic/defer). error is just a convention, it's not an error system.
  - KirinDave 9y ago
    I'll take Either where I can guarantee I know what I'm dealing with and that it's dealt with rather than the honors system Go offers.
Avshalom 9y ago
>This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes. A certain demographic can't stop waxing erotic about "being in the flow" and so love nothing more than churning out 1000 lines of mindless boilerplate, for this chunk endless if-nil checks are a feature not a bug because it's rote and adds to the line count.

treehau5 9y ago

As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." After a decade of OOP indoctrination and misuse, we see the results of this. > Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible This lends me to believe you actually haven't written any go code for yourself. This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. I came from those languages, and this statement is categorically false and completely unfounded in reality.

KirinDave 9y ago
> After a decade of OOP indoctrination and misuse, we see the results of this. Sure, but that's OO's fault and the lesson is not "abstractions are bad" but rather, "OO's good at domain abstractions and bad at universal abstractions." The takeaway should not be to discard the last 12 years of advances in computer science and call it quits with a bad copy of Erlang's concurrency model and a weak version of C. > This lends me to believe you actually haven't written any go code for yourself. I've written about 5000 lines. So not a ton, but enough to have shipped Go to prod and be capable of reading it. > This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. Go is more OOP-focused with its weak interface{} methodology than anything I promote or have used joyfully in the last 6 years. Even the most cursory examination of my presence will reveal that. Please don't put words in my mouth to tidy your argument.
- deleted 9y ago
  [deleted]
camus2 9y ago
> As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." like writing 500 * if err != nil { return err } is an average Go app? A little yes, but this isn't a little.
- treehau5 9y ago
  like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching. Sorry, the if err != nil horse has been beaten to death already.
  - camus2 9y ago
    > like having your IDE cover the other 100 some-odd places of boiler plate such as writing getters and setters, and implementing comparable and hashCode and every other piece of insanity? What is insane is believing returning errors is actually handling them, it is not, you're just passing the burden on the caller. Second, Go isn't free of all the bullhshit you described so I'm not sure what is your point, that you don't have to write getters and setters in Go? lol, off course you do have to. > Also, I much prefer to handle my errors where they happen in the code rather than do Pokemon try/catching Who cares, go back playing Pokemon since apparently that's the only thing you can think off and stop being an hypocrite. What do you think panics are? yes, it's an half-baked exception system, like everything in Go, a language designed by people who clearly didn't know what they are doing, for people who don't. > Sorry, the if err != nil horse has been beaten to death already Yes, and don't worry, people will keep on beating that horse, because it was designed by people that clearly don't know what they are doing.

thesmallestcat 9y ago

Regarding your last paragraph, it's a reflection of the state of the industry. The vast majority of "software engineers"/"full stack developers" can't be bothered to learn new skills or improve their existing ones, so any popular programming tool is stuck catering to the least common denominator. Do you carefully review your own code? Do you voluntarily learn any new skill beyond "blog post intro tutorial" level? Do you think about the consequences of a change you make beyond the immediate need it addresses? Congratulations: Regardless of talent, you're already better than ~90% of professional programmers. You're a "10x developer" by virtue of the fact that by a reasonable baseline of quality the remainder are "0.1x developers" or worse. I don't think that Google is wrong to focus on mitigating the damage that the majority of engineers will inflict on a codebase. In fact it's depressing how right they are, and what the realities of software engineering look like at scale. It confuses me though that small teams select tools built to solve those problems.

figgis 9y ago
> Do you carefully review your own code? Do you have any resources for getting better at this? I don't get a lot of chances for other people to review what I write (yeah believe me I know..) and am looking into better ways to make sure I don't release shit. I have a decent amount of testing automated for a majority of my projects but that's turning into an extra job on-top of my already demanding job.
- thesmallestcat 9y ago
  It sounds like you're already doing a good job of trying to not ship garbage.
- tjalfi 9y ago
  Here are some of the techniques that I use for C, C++, and C#. Read every checkin twice before committing it. I find and fix many bugs by doing this. Keep a log of errors and problematic APIs. Periodically review your code for methods and idioms that you tend to misuse. I find it easier to spot one incorrect call to an API when looking at all uses of it. Enable all compiler warnings and use warnings as errors. It is easier to spot regressions when the build is normally silent. If a project has a noisy build then use the normal warning level and enable additional warnings over time.

Xeoncross 9y ago

I love the error handling in Go. Every other language I've used led to the inevitable and useless "An error was encountered" message. Go is the first language where I can actually access the original socket permission error because it was actually passed up.

thesmallestcat 9y ago
You just described exceptions.
wyager 9y ago
> Every other language I've used led to the inevitable and useless "An error was encountered" message. I can't think of a single language except C where this has been a problem for me. What are you referring to?
- KirinDave 9y ago
  What's weird is that what they're describing is actually really tricky to do reliably in Go unless you totally understand every library beneath you. Much bad can be said about checked exceptions, but they certainly helped with that problem...
camus2 9y ago
> Go is the first language where I can actually access the original socket permission error because it was actually passed up. Now try to trace them as easily as exceptions. Oh wait, you can't unless you wrap Go errors into some struct from a library that isn't in the std lib therefore everybody has different systems to trace errors /s i'll take exceptions over this (which go has, panic/defer). error is just a convention, it's not an error system.
- KirinDave 9y ago
  I'll take Either where I can guarantee I know what I'm dealing with and that it's dealt with rather than the honors system Go offers.

Avshalom 9y ago

>This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes. A certain demographic can't stop waxing erotic about "being in the flow" and so love nothing more than churning out 1000 lines of mindless boilerplate, for this chunk endless if-nil checks are a feature not a bug because it's rote and adds to the line count.