gofpher VS fp-go

I'm glad to see this idea getting some traction again. I haven't used Go much in the last few years, but I started writing 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...).

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.

Monadic error handling like in ML work-alikes, Rust etc. would be a good start. Adopt:

• https://github.com/rebeccaskinner/gofpher

• https://speakerdeck.com/rebeccaskinner/monadic-error-handlin...

I've been talking to the local Go user group. No one even knows about that concept. This continues a pattern of general ignorance/lack of looking beyond one's horizon I've noticed.

I've tried going down this route myself by using libraries like fp-go[1]. I think this particular project has done a great job, but I ultimately opted not to pursue functional programming in Go for a few reasons:

- Ergonomics weren't the greatest when working with monads such as options and results. I think pattern matching is needed here, but concepts like those go against Go's core design philosophy.

- I suspect there are several cases where runtime performance is an issue, but admittedly did not investigate this.

- Perhaps most importantly, it deviates from the way most people read and write Go, and less importantly, LLMs struggle too.

Because of these reasons, I came to the conclusion that the advantages were not worth the trade-offs.

Perhaps somebody will create a garbage-collected Rust-like language in the future and bridge the gap between the two languages.

[1] - https://github.com/IBM/fp-go

True, however the README does link to this:

https://github.com/IBM/fp-go/tree/main/samples