gofpher VS fp-ts

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.

In addition to our testing strategy, we ensure that each service in our modules—whether public or private—follows a functional programming style using the fp-ts library.

You might be interested in `fp-ts` (and the related `io-ts`).

https://gcanti.github.io/fp-ts/

https://gcanti.github.io/io-ts/

I think it’s great that functional programming is making its way into traditional imperative languages - even JavaScript (I recently came across https://gcanti.github.io/fp-ts/ as a pretty extreme example)

Elixir/Erlang has function-level pattern matching, which I really like. I’ve yet to see it anywhere else, though my understanding is it came from Prolog.

While I certainly agree, I've found that this is often an indication of too-complex an architecture, and a fundamental re-think being necessary. I've had projects that depend on [fp-ts], which end up incredibly generic-heavy, but still make it entirely through a typecheck(not build- typescript's just worse at that than other tools like esbuild) in seconds-at-worse.

Obviously depends on your organization/project/application, but I do like these things as complexity-smells.

[fp-ts]: https://gcanti.github.io/fp-ts/

Unlike more comprehensive functional libraries like fp-ts, each module can be imported and resolved separately. If you just need options, simply add the option module and you're good to go.

While it's quite abstract, I believe it may be useful to those of you who is interested to learn more about functional programming [in Typescript] and also get more intuition on diverse programming ideas. I use fp-ts as a functional programming library there.

The library for TypeScript that this is influenced by is here:

https://github.com/gcanti/fp-ts

Interesting how both languages with this library converge to a similar syntax, due to heavy use of functions.

Learn something that pays the bill first - nowadays it's Golang/Rust react/typescript. Then you can try some pure fp libs like fp-ts and fp-core.rs, and look through existing scala cats docs. If you'll feel bad about it - that's totally fine and expectable, fp takes a paradigm shift and not that many dev able to shift their brains way of thought due to basic psychological rigidity) (inability to change habits and to modify concepts/attitudes once developed). And that's purely a staffing and management issue - folks hired randoms out of the blue, and called 'em a team.

fp-ts, a library that caters to functional programming in TypeScript, comes with some micro-abstractions that already solve a few of our needs.

Also, don't underestimate how powerful TypeScript can be in capable hands (namely Giulio Canti's). Check out fp-ts, for instance.