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.