[38]

oh my, its horrible:

    client := H.MakeClient(HTTP.DefaultClient)
    readSinglePost := H.ReadJson[PostItem](client)
    readSingleCatFact := H.ReadJson[CatFact](client)
    
    data := F.Pipe3(
      T.MakeTuple2("https://jsonplaceholder.typicode.com/posts/1", "https://catfact.ninja/fact"),
      T.Map2(H.MakeGetRequest, H.MakeGetRequest),
      R.TraverseTuple2(
         readSinglePost,
         readSingleCatFact,
      ),
      R.ChainFirstIOK(IO.Logf[T.Tuple2[PostItem, CatFact]]("Log Result: %v")),
    )
    
    result := data(context.Background())
    fmt.Println(result())

https://github.com/IBM/fp-go/blob/main/samples/http/http_tes...

[lenkite]

Actually, this sample is pretty easily followed and readable to anyone familiar with iterators, tuples, filter, map and transduction. Sure the stuff like Pipe3/Map2 is irritating because Go doesn't have function overloading.

Now, try and do the equivalent in "normal" Go code - it will be 3x-5x the lines of code. (Probably more)

[38]

it has no error handling. also look at the API, what a joke:

https://godocs.io/github.com/IBM/fp-go/function

and check out the "constants":

https://godocs.io/github.com/IBM/fp-go/function#pkg-variable...

[vjerancrnjak]

This library is almost a copy of fp-ts library (TypeScript).

You are forced to handle errors. The result is almost certainly an Either[Error, Result].

fp-ts in TypeScript is not syntactically nice but it feels simple enough that after a week you can be pretty comfortable with it. Although, TypeScript compiler might be much better at inferring types than Go. My experience with fp-ts is that most of the time I do not have to write any type annotations except the top level ones.

The API looks fine, you will find similar type annotations in fp-ts and in Haskell, that's just how handling variadics works in most languages and for useful abstractions like traverse/map/chain you need to have the variadic ones available to avoid having to deal with arrays of anonymous functions (that might all need to have the same type).

When you spend a significant time writing fp-ts you barely look at the types. The experience of writing the code is smooth. Code written still has similar pitfalls as regular imperative programming, pyramids of doom, readability, most of the functions "annotated" with async but they are pure or can be pure if you order the data better etc.

I would say there is friction in the beginning, but as time passes, the brain learns how to parse the code. The effect felt very similar to me when I shifted from colored syntax to just plain black on white. After some point brain does its magic.

[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.