This looks like a pain to modify if you're not intimately familiar with the fp-go library and are just trying to insert a debug statement. Also, the passing two values in parallel via a chain of functions seems really brittle.
The real cheat of examples like this is using only existing functions. Once you add a closure with current Go syntax it goes to 11 on the hideous.
There's some chat about adding some variant of (x, y => z) to Go, though even then you're adding some more symbols to an already symbol-heavy structure and it looks even worse when you're not using x y z but (username, accountId => a few lines of username and accountId being used).
I agree that the code will become unreadable as soon as you try to use inline functions (since there are no lambda expressions).
However, the fp style (independent of this library) encourages to decompose the codebase into small and - if possible - pure functions. For testability.
Once the code is structured that way, it's no longer a `cheat`, these pure functions can be used right away in function composition to create more complex structures.
It is very probable that data is an Either[Error, Result]. So you are forced to handle the error.
You could also probably add a mapLeft and deal with an error at every step of computation.
Given the way fp-ts work, this library should be very type safe.
But of course, all of this looks much prettier and less verbose in haskell
The example actually does handle all errors, because the values are of type `Either` and the composition functions take this into account.
If you would like to handle a particular error sitation explicitly, e.g. to enrich it with context or to transform one error into another, you may use `MapLeft` or `Swap`.
Unfortunately there is no way to use variadic arguments in a type safe way in go (yet) - except for the special case that all arguments are of the same type.
This is why some of the functions that work with many arguments (such as `Pipe`, `Flow`, `Traverse` ...) carry their cardinality as a suffix. Their shapes are then auto-generated up to a max cardinality that seems to make sense in practice.
So the traverse tuple function does not only exist for cardinality 2 but also for higher ones. But unfortunately you have to specify it explicitly.
It feels like they buried the lede, because the referenced Go code is horrendous. I'd be afraid to put that on the front page of my repo, too, if my library lead to code that reads/looks like that.