7 ms·

I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using

I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.

bsaul 12y ago
this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.
- brian_herman 12y ago
  I think small is a good thing in languages for example the C programming language is very simple in the language but very powerful. Simplify Simplify Simplify.
  - pjmlp 12y ago
    Not that much if you leave out compiler specific extensions not part of ANSI C and library functions that are actually implemented in Assembly.
  - aikah 12y ago
    > Simplify Simplify Simplify. Yet C programmers use shitloads of macros to make up for C lack of features.
- mratzloff 12y ago
  If you have only worked in languages with exceptions, it's not surprising that you would struggle with Go's C-style error handling. I've grown to prefer it, as exception handling typically boils down to "not my problem" in most code bases. Go forces you to think through each error condition, which is an unusual amount of effort for people who may not be accustomed to it.
  - zimbatm 12y ago
    Go's error handling works well in small programs but there's a couple of issues. One is that it quickly becomes hard to find out where errors really came from. Consider this idiomatic code: func MyFunc(input int) (output int, err error) { if output, err = someOtherFuncA(input); err != nil { return } if output, err = someOtherFuncB(output); err != nil { return } // ... } If MyFunc returns an error it's not possible to know where it came from unless you know all about someOtherFuncA and someOtherFuncB and they return different kind of errors. What's missing from the stdlib is a utility that wraps errors to reproduce what's essentially a backtrace. `return wrapError("someOtherFuncA", err)` The other issue is that (error) doesn't tell you what kind of errors are going to be returned. It's often useful to be able to classify errors as to respond to them accordingly. IO errors might be retryable but data-structure errors might be not. In the stdlib they use value comparison as a trick to classify errors combined with documentation of what exactly will be returned.
    - gizzlon 12y ago
      Think the point i to handle errors wherever they're best handled. Sometimes that means returning it and sometimes it means handling it right away. I've written code with this style of error-handling in Perl 5, and I think it works quite well. I like having "custom" error-handling that fits the style and the purpose of that particular program, instead of trying to to fit a general pattern onto all programs. It also means you can start out with something very crude, and improve it as you go along and learn more about the failure modes etc.
    - NateDad 12y ago
      That's not really idiomatic. You should be adding context to the error you return, or a new error.
      - lclarkmichalek 12y ago
        Given its prevalence all across Go code, are you _sure_ it's not idiomatic? Hell, look at the presentation in the link: http://talks.golang.org/2014/readability.slide#11 http://talks.golang.org/2014/readability.slide#11. If the oracle of idioms does not write idiomatic code, then wtf is idiomatic code?
myg204 12y ago
> I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). C++11 and C++14 also have a lot of idiomatic discussion since the community's trying to move to a different style with the latest enhancements. Not sure if this is a signal of core issues.
- steveklabnik 12y ago
  We Ruby programmers also obsess over style, especially with regards to tests. There's even a full, printed book about it: "Eloquent Ruby."
  - Tomte 12y ago
    An exceptionally well written book, I'd like to add. Many authors try to unite casual style with technical writing. Russ Olsen does it beautifully. He never treats you as a child or an idiot. He never lets you feel his master status. He's like the good-natured old-timer who sits next to you with a cup of coffee, teaching you more than you realize.
- userbinator 12y ago
  Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). I wonder what an appropriate adjective could be for idiomatic Go code. Gonic? Gonian?
  - thrill 12y ago
    Gonic - causing a desired reaction - might work, though I suppose any correct code would fit that definition. I sort of like gothic - always recognizable, consistent, big.
  - jmnicolas 12y ago
    How about Gothic ?
  - NateDad 12y ago
StevePerkins 12y ago
Heh... I had a similar thought back when I was using Python. In both cases, I don't think it's a matter of the language "fighting" you. You can write Go however you like, so long as it compiles and runs. However, it IS a matter of people on the Internet mocking you for not being "pythonic".
eternalban 12y ago
You must, truly, channel the minds from planet 9 to enjoy the experience of Go. (This statement is not considered 'polite' in certain circles, but darn it, I can't help myself ;) That said, I've tried channeling Rob and it is an interesting and informative experience ..
skrebbel 12y ago
I think that's a good thing. If Scala had a better commonly accepted idea of what's "idiomatic Scala", then maybe the "there's more than 6497492 ways to do it" stigma that Scala's recently gotten might've been avoided. You need discussion about what's considered "good" before you can arrive at a relatively common opinion about that.
mostafah 12y ago
Or, it could be a result of Go making use of some novel approaches that a lot of programmers are not used to.
- frowaway001 12y ago
  No, certainly not.
wwweston 12y ago
Don't forget the constant reminder that leaving <language feature X> out is just simplicity, even if it means you're writing a lot of if statements and extra code.

bsaul 12y ago

this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.

brian_herman 12y ago
I think small is a good thing in languages for example the C programming language is very simple in the language but very powerful. Simplify Simplify Simplify.
- pjmlp 12y ago
  Not that much if you leave out compiler specific extensions not part of ANSI C and library functions that are actually implemented in Assembly.
- aikah 12y ago
  > Simplify Simplify Simplify. Yet C programmers use shitloads of macros to make up for C lack of features.
mratzloff 12y ago
If you have only worked in languages with exceptions, it's not surprising that you would struggle with Go's C-style error handling. I've grown to prefer it, as exception handling typically boils down to "not my problem" in most code bases. Go forces you to think through each error condition, which is an unusual amount of effort for people who may not be accustomed to it.
- zimbatm 12y ago
  Go's error handling works well in small programs but there's a couple of issues. One is that it quickly becomes hard to find out where errors really came from. Consider this idiomatic code: func MyFunc(input int) (output int, err error) { if output, err = someOtherFuncA(input); err != nil { return } if output, err = someOtherFuncB(output); err != nil { return } // ... } If MyFunc returns an error it's not possible to know where it came from unless you know all about someOtherFuncA and someOtherFuncB and they return different kind of errors. What's missing from the stdlib is a utility that wraps errors to reproduce what's essentially a backtrace. `return wrapError("someOtherFuncA", err)` The other issue is that (error) doesn't tell you what kind of errors are going to be returned. It's often useful to be able to classify errors as to respond to them accordingly. IO errors might be retryable but data-structure errors might be not. In the stdlib they use value comparison as a trick to classify errors combined with documentation of what exactly will be returned.
  - gizzlon 12y ago
    Think the point i to handle errors wherever they're best handled. Sometimes that means returning it and sometimes it means handling it right away. I've written code with this style of error-handling in Perl 5, and I think it works quite well. I like having "custom" error-handling that fits the style and the purpose of that particular program, instead of trying to to fit a general pattern onto all programs. It also means you can start out with something very crude, and improve it as you go along and learn more about the failure modes etc.
  - NateDad 12y ago
    That's not really idiomatic. You should be adding context to the error you return, or a new error.
    - lclarkmichalek 12y ago
      Given its prevalence all across Go code, are you _sure_ it's not idiomatic? Hell, look at the presentation in the link: http://talks.golang.org/2014/readability.slide#11 http://talks.golang.org/2014/readability.slide#11. If the oracle of idioms does not write idiomatic code, then wtf is idiomatic code?

myg204 12y ago

> I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). C++11 and C++14 also have a lot of idiomatic discussion since the community's trying to move to a different style with the latest enhancements. Not sure if this is a signal of core issues.

steveklabnik 12y ago
We Ruby programmers also obsess over style, especially with regards to tests. There's even a full, printed book about it: "Eloquent Ruby."
- Tomte 12y ago
  An exceptionally well written book, I'd like to add. Many authors try to unite casual style with technical writing. Russ Olsen does it beautifully. He never treats you as a child or an idiot. He never lets you feel his master status. He's like the good-natured old-timer who sits next to you with a cup of coffee, teaching you more than you realize.
userbinator 12y ago
Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). I wonder what an appropriate adjective could be for idiomatic Go code. Gonic? Gonian?
- thrill 12y ago
  Gonic - causing a desired reaction - might work, though I suppose any correct code would fit that definition. I sort of like gothic - always recognizable, consistent, big.
- jmnicolas 12y ago
  How about Gothic ?
- NateDad 12y ago

StevePerkins 12y ago

Heh... I had a similar thought back when I was using Python. In both cases, I don't think it's a matter of the language "fighting" you. You can write Go however you like, so long as it compiles and runs. However, it IS a matter of people on the Internet mocking you for not being "pythonic".

eternalban 12y ago

You must, truly, channel the minds from planet 9 to enjoy the experience of Go. (This statement is not considered 'polite' in certain circles, but darn it, I can't help myself ;) That said, I've tried channeling Rob and it is an interesting and informative experience ..

skrebbel 12y ago

I think that's a good thing. If Scala had a better commonly accepted idea of what's "idiomatic Scala", then maybe the "there's more than 6497492 ways to do it" stigma that Scala's recently gotten might've been avoided. You need discussion about what's considered "good" before you can arrive at a relatively common opinion about that.

mostafah 12y ago

Or, it could be a result of Go making use of some novel approaches that a lot of programmers are not used to.

frowaway001 12y ago
No, certainly not.

wwweston 12y ago

Don't forget the constant reminder that leaving <language feature X> out is just simplicity, even if it means you're writing a lot of if statements and extra code.