I think a compile to Go approach would have been better. It would allow bypassing most of the warts and still potentially allow interoperability with existing Go code. It would also likely be better received as it would be clear that this is not supposed to be Go.
FP-Go: Functional programming library for Golang
51–60 of 185 posts
Re: FP-Go: Functional programming library for Golang
#52I 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.
Fortunately it's all paid for by investors.
Re: FP-Go: Functional programming library for Golang
#53I 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.
[deleted]
Re: FP-Go: Functional programming library for Golang
#54See also, fp-ts and fpdart, both of which I use for my frontend projects. On the backend, I use Rust.
Re: FP-Go: Functional programming library for Golang
#55Seriously, why? The only compelling argument for monadic effect systems I see is in languages with no easy-to-use and lightweight concurrency, and this is where Go shines. I thinks this is cool and all but I don't think it can ever be justified with this added complexity in Go. I have worked much with Cats Effect in Scala, which is nice but it adds some serious cognitive overhead.
Re: FP-Go: Functional programming library for Golang
#56A simple alternative is the combination of:
- https://github.com/samber/lo
- https://github.com/samber/mo
The split is also nice as you can choose to just use the generic convenience functions from lo without the more FP related things from mo.
Re: FP-Go: Functional programming library for Golang
#57Was 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,…
Exactly, I can’t wait to force this on my junior programmers and make them look stupid.
cracks knuckles over keyboard
Re: FP-Go: Functional programming library for Golang
#58Why?
I can think of two good reasons:
1. To look clever.
2. To make junior programmers look stupid.
Re: FP-Go: Functional programming library for Golang
#59[deleted]
Re: FP-Go: Functional programming library for Golang
#60This 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.
IBM is a leader in (over)engineering.