Re:The Human Side of Elixir
by karmakaze on Wednesday July 28, 2021 @06:52PM
(#27990786)
My OO definitely has a much more functional feel to it. Pretty much use OO to connect the parts so that the functions are connected from inputs through to outputs in a pipeline-y way. Monadic data, aspects, and error handling is also commonplace. I recently figured out that I can chain (value, error) in Go with different value types and not deal with input x output explosion of flatmappers--trick is to bind with closures to make zero-arg functions so only the output type varies.
[ Parent
| on HN ]
Sounds interesting, can you share a snippet?
I assume you mean the Go part. I meant to write a mini-blog post but can summarize here. Lets say we want to use an Either<ok, error> and chain computations. In Go naively without generics this needs the product no-of-input-types x no-of-output-types forms of result mappers/chainers. Instead we make functions that bind all it's inputs so only has an output-type. Now we only need linearly as many mappers/chainers (and_then's). e.g.
x, err := computeAThing(1, 1)
y, err := and_then.Int(err, makeComputeAThingFn(x, 1))
z, err := and_then.Int(err, makeComputeAthingFn(x, y))
another, err := and_then.AnotherType(err, makeComputeAnotherTypeFn(z))
where makeComputeAThingFn(...) returns a function with the body `return computeAThing(...)`. `err` will end up with the first non-nil error and the following and_then.X's will be no-ops.