10 ms·

Functional Programming in Go

45 points by gus_leonel 2y ago

neonsunset 2y ago
[flagged]
- speps 2y ago
  You’d benefit from reading the guidelines regarding comments.
- NomDePlum 2y ago
  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.
- FrustratedMonky 2y ago
  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.?
  - jerf 2y ago
    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.)
    - FrustratedMonky 2y ago
      "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.
      - jerf 2y ago
        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/ https://xkcd.com/224/
freitzzz 2y ago
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.
- whalesalad 2y ago
  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.
  - jshen 2y ago
    I love Go's syntax. If you hate it, please use a different language. Diversity is good, monocultures are bad.
  - geodel 2y ago
    > 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.
    - whalesalad 2y ago
      [flagged]
      - 2y ago
SleekoNiko 2y ago
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 https://github.com/IBM/fp-go
- neonsunset 2y ago
  > Perhaps somebody will create a garbage-collected Rust-like language in the future and bridge the gap between the two languages. F# :)
  - zxexz 2y ago
    F# is exactly this, and a pleasure to work with.
- __jonas 2y ago
  > 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.
eska 2y ago
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.
- xelamonster 2y ago
  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".
  - ljm 2y ago
    I'm only partly convinced that bringing functional abstractions to various kinds of collections/iterators/enumerators, etc. adds value to Go, both in terms of reading code and writing it. That's pretty much as far as 'functional programming' goes when this topic comes up. It brings Java libraries like vavr to mind. The concept has appeal if you appreciate the aesthetics of functional programming but your codebase will be filled with places where you have to convert between the sexy functional style and the boring shit in order to get anything done. It's better to just roll with the language and stick to where it excels. It may not be as easy on the eyes and it may also be boring to write, but a lot less can go wrong with it.
- eyelidlessness 2y ago
  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.
ojhughes 2y ago
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 https://onsi.github.io/ginkgo/#writing-specs
- ljm 2y ago
  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).
- arunix 2y ago
  What's horrible about that?
deleted 2y ago
[deleted]
Insanity 2y ago
Hey, I wrote a book with that exact same title as the blog post.. :) not sure if HN frowns upon this kind of self-advertising in comments, but well.. you can find it on Amazon / Packt, if you are interested lol
librasteve 2y ago
I think there is a genuine tension between languages that can do functional and languages that are functional. Sometimes having functional there as one of the tools, but not the only tool, is best. For example raku (and perl before it) has very good support with map/grep/closures, etc. https://rakujourney.wordpress.com/2024/10/12/raku-burritos/ https://rakujourney.wordpress.com/2024/10/12/raku-burritos/ Says… And let’s end with a quote (sadly I did not record the originator)… I think i just expressed my thought in a wrong way, haha. I am a functional freak, and the first thing i did was check out Raku’s functional patterns. I was amazed. Raku can be extremely functional, but in my opinion language can be called functional when there’s no other way other than functional for the most part. Raku has great functional support, but the language doesn’t force you into anything, you can do basically anything! A sandbox language, and i am loving it. anon

45 points by gus_leonel 2y ago

neonsunset 2y ago

[flagged]

speps 2y ago
You’d benefit from reading the guidelines regarding comments.
NomDePlum 2y ago
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.
FrustratedMonky 2y ago
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.?
- jerf 2y ago
  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.)
  - FrustratedMonky 2y ago
    "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.
    - jerf 2y ago
      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/ https://xkcd.com/224/

freitzzz 2y ago

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.

whalesalad 2y ago
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.
- jshen 2y ago
  I love Go's syntax. If you hate it, please use a different language. Diversity is good, monocultures are bad.
- geodel 2y ago
  > 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.
  - whalesalad 2y ago
    [flagged]
    - 2y ago

SleekoNiko 2y ago

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 https://github.com/IBM/fp-go

neonsunset 2y ago
> Perhaps somebody will create a garbage-collected Rust-like language in the future and bridge the gap between the two languages. F# :)
- zxexz 2y ago
  F# is exactly this, and a pleasure to work with.
__jonas 2y ago
> 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.

eska 2y ago

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.

xelamonster 2y ago
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".
- ljm 2y ago
  I'm only partly convinced that bringing functional abstractions to various kinds of collections/iterators/enumerators, etc. adds value to Go, both in terms of reading code and writing it. That's pretty much as far as 'functional programming' goes when this topic comes up. It brings Java libraries like vavr to mind. The concept has appeal if you appreciate the aesthetics of functional programming but your codebase will be filled with places where you have to convert between the sexy functional style and the boring shit in order to get anything done. It's better to just roll with the language and stick to where it excels. It may not be as easy on the eyes and it may also be boring to write, but a lot less can go wrong with it.
eyelidlessness 2y ago
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.

ojhughes 2y ago

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 https://onsi.github.io/ginkgo/#writing-specs

ljm 2y ago
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).
arunix 2y ago
What's horrible about that?

deleted 2y ago

[deleted]

Insanity 2y ago

Hey, I wrote a book with that exact same title as the blog post.. :) not sure if HN frowns upon this kind of self-advertising in comments, but well.. you can find it on Amazon / Packt, if you are interested lol

librasteve 2y ago

I think there is a genuine tension between languages that can do functional and languages that are functional. Sometimes having functional there as one of the tools, but not the only tool, is best. For example raku (and perl before it) has very good support with map/grep/closures, etc. https://rakujourney.wordpress.com/2024/10/12/raku-burritos/ https://rakujourney.wordpress.com/2024/10/12/raku-burritos/ Says… And let’s end with a quote (sadly I did not record the originator)… I think i just expressed my thought in a wrong way, haha. I am a functional freak, and the first thing i did was check out Raku’s functional patterns. I was amazed. Raku can be extremely functional, but in my opinion language can be called functional when there’s no other way other than functional for the most part. Raku has great functional support, but the language doesn’t force you into anything, you can do basically anything! A sandbox language, and i am loving it. anon