101–110 of 185 posts
I’m sorry, but this is just awful. func TraverseTuple10[F1 ~func(A1) IOEither[E, T1], F2 ~func(A2) IOEither[E, T2], F3 ~func(A3) IOEither[E, T3], F4 ~func(A4) IOEither[E, T4], F5 ~func(A5) IOEither[E, T5], F6 ~func(A6) IOEither[E, T6], F7 ~func(A7) IOEither[E, T7], F8 ~func(A8) IOEither[E, T8], F9 ~func(A9) IOEither[E, T9], F10 ~func(A10) IOEither[E, T10], E, A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, T1, T2, T3, T4, T…
IBM as fuck.
Earlier quoted context omitted.
Can you share some examples? I personally haven't found any excuses to use generics yet, so I'm curious where other people are finding them useful
Here is an example in the standard library: https://pkg.go.dev/slices
Earlier quoted context omitted.
As a Rust guy, I disagree. For one, Rust does not have lazy evaluation, just like C which is why I raised the point C is incompatible with FPP. Lazy evaluation in C (and Rust) can be emulated by function pointers (and closures), but it is not easy to use
> Rust does not have lazy evaluation Does one need lazy evaluation to be FP? Scheme isn't lazy to my knowledge.
> very important senior grug say "this too complicated and confuse to me" https://grugbrain.dev
> If your pure function can return an error, then it will have a (T, error) return value in idiomatic go. In functional style the return value is Either[error, T] because function composition is easier with such a return type. This seems flawed. In idiomatic Go, T and error are always independently observable. The Either monad implies that they are dependent, which is not true.
Earlier quoted context omitted.
Here is an example in the standard library: https://pkg.go.dev/slices
I've used the slices package and I agree it's useful. I was wondering more about generics use in application code
I also like using generics for API request/response code, ex: https://go.dev/play/p/OWf9eFmg1qF
With generics you don't need to return any/interface{} / type assert at runtime
This is a tour de force, and it accomplishes the goal of enabling FP using the Go syntax and toolchain. But code written using this library is no longer Go: most Go programmers can't grok it, and it's awkward to call normal Go libraries because there's no way to know if that function you're calling is pure. If your goal is to "make it easy and fun to write maintainable and testable code in golang" by making pure func…
I believe these things are mostly productivity sinks, which is why I am such a Go fan and also so sad to see these types of projects in Go. This is exactly what I was afraid of when generics were introduced, and now I get to spend time arguing with people who read some blog post about how functional programming and type theory will save the world, instead of actually being productive. Ugh.
Earlier quoted context omitted.
True, however the README does link to this: https://github.com/IBM/fp-go/tree/main/samples
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")), ) 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 statemen…
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).
Adding generics to go was a mistake
Indeed, this was the exact stuff that I loved not having to deal with in Go: architecture astronauts pushing their code golf on everyone else. I’m quite sad to see this project as it demonstrates that Go is starting to lose many of the characteristics that attracted me to it in the first place. (For some context, I know quite a bit about functional programming and formal type theory, having studied the latter in grad…
I'd love to be able to survey the authors of the dozen-ish variations on this posted over the last couple of years (most of the much less elaborate than this) and see how many of them are still using it in their real code. Again I'm sure the answer isn't literally zero but I bet it's statistically-significantly fewer than all of them.
The long README needs some usage examples.
True, however the README does link to this: https://github.com/IBM/fp-go/tree/main/samples