FP-Go: Functional programming library for Golang
1–10 of 185 posts
Re: FP-Go: Functional programming library for Golang
#2I didn't look too much at this but are they offering an alternative to the (IMO ugly) error checking pattern Go enforces? It's interesting to me shoehorning this into Go in particular. Go is notoriously stringent on how you write code.
Re: FP-Go: Functional programming library for Golang
#3I'm glad to see this idea getting some traction again. I haven't used Go much in the last few years, but I started playing around with a similar idea back in 2016 when I was working on a small compiler for a configuration management tool, and later put together a small stand-alone proof of concept library(https://github.com/rebeccaskinner/gofpher) as part of a talk (https://speakerdeck.com/rebeccaskinner/monadic-error-handlin...) I gave in 2017.
At the time, I remember finding FP in go surprisingly ergonomic. Implementing the library to support it was a pain since the type system wasn't expressive enough to prevent everything from devolving into a pile of untyped reflection, but it was reasonably easy to keep that an implementation detail. On the whole, I felt like go would have lent itself well to the "dash of FP for flavor" style of programming that seems to be gaining popularity these days. Unfortunately, in 2017 at least, the Go community seemed to have very little interest in the idea.
I still have a fondness for Go. It always felt nice to use. If the language features have caught up to the point where a robust library like this is feasible, and the communities attitude has shifted, I might take another look at the language.
Re: FP-Go: Functional programming library for Golang
#4These abstractions are not native to go. If you miss them, pick a better language.
Re: FP-Go: Functional programming library for Golang
#5I 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 :-(
There seems also to be a performance problem with map(). It would work better if Go had Iteration instead of slices, otherwise map() creates a lot of slices. And if map does not return a slice you have an ugly
y := x.map(...).native
Re: FP-Go: Functional programming library for Golang
#6These abstractions are not native to go. If you miss them, pick a better language.
Just like FPP is incompatible with C, I agree. And if you want a real taste of FPP go with either Haskell, OCaml or even the good ol' LISP
Re: FP-Go: Functional programming library for Golang
#7Never thought I’d see these three things together. The library looks extremely well done, although I’d expect some interesting reaction as Go is as imperative as it gets.
Re: FP-Go: Functional programming library for Golang
#8I 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).
Re: FP-Go: Functional programming library for Golang
#9The long README needs some usage examples.