4 ms·

I think I just realized something about golang as I was walking down the hall. This is something which confuses many people in a way which many respond to with

I think I just realized something about golang as I was walking down the hall. This is something which confuses many people in a way which many respond to with unwarranted emotion, since they are unable to make this connection. Since Go uses Duck Typing, having certain methods is effectively a Type Annotation for a given type implementing an Interface. Many programmers, failing to realize this, become outraged at "boilerplate." It is a design trade-off forcing the programmer to specify all cases when implementing an interface, in much the same way that golang's exception handling eschews tools that let you create clever catch-alls and requires you to specify everything. It's just the "no magic" tradeoff.

jfoutz 8y ago
> requires you to specify everything That's not my experience. checking for errors is completely optional. I'm probably just a bad lazy programmer that leans to hard on the compiler. I like the catch everything and then refine error handling as i get more understanding of failure modes (i'm from java, i avoid runtimeexception). Go makes me feel like i need to understand all possible error cases for every line as i type it. I feel like i have to handle it right now, forever, or i'll forget that line can have an error. I really miss being able to gradually refine error handling, because i can rely on the compiler to remind me about all the stuff that can go wrong.
- mdanger007 8y ago
  You can throw away errors, by assigning errors or panic with Must. But a goru said, Why not log everything? Must(func()(val, err)) -> LogIf(func()(val, err))
  - dagss 8y ago
    ...that would be nice except you need to reimplement LogIf or Must again for every single function signature due to lack of metaprogramming..
- sagichmal 8y ago
  Indeed, Go's position is that your style of programming produces fragile programs, and that it is better to consider the failure modes of each expression as you type it, rather than afterwards.
  - twiceaday 8y ago
    This is the position of the Google c++ style guide, from which I think Go borrowed heavily.
  - jfoutz 8y ago
    Seems like breadth first vs depth first search. They will converge at the same answer. Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced. This is really insightful, thank you.
    - sagichmal 8y ago
      > Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.
  - erik_seaberg 8y ago
    if err != nil { return nil, err } is ceremony that requires no thought and adds no value. There should be sugar for this so it doesn't completely swamp the tiny minority of cases that actually do something.
    - sacado2 8y ago
      I actually rarely type that very snippet. In like 3/4 of the cases, I make the error more specific, like if err != nil { return nil, fmt.Errorf("could not parse file %s: %v", path, err) } the remainder being either the snippet you put above or more complex error management.
- dilap 8y ago
  it's a real trade-off. i think for more interactive software, a "fuck it and throw an exception" approach can be reasonable. for server software it's death. (you need to service the request to the best of your ability, and make sure that you are handling any failures in the best possible way.)
  - bigato 8y ago
    > i think for more interactive software, a "fuck it and throw an exception" approach can be reasonable. Your users probably don't think so
    - dilap 8y ago
      it can be not-so-bad, because it's something like, "oh, i passed in the wrong file" or "oh, that menu item is broken" or something like that. you as a user are entirely in control of the inputs & the state is usually just a file or two, so it's easy to just try again until things work. but for something running on a server somewhere, many inputs are beyond the user's control & the state is long-lived and fragile (if my HN or FB account gets somehow b0rked, that's a serious problem for me), so it's important to handle all possible error conditions in the best possible way. in my experience this is something exceptions make very hard to do. (& i would still prefer explicit error handling even for front-end software, but i think the argument for exceptions is at least stronger there.)
- sacado2 8y ago
  Then just `panic` first on all errors, and correct it as you go on. This is not really the advised practice, but if it works for you...
deckarep 8y ago
Go uses structured typing as described by Rob Pike. Duck typing can still lead to runtime errors which is practically all accounted for thanks to the compile-time safety of structured typing.
- dilap 8y ago
  duck typing is an informal term, no? i think it's fair to think of structural typing as "compile time duck typing".
  - msiggy 8y ago
    don't think so
    - stcredzero 8y ago
      It's what I meant.
fbonetti 8y ago
The term you’re looking for is “type inference”, where the compiler determines the type of a variable automatically at compile time.
- ychen306 8y ago
  I think he's referring to not having to explicitly declare if some type implements any interfaces.

jfoutz 8y ago

> requires you to specify everything That's not my experience. checking for errors is completely optional. I'm probably just a bad lazy programmer that leans to hard on the compiler. I like the catch everything and then refine error handling as i get more understanding of failure modes (i'm from java, i avoid runtimeexception). Go makes me feel like i need to understand all possible error cases for every line as i type it. I feel like i have to handle it right now, forever, or i'll forget that line can have an error. I really miss being able to gradually refine error handling, because i can rely on the compiler to remind me about all the stuff that can go wrong.

mdanger007 8y ago
You can throw away errors, by assigning errors or panic with Must. But a goru said, Why not log everything? Must(func()(val, err)) -> LogIf(func()(val, err))
- dagss 8y ago
  ...that would be nice except you need to reimplement LogIf or Must again for every single function signature due to lack of metaprogramming..
sagichmal 8y ago
Indeed, Go's position is that your style of programming produces fragile programs, and that it is better to consider the failure modes of each expression as you type it, rather than afterwards.
- twiceaday 8y ago
  This is the position of the Google c++ style guide, from which I think Go borrowed heavily.
- jfoutz 8y ago
  Seems like breadth first vs depth first search. They will converge at the same answer. Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced. This is really insightful, thank you.
  - sagichmal 8y ago
    > Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.
- erik_seaberg 8y ago
  if err != nil { return nil, err } is ceremony that requires no thought and adds no value. There should be sugar for this so it doesn't completely swamp the tiny minority of cases that actually do something.
  - sacado2 8y ago
    I actually rarely type that very snippet. In like 3/4 of the cases, I make the error more specific, like if err != nil { return nil, fmt.Errorf("could not parse file %s: %v", path, err) } the remainder being either the snippet you put above or more complex error management.
dilap 8y ago
it's a real trade-off. i think for more interactive software, a "fuck it and throw an exception" approach can be reasonable. for server software it's death. (you need to service the request to the best of your ability, and make sure that you are handling any failures in the best possible way.)
- bigato 8y ago
  > i think for more interactive software, a "fuck it and throw an exception" approach can be reasonable. Your users probably don't think so
  - dilap 8y ago
    it can be not-so-bad, because it's something like, "oh, i passed in the wrong file" or "oh, that menu item is broken" or something like that. you as a user are entirely in control of the inputs & the state is usually just a file or two, so it's easy to just try again until things work. but for something running on a server somewhere, many inputs are beyond the user's control & the state is long-lived and fragile (if my HN or FB account gets somehow b0rked, that's a serious problem for me), so it's important to handle all possible error conditions in the best possible way. in my experience this is something exceptions make very hard to do. (& i would still prefer explicit error handling even for front-end software, but i think the argument for exceptions is at least stronger there.)
sacado2 8y ago
Then just `panic` first on all errors, and correct it as you go on. This is not really the advised practice, but if it works for you...

deckarep 8y ago

Go uses structured typing as described by Rob Pike. Duck typing can still lead to runtime errors which is practically all accounted for thanks to the compile-time safety of structured typing.

dilap 8y ago
duck typing is an informal term, no? i think it's fair to think of structural typing as "compile time duck typing".
- msiggy 8y ago
  don't think so
  - stcredzero 8y ago
    It's what I meant.

fbonetti 8y ago

The term you’re looking for is “type inference”, where the compiler determines the type of a variable automatically at compile time.

ychen306 8y ago
I think he's referring to not having to explicitly declare if some type implements any interfaces.