[lenkite]

It actually does have error handling. It uses a Result type

    type ReaderIOEither[A any] RE.ReaderIOEither[context.Context, error, A]

In fact the test code you linked actually even does a check on the result:

   assert.Equal(t, E.Of[error](count), result())

In order to avoid all those excessive functions and 'silly' constants, Go needs to support const and variadic generics like C++ does. Then the API would become quite clean.

I am not supporting the use of this library in prod code used in a large team - but its OK for small tools where one needs to iterate quickly. Folks familiar with FP constructs (esp users of fp-ts) would follow this code almost immediately. Basically the dirtiness and pain (most of it) has been encapsulated into the library.

[38]

> In order to avoid all those excessive functions and 'silly' constants, Go needs to support const and variadic generics like C++ does.

oh yes, lets look to C++ as a shining example. lets please not ruin another language by bolting on functional programming. if you want functional programming, use a functional language.

If you want to use Go, just use a for loop like everyone else.