1424
Golang be like
(i.imgur.com)
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
People are scared of monads and think this is better.
My brain is too smooth to imagine a solution to this using monads. Mind sharing what you got with the class?
Having a
Result[T, Err]
monad that could represent either the data from a successful operation or an error. This can be generalised to theEither[A, B]
monad too.Wait, that's all monads are? some generic class
?
Nope. Monads enable you to redefine how statements work.
Let's say you have a program and use an Error[T] data type which can either be Ok {Value: T} or Error:
Each statement has the following form:
You first evaluate the "expr" part and bind/store the result in variable a, and evaluate the "rest" of the program.
You could represent the same thing using an anonymous function you evaluate right away:
In a normal statement you just pass the result of "expr" to the function directly. The monad allows you to redefine that part.
You instead write:
Here "bind" redefines how the result of expr is passed to the anonymous function.
If you implement bind as:
Then you get normal statements.
If you implement bind as:
You get statements with error handling.
So in an above example if the result of foo() is Error, the result of the statement is Error and the rest of the program is not evaluated. Otherwise, if the result of foo() is Ok {Value = 3}, you pass 3 to the rest of the program and you get a final result Ok {Value = 4}.
So the whole idea is that you hide the if Error part by redefining how the statements are interpreted.
"Some generic class" with specific methods and laws, Monads are an algebraic structure and you want those laws included same as if you enable some type to use
+
you want to have a0
somewhere andx + 0 == x
to hold. Like"foo" + "" == "foo"
in the case of strings, just as an example.In Rust,
Result
andOption
actually are monads. Let's takeOption
as example:pure x
isSome(x)
a >>= b
isa.and_then(b)
Then we have:
Some(x).and_then(f)
≡f(x)
x.and_then(Some)
≡x
m.and_then(g).and_then(h)
≡m.and_then(|x| g(x).and_then(h))
Why those laws? Because following them avoids surprises like
x + 0 /= x
.Rust's type system isn't powerful enough to have a Monad trait (lack of HKTs) hence why you can't write code that works with any type that implements that kind of interface.
Result
names>>=
and_then
, just likeOption
does so the code reads the same but you'll have to choose betweenOption
orResult
in the type signature, the code can't be properly generic over it.This is the best explanation I've ever seen of monads: https://www.adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
For some reason, you'll find a lot of really bad explanations of monads, like "programmable semi-colons". Ignore those, and check out the link.
Someone else and not an expert. But Maybe types are implemented with Monads, Maybe is a common monad.
Its how rust does error handling for example, you have to test a return value for "something or nothing" but you can pass the monadic value and handle the error later, in go you have to handle the error explicitly (almost) all the time.
Here's an example (first in Haskell then in Go), lets say you have some types/functions:
then you can make
for some reason <- in lemmy shows up as
<-
inside code blocks, so I used the left arrow unicode in the above insteadin Go you'd have these
Possible
type alias, Go can't do generic type aliases yet, there's an open issue for it)and with them you'd make:
In the Haskell, the fact that
Either
is a monad is saving you from a lot of boilerplate. You don't have to explicitly handle theLeft
/error case, if any of theEither
s end up being aLeft
value then it'll correctly "short-circuit" and the function will evaluate to thatLeft
value.Without using the fact that it's a functor/monad (e.g you have no access to fmap/>>=/do syntax), you'd end up with code that has a similar amount of boilerplate to the Go code (notice we have to handle each
Left
case now):Swift and Rust have a far more elegant solution. Swift has a pseudo throw / try-catch, while Rust has a Result<> and if you want to throw it up the chain you can use a ? notation instead of cluttering the code with error checking.
The exception handling question mark, spelled
?
and abbreviated and pronouncedeh?
, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can't dofoo()?.bar()?.baz()?
in Haskell so it's only theoretical purity which is half-arsed, not ergonomics.Note: Lemmy code blocks don't play nice with some symbols, specifically < and & in the following code examples
This isn't a language level issue really though, Haskell can be equally ergonomic.
The weird thing about
?.
is that it's actually overloaded, it can mean:A?
that returnsB?
A?
that returnsB
you'd end up with
B?
in either caseSay you have these functions
and you want to construct the following using these 3 functions
in a Rust-type syntax, you'd call
in Haskell you'd have two different operators here
however you can define this type class
and then get roughly the same syntax as rust without introducing a new language feature
though this is more general than just
Maybe
s (it works with any functor/monad), and maybe you wouldn't want it to be. In that case you'd do thisrestricting it to only maybes could also theoretically help type inference.
I was thinking along the lines of "you can't easily get at the wrapped type". To get at
b
instead ofMaybe b
you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they're awkward in a monadic context) whereas Rust will gladly hand you thatb
in the middle of an expression, and doesn't force you to name the point.Or to give a concrete example,
if foo()? {...}
is rather awkward in Haskell, you end up writing things like, though of course baz is completely generic and can be factored out. I think I called it "cap" in my Haskell days, for "consequent-alternative-predicate".
Flattening Functors and Monads syntax-wise is neat but it's not getting you all the way. But it's the Haskell way: Instead of macros, use tons upon tons of trivial functions :)
It's not a half-arsed copy, it's borrowing a limited subset of HKT for a language with very different goals. Haskell can afford a lot of luxuries that Rust can't.
It's a specialised syntax transformation that has nothing to do with HKTs, or the type system in general. Also HKTs aren't off the table it's just that their theory isn't exactly trivial in face of the rest of Rust's type system but we already have GATs.
It actually wouldn't be hard writing a macro implementing do-notation that desugars to
and_then
calls on a particular type to get some kind of generic code (though of course monomorphised), but of course that would be circumventing the type system.Anyhow my point stands that how Rust currently does it is imitating all that Haskell goodness on a practical everyday coding level but without having (yet) to solve the hard problem of how to do it without special-cased syntax sugar. With proper monads we e.g. wouldn't need to have separate syntax for
async
and?
You can say it's half-arsed if you like, but it's still vastly more convenient to write than if err != nil all over the place
Can anybody explain the rationale behind this?
Exceptions don't exists and ask errors must be handled at every level. It's infuriating.
I actually kind of like the error handling. Code should explain why something was a problem, not just where it was a problem. You get a huge string of "couldn't foobar the baz: target baz was not greebleable: no greeble provider named fizzbuzz", and while the strings are long as hell they are much better explanations for a problem than a stack trace is.
Hahaha, fuck no, I've dealt with exception-less code enough in my life, kthxbye
I think you missed a memo. Exceptions are bad and errors as values are in… I’ll have Harold forward it to you
The language was designed to be as simple as possible, as to not confuse the developers at Google. I know this sounds like something I made up in bad faith, but it's really not.
The infamous
if err != nil
blocks are a consequence of building the language around tuples (as opposed to, say, sum types like in Rust) and treating errors as values like in C. Rob Pike attempts to explain why it's not a big deal here.a desperate fear of modular code that provides sound and safe abstractions over common patterns. that the language failed to learn from Java and was eventually forced to add generics anyway - a lesson from 2004 - says everything worth saying about the language.
btw lua handles error in exactly the same way