4 ms·
This looks suspiciously like implementing Maybe every time you need to deal with a series of errors.
by modernserf 12y ago
This looks suspiciously like implementing Maybe every time you need to deal with a series of errors.
- tel 12y agoIt's exactly that (well, EitherT Error IO () perhaps) and the pattern would be far easier to replicate if Go had generics. So we're back here. Edit: I wrote an elaboration, https://news.ycombinator.com/item?id=8877732 https://news.ycombinator.com/item?id=8877732
- thomasahle 12y agoYep, I also think that's a good way to think about it. But I don't think implementing that one or two times for an entire program is too bad if it forces you to think error handling into your design.
- inglor 12y agoMaybe and Either constantly show up when people discuss patterns to make error handling less clumsy in languages without exceptions baked in (and in asynchronous contexts in some languages with exceptions) - I just wish posts like this named what they're talking about better - Rob Pike is undoubtedly aware of the names.
- deleted 12y ago[deleted]
- theseoafs 12y agoI would not be so sure Rob Pike knows about Maybe and Either. How would he?
- deleted 12y ago[deleted]
- TheDong 12y agoOh, I dunno, maybe the fact that he designed a programming language which practically proves he must have interest in programming languages. Combine that with the fact that Maybe/Options are neither new nor unusual in language design and fairly heavily discussed and I think it would be practically impossible for him to not have known about them a decade ago. Even failing at that, he would doubtlessly have heard of them since because people discuss them in relation to Go so often. So yeah, that's how he would know about them. They're extremely common in two areas of his interest (Go discussion/criticisms, language design).
- prodigal_erik 12y agoFailing to solve a problem is not evidence that you are familiar with any solutions.
- theseoafs 12y agoGiven that the party line on generics in Go has been "Go doesn't have generics, but since generics are mainly used to implement generic collections, you can just use the built-in collection types for those purposes", I wouldn't be shocked if the designers of the language only had a minimal or cursory understanding of Maybe, Either, and friends. I do not mean this as a dig or an insult, but if Rob Pike is at all familiar with the benefits of Maybe and Either (or sum types in general), then it does not show either in his work or in the talks he's given.
- enneff 12y agoThis is an amazing comment.
- NateDad 12y agoPeople are amazingly able to assume ignorance is the cause of disagreement.
- harryh 12y agoLOL LOL LOL. Very nice dig. A+
- spion 12y agoUnfortunately, its impossible to implement Maybe / Result / Either in Go. Doing that requires generics.
- falcolas 12y agoA generic maybe/result/either? Yes. However the maybe pattern is built into the NullString, NullFloat64, and NullInt64 types in the database/sql package.
- spion 12y agoThat doesn't quite work, as the maybe pattern also implies a chaining operation (flatMap), which is impossible to implement without generics
- falcolas 12y agoYou can still chain, you just have to do type conversion to and from the interface{} type. It's not pretty (and not in broad adoption), but neither is it impossible.
- spion 12y agoThat defeats the point of having a type system (casting is as error prone as forgetting to check errors). Also it doesn't allow for the use of already defined functions to do the transformations, (e.g. `maybe.flatMap(existingFn).flatMap(otherFn)` wont ever work, new closures will have to be defined that do casts before calling the existing functions). So basically, its just-as-error-prone and just-as-tedious as checking error codes but in a different way. Both benefits of the pattern are gone. Given this, I don't think that the word "impossible" is a stretch at all (not having any of the benefits of the pattern = not implementing the pattern)
- lmm 12y agoI guess that's the Go way, copy/paste the same code and change the types to be String, Float64, Int64, .... I'm not sure whether to laugh or cry.
- skybrian 12y agoMaybe is not an error-handling mechanism because it doesn't report any error message. I don't know why Haskell programmers think it's any good for reporting errors. You could use Either, but it doesn't give you any guarantee that you'll get a string back, and the naming is lousy. (Left and Right? Really? I know there's a mnemomic, but we can do better than that.) So, might as write your own ADT and name it right. (Also, a real error-reporting mechanism should support cause chaining so you can see the dependencies; you can sort of do it with string concatenation but it gets awkward after a few levels.)
- deleted 12y ago[deleted]
- codygman 12y ago> You could use Either, but it doesn't give you any guarantee that you'll get a string back 1. It's better not to use strings and instead use a user defined error type. 2. What do you mean "doesn't give you any guarantee you'll get a string back"? > real error-reporting mechanism should support cause chaining so you can see the dependencies; Can you elaborate on cause chaining, perhaps with an example?
- skybrian 12y agoWhat I mean is something like a stack trace except without all the extra detail: - Can't persist shopping cart - RPC request failed: http://example.com/update_cart - Can't write to database "carts" - Can't save file: "/a/b/c" - OS error: disk full Ideally, all errors in the cause chain should be logged, and they typically cross abstraction boundaries; the message at each level comes from a different part of the stack. This seems hard to do across languages, but within a language there should be a standard way to do it. (Go falls down on this too. Perhaps we don't need Java-style stack traces that go on for multiple screens, but we should have more than a string.)
- nbevans 12y agoMaybe is just an example. If you need to return more error codes, perhaps with contextual information such as message(s), then just define your own discriminated union and use that.