Functional Programming in Go

I agree, but I also appreciate this because missing map/filter/reduce is probably my biggest pain point when writing Go. Nested for loops and explicit filters are so ugly and hard to read, for me that alone undoes any of the appeal of the language's "simplicity".

I can’t speak to Go, but I encounter this attitude in other languages where I have more experience. In one particular case, TypeScript, I have quite a bit of experience “shoehorning” FP to very good results.

I find the attitude tiresome. Sure, in an abstract sense, there’s “more” to FP than these common abstractions. But there’s also less: FP is ultimately about acting on values. The “functional” part is an acknowledgment that a “function”, in its mathematical sense, is the common abstraction which achieves that. Map/filter/reduce are no more fundamental to that than any of the typical academic concepts often found in ML-family languages. Nor, as a detractor on Twitter suggested to me recently, are persistent data structures essential. Values are the essential concept, and all else that FP offers are in service of that concept.

You can apply the same principles in nearly any language. You may need to build up your own implementation of some common abstractions to benefit from them. You may find certain patterns inherently awkward due to language semantics, or sometimes just syntax. Ultimately it’s still rewarding, from the perspective that one will be using said non-FP-paradigm language anyway. Because working with values is its own reward. And it’s incredibly rewarding, even if limited.

I don’t think it does anyone any good to gatekeep that on the basis that the compromise… is a compromise. Sure, it’s worth pointing out that there are limited benefits. But none, in my experience, so limited that they negate the benefit entirely.

I worked with a group that basically elixir-fide typescript for the frontend and ruby for the backend.

It was insanely slow and unintrospectable, to get elixir syntax for ruby they had to abuse blocks horribly, refactoring was decent for already existing components but as an org they had the slowest ruby "new feature" development I've ever seen in 20 years.

Don't throw away all your debugging and IDE tools just to shoehorn a different language paradigm into your existing codebase, if you can prove to me that you have put co-commiserate effort into the tooling and can actually demonstrate this fact practically then you are good but probably still wasting time and should switch to elixir/f# or whatever.

This group hired me because I was the only outside senior level person that was a rubyist and an elixir guy with a lot of FP work in the data space willing to give them a shot (fp is good, it's a good tool but not a panacea, fp is borderline an academic cargo cult nerd snipe in how people proselytize and get into it imo) and I was at a career point where I was doing a lot of exploratory stuff so I found them intriguing since they did have a real product in prod.

In my interview process, I didn't vet their actual dev process nearly enough, total waste of time for people who want to do product development with any velocity.

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

F# :)

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

Gleam is pretty nice in that regard I think, I can see some parallels with Go in terms of simplicity and Rust in terms of basic syntax, it does currently lack a native target that produces a Go-like single binary though.

If one were to produce a Clojure analogue to Go, I think that would be pretty huge. Meaning, Clojure is to Java as XXXX is to Golang. Golang has atrocious syntax and - agreed - not really well suited for functional programming. But having a higher level language that could be compiled down to golang and leverage the ecosystem would be quite nice.

Was just talking about this during a 1:1 with a colleague of mine today. It's remarkable that language developers have set out to do clean sheet designs (golang, rust) and somehow managed to settle on gross syntax. If I were desigining a language today it would look and feel like Python without any of the performance hurdles.

I don't think this is functional programming as much as it is just a DSL for behaviour driven testing.

It doesn't feel like Go, really, but there is still a place for high level testing like that. Personally, I prefer it for integration testing and other situations where you might be asserting on multiple steps of functionality as part of a wider piece (like transactional business logic).

What's horrible about that?