I think shoehorning fp onto go just results in people having a wrong first impression of fp, damaging them for years or forever. fp is so much more than map, filter and reduce.
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.
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'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.
> 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.
Function operations are possible in Go like it’s possible in any language that define function in the syntax. But functional programming goes beyond functions, and Go was not designed to support it.
I’m a fan of Go and FP and would love to see someone bridge other FP aspects like monads, in a way that feels natural in Go.
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.
> It's remarkable that language developers have set out to do clean sheet designs (golang, rust) and somehow managed to settle on gross syntax.
You are talking of your opinion as some kind of facts. What you call gross syntax is good enough for people to write enormous amount of useful software that millions and millions use daily. The same can't be said for Clojure.
50+% of the united states voted to re-elect a rapist, felon, etc... so I don't base my opinions on the fact that a huge population of people have accomplished something with said tool.
Because functional programming isn't infinitely good, such that all need to consider costs is forever and totally erased.
The costs and benefits of a particular programming style must be evaluated in the context of the language under examination. You can't take the benefits of functional programming in Haskell and blindly copy them into the benefits column of your Go analysis. You must actually do the analysis in the target language.
And once you do that, you will discover the cost/benefits of doing what most people call "functional programming" in Go is not very appealing. The costs magnify substantially and the benefits diminish greatly.
So... why would one do it?
(I qualify "what most people call functional programming" because my considered opinion is that "map/reduce/filter" isn't the interesting aspect of functional programming, but I'm still working on my guide on how to correctly bring the real lessons of functional programming back into imperative languages like Go, and this comment box is not enough to drop it all here.)
Well, it depends on your point of view. According to the most respected Computational Theologian of our time, rather a lot of the universe is written in Perl [1]. Is Perl "functional programming"? One might argue it at least embeds a functional programming language within itself, but I suspect if we could do exegesis on the phrase "hacked most of it together in Perl" that it would not very strongly suggest the sort of elegance one nominally associates with Functional Programming.
I think shoehorning fp onto go just results in people having a wrong first impression of fp, damaging them for years or forever. fp is so much more than map, filter and reduce.
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.
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'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
> 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.
> Perhaps somebody will create a garbage-collected Rust-like language in the future and bridge the gap between the two languages.
F# :)
Function operations are possible in Go like it’s possible in any language that define function in the syntax. But functional programming goes beyond functions, and Go was not designed to support it.
I’m a fan of Go and FP and would love to see someone bridge other FP aspects like monads, in a way that feels natural in Go.
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.
> It's remarkable that language developers have set out to do clean sheet designs (golang, rust) and somehow managed to settle on gross syntax.
You are talking of your opinion as some kind of facts. What you call gross syntax is good enough for people to write enormous amount of useful software that millions and millions use daily. The same can't be said for Clojure.
50+% of the united states voted to re-elect a rapist, felon, etc... so I don't base my opinions on the fact that a huge population of people have accomplished something with said tool.
Make sense. You are indeed Opinion leader of your opinions and Thought leader of your thoughts.
I love Go's syntax. If you hate it, please use a different language. Diversity is good, monocultures are bad.
Take a look at the Ginkgo testing framework to see the horrors of shoe horning FP into Go
https://onsi.github.io/ginkgo/#writing-specs
[flagged]
You’d benefit from reading the guidelines regarding comments.
Why? Can't you do functional programming in any language? Some easier than others, but conceptually, some examples are good. So why not do it in GO.?
Because functional programming isn't infinitely good, such that all need to consider costs is forever and totally erased.
The costs and benefits of a particular programming style must be evaluated in the context of the language under examination. You can't take the benefits of functional programming in Haskell and blindly copy them into the benefits column of your Go analysis. You must actually do the analysis in the target language.
And once you do that, you will discover the cost/benefits of doing what most people call "functional programming" in Go is not very appealing. The costs magnify substantially and the benefits diminish greatly.
So... why would one do it?
(I qualify "what most people call functional programming" because my considered opinion is that "map/reduce/filter" isn't the interesting aspect of functional programming, but I'm still working on my guide on how to correctly bring the real lessons of functional programming back into imperative languages like Go, and this comment box is not enough to drop it all here.)
"Because functional programming isn't infinitely good,"
Some languages do make it harder, but functional programming is infinitely good.
I hear god used functional programming when he made the universe.
He tried objects once, I think C++, and accidently created Australia. Some error with multiple inheritance.
Well, it depends on your point of view. According to the most respected Computational Theologian of our time, rather a lot of the universe is written in Perl [1]. Is Perl "functional programming"? One might argue it at least embeds a functional programming language within itself, but I suspect if we could do exegesis on the phrase "hacked most of it together in Perl" that it would not very strongly suggest the sort of elegance one nominally associates with Functional Programming.
[1]: https://xkcd.com/224/
I had the same thought, but the actual code examples in the article look fine to me as useful utilities.
It's not really much more than that. Certainly a long way off full FP.