5 ms·

Are you sure? And what if $programmer forgets to check what's in err? What would pid contain in that case? I mention this because I guess you quoted a kind of

by knocte 12y ago

Are you sure? And what if $programmer forgets to check what's in err? What would pid contain in that case? I mention this because I guess you quoted a kind of syntax that matches the one from Go. So then I'm guessing that Go would simply ignore the error in this case. However, having a proper exception mechanism, if you don't catch the problem, then it bubbles up, and the program doesn't continue with wrong data (which is a good thing => fail fast!). This is the biggest downside of GoLang IMNSHO.

alxnlssn 12y ago
The compile will fail if err is unused. You have to explicitly ignore it by doing like this: pid,_ = fork()
- donatj 12y ago
  And these underscores are really easy to find. Then you just do a git blame and get your shaming on at code review time.
donatj 12y ago
Actually if you want to not handle an error, you have to do either _ = err or just go data, _ = doStuff(), both of which are very visible. You can basically scan your codebase for _'s and find all the unhanded exceptions. If you don't do something with a variable, eg I do myInt := 1 but I don't use myInt go simply refuses to compile.
- acdha 12y ago
  Technically true but most of the [admittededly modest] Go code I've seen had that error punt all over the place. I really wish they'd learned from C and either banned assigning _ for errors or threw a compiler error if the next line wasn't a _ check. On second thought, it'd probably avoid some nasty production failures if that behaviour was true for everything which can return an error.
MichaelGG 12y ago
Yeah, better than returning a tuple, it should return a sum type. Then you would need to deconstruct it, like how people suggest using a switch: match fork() -> | Error(errno) -> ... | Pid(pid) -> ... Or a general "Choice" sum, perhaps using phantom types so int<err> isn't compatible with int<pid>. But then all of a sudden, instead of a single word being returned, a tag and possibly variably-sized result has to be returned, and that's quite a hassle which doesn't fit well with C.
- masklinn 12y ago
  A "Choice" (Either in Haskell, Result in Rust) wouldn't work for fork() as it can have 3 results, and you'd want the `Child` case cleanly and easily separated from `Pid`.
  - mbel 12y ago
    I think the parent meant only a sum type, not a concrete example of it such as Either of Haskell, which would surely not suffice here. In Haskell you would probably define a new sum type for this occasion, e.g.: data ForkResult = Failure | Parent Int | Child

by knocte 12y ago

alxnlssn 12y ago

The compile will fail if err is unused. You have to explicitly ignore it by doing like this: pid,_ = fork()

donatj 12y ago
And these underscores are really easy to find. Then you just do a git blame and get your shaming on at code review time.

donatj 12y ago

Actually if you want to not handle an error, you have to do either _ = err or just go data, _ = doStuff(), both of which are very visible. You can basically scan your codebase for _'s and find all the unhanded exceptions. If you don't do something with a variable, eg I do myInt := 1 but I don't use myInt go simply refuses to compile.

acdha 12y ago
Technically true but most of the [admittededly modest] Go code I've seen had that error punt all over the place. I really wish they'd learned from C and either banned assigning _ for errors or threw a compiler error if the next line wasn't a _ check. On second thought, it'd probably avoid some nasty production failures if that behaviour was true for everything which can return an error.

MichaelGG 12y ago

Yeah, better than returning a tuple, it should return a sum type. Then you would need to deconstruct it, like how people suggest using a switch: match fork() -> | Error(errno) -> ... | Pid(pid) -> ... Or a general "Choice" sum, perhaps using phantom types so int<err> isn't compatible with int<pid>. But then all of a sudden, instead of a single word being returned, a tag and possibly variably-sized result has to be returned, and that's quite a hassle which doesn't fit well with C.

masklinn 12y ago
A "Choice" (Either in Haskell, Result in Rust) wouldn't work for fork() as it can have 3 results, and you'd want the `Child` case cleanly and easily separated from `Pid`.
- mbel 12y ago
  I think the parent meant only a sum type, not a concrete example of it such as Either of Haskell, which would surely not suffice here. In Haskell you would probably define a new sum type for this occasion, e.g.: data ForkResult = Failure | Parent Int | Child