Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FP-Go: Functional programming library for Golang

github.com

Post reply on HN
Print view View original

41–50 of 185 posts

Re: FP-Go: Functional programming library for Golang

#43

Post by jpk »

sambeau wrote: post #37

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…

Big Scala vibes here, see also [1].

1: https://github.com/scala/scala/blob/v2.13.11/src/library/sca...

Re: FP-Go: Functional programming library for Golang

#44

Post by Spiwux »

I_am_tiberius wrote: post #35

Was just scrolling through the docs. Does anyone feel comfortable with all these generic type annotations? I'm not expert programmer but this looks overkill to me.

Why, what's wrong with

func TraverseParTuple10[F1 ~func(A1) ReaderIOEither[T1], F2 ~func(A2) ReaderIOEither[T2], F3 ~func(A3) ReaderIOEither[T3], F4 ~func(A4) ReaderIOEither[T4], F5 ~func(A5) ReaderIOEither[T5], F6 ~func(A6) ReaderIOEither[T6], F7 ~func(A7) ReaderIOEither[T7], F8 ~func(A8) ReaderIOEither[T8], F9 ~func(A9) ReaderIOEither[T9], F10 ~func(A10) ReaderIOEither[T10], A1, T1, A2, T2, A3, T3, A4, T4, A5, T5, A6, T6, A7, T7, A8, T8, A9, T9, A10, T10 any](f1 F1, f2 F2, f3 F3, f4 F4, f5 F5, f6 F6, f7 F7, f8 F8, f9 F9, f10 F10) func(T.Tuple10[A1, A2, A3, A4, A5, A6, A7, A8, A9, A10]) ReaderIOEither[T.Tuple10[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]]

(https://pkg.go.dev/github.com/IBM/fp-go/context/readerioeith...)

Re: FP-Go: Functional programming library for Golang

#45

Post by mseepgood »

Spiwux wrote: post #44
I_am_tiberius wrote: post #35

Was just scrolling through the docs. Does anyone feel comfortable with all these generic type annotations? I'm not expert programmer but this looks overkill to me.

Why, what's wrong with func TraverseParTuple10[F1 ~func(A1) ReaderIOEither[T1], F2 ~func(A2) ReaderIOEither[T2], F3 ~func(A3) ReaderIOEither[T3], F4 ~func(A4) ReaderIOEither[T4], F5 ~func(A5) ReaderIOEither[T5], F6 ~func(A6) ReaderIOEither[T6], F7 ~func(A7) ReaderIOEither[T7], F8 ~func(A8) ReaderIOEither[T8], F9 ~func(A9) ReaderIOEither[T9], F10 ~func(A10) ReaderIOEither[T10], A1, T1, A2, T2, A3, T3, A4, T4, A5, T5,…

Wow, this looks like Rust

Re: FP-Go: Functional programming library for Golang

#47

Post by KingOfCoders »

charlieflowers wrote: post #8
KingOfCoders wrote: post #5

I think map() is useful, even if it does not look like Go and rubs a little against the sprit of simplicity of Go. Wish the for loop in Go would return a result, which could accomplish the same but would be a little bit more Go like x := for y := range z { return y } // unclear return :-( If you want Either, use Haskell. There seems also to be a performance problem with map(). It would work better if Go had Iteration…

`Either` works pretty well in Go. I implemented it and it felt reasonably close to Rust/Haskell (without `try!` of course).

I don't think you should bolt every concept into every language. One USP of Go is how dead simple it is to learn and how fast it compiles (because it is dead simple - compare it to Rust compile times). I did a lot of Lisp and Haskell, scaled a startup on FP Scala code and sold it. I did put Option everywhere. In the 2000s I came up with the Iterable hack for Option in Java

   public abstract class Option[T] implements Iterable[T] { }

   // Some then is a one element Iterator/ None is an empty iterator

   // With for you then can do something on Some
   // orElse left as an exercise to the reader
   
   for (String name: option) {
      // do something with name
   }
but today I think one should embrace the language and if it does not work for you, use something else.

For Go I think something like Zigs !i32 would fit in perhaps, if one wants a higher level of error handling.

Re: FP-Go: Functional programming library for Golang

#48

Post by truth_seeker »

This library could be only useful if someone trying to build new Programming Language with its own ecosystem with Golang runtime as backend, like for example Scala on JVM. In upcoming versions Go 1.22 they are also improving code inlining support, so that might help.

Trying to merge this abstractions and patterns with existing Golang's philosophy and community libraries is simply a case of over-engineering.

Re: FP-Go: Functional programming library for Golang

#49

Post by mc10 »

dveeden2 wrote: post #40
AYBABTME wrote: post #9

The long README needs some usage examples.

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 statement. Also, the passing two values in parallel via a chain of functions seems really brittle.

Re: FP-Go: Functional programming library for Golang

#50

Post by sambeau »

I don’t know who to feel more sorry for: the junior programmer who has dutifully taught themselves idiomatic go and explicit error handling being shown a large unreadable codebase full of this nonsense on their first day, or the the poor sods having to tear this nonsense out of a large tangled codebase in three years time.
Post reply on HN