Live data from Hacker News

FP-Go: Functional programming library for Golang

github.com

81–90 of 185 posts

Re: FP-Go: Functional programming library for Golang

#81
post #62
post #49

Earlier quoted context omitted.

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…

And, after all that, they don’t even handle the IO errors.

It is very probable that data is an Either[Error, Result]. So you are forced to handle the error. You could also probably add a mapLeft and deal with an error at every step of computation.

Given the way fp-ts work, this library should be very type safe.

But of course, all of this looks much prettier and less verbose in haskell

Re: FP-Go: Functional programming library for Golang

#82

Love expression-oriented pseudo-FP (F#, Scala, Rust), but I think this recent trend of trying to shoehorn Haskell-lite features into mainstream imperative languages is, to put it gently, extremely awkward. That said, I actually do remember my first exposure to Golang being a blog post about using monads to avoid incessantly typing `if err != nil`. Very much like that original author, my personal values in software en…

totally agree, for me golang is a strongly imperative language and that's ok. I'm willing to be proved wrong, but I would imagine if you want to do functional programming it's going to be a lot easier to just use a different language.

Re: FP-Go: Functional programming library for Golang

#86

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…

Feels like the spirit of Scala reborn.

Re: FP-Go: Functional programming library for Golang

#87
post #73

Adding generics to go was a mistake

I've ended up using at least a half dozen generic helpers in every application I've written since they were added. They've made my coding easier, more concise, and help with testing. Adding generics to Go was well-founded.

Re: FP-Go: Functional programming library for Golang

#89
post #73

Adding generics to go was a mistake

I've ended up using at least a half dozen generic helpers in every application I've written since they were added. They've made my coding easier, more concise, and help with testing. Adding generics to Go was well-founded.

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

Re: FP-Go: Functional programming library for Golang

#90
> 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.

Post reply on HN