[cleue]

1) I would argue that with fp style you might want to structure your code into small, pure functions, anyway, for testability reasons. Also many functions from the go library are already pure functions with one input and one output, so they can be used right way, e.g. `Atoi` from `strcov` or `ToUpper` from `strings`. Also go has the nice feature that you can pass methods on structs (member functions) from their instance as functions (the instance reference is bound in a closure). So lambda functions are not really needed that much

2) I absolutely agree, type inference could be better. However this has improved over time and go1.21 has also made good progress. I would expect that type inference will continue to improve in the future. This library tries to easy the pain of having to specify types redundantly by carefully choosing the order of type parameters. Those parameters that can be inferred (e.g. because they are part of the immediate function argument) come last, whereas the parameters that cannot be inferred come first, so you only have to specify those. This compromizes on a consistent type ordering, preferring useability over (internal) consistency. Examples are `Left` and `Right` of the `either` package. The order of type parameters is reversed between the two to avoid excessibe typing.