6 ms·

Higher-order functions in Go

62 points by azhenley 4y ago

kodah 4y ago
Higher order functions are super useful for middleware in Go. Functions are also nillable which makes them useful as options. Combined with variatic functions you can build quite a nice API.
- cookiengineer 4y ago
  Does that mean you use variadic functions to adapt to different structs and their properties/fields and they all return the same "base struct"? Do you have example code? I am now really curious, but don't know what to google.
  - gouggoug 4y ago
    I think you are looking for “functional options”[0] [0] https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis https://dave.cheney.net/2014/10/17/functional-options-for-fr...
    - bryancoxwell 4y ago
      Oh dear I love that. Thanks for sharing.
Hirrolot 4y ago
Built-in support for closures in Golang is indeed a nice feature. In contrast, in C you would have to explicitly allocate/deallocate closures if they are passed upwards the stack [1], and pack all environmental variables in a single structure (used externally as a `void` pointer). This all tends to be quite clumsy in real-world code. The Rust support for closures is more pleasant than that of C but the innate `Fn`/`FnMut`/`FnOnce` dichotomy makes things more complicated. [1] https://en.wikipedia.org/wiki/Funarg_problem#Upwards_funarg_problem https://en.wikipedia.org/wiki/Funarg_problem#Upwards_funarg_...
- lloydatkinson 4y ago
  I can’t think of any modern languages without closures.
  - speps 4y ago
    Zig...
    - lloydatkinson 4y ago
      Ouch
    - dist1ll 4y ago
      You can emulate closures with anonymous structs. struct { fn foo() { /**/ } }.foo If you want closures that capture values, you just need to define the appropriate struct. I'm pretty sure with proper use of comptime reflection and custom allocators you can build pretty performant and ergonomic closures (albeit with a lot less memory and type safety of course).
KingOfCoders 4y ago
I use samber/lo in every project https://github.com/samber/lo https://github.com/samber/lo (Go is still plenty fast with it)
- mseepgood 4y ago
  That's really misguided. Go is not a functional programming language, it's an imperative programming language. You're going against its design. You're like these people who write Java and "class hierarchies" in Go, just from a different angle. If you like FP you should use Haskell instead of Go. I say this as a fan of Go.
  - KingOfCoders 4y ago
    A map() is much easier to read and understand than create slice, for loop, return slice. Coding is about reading code.
    - morelisp 4y ago
      An unfused map-filter chain is a performance disaster waiting to happen.
      - KingOfCoders 4y ago
        In Go or in general? I've written code for companies with 50k+ concurrent writing users, I've bootstrapped and scaled and sold a startup on Scala (which has bad performance b/c of immutable lists but with usual list <100 elements no problem) and I haven't seen this in other languages, but I'm not experienced enough in Go and haven't deployed something major in Go yet.
        morelisp 4y ago
        Other popular languages will fuse either via JIT or via some kind of linear types. You should preen less in your comments.
t8sr 4y ago
When Go first started to get traction at Google, I saw it mostly replacing Python (and some Java), but not a whole lot of C/C++. As the adage goes, you can write Java/Python in any language, and a lot of people did, and from that time we have a lot of Go code with two specific smells: 1) A lot of channels, because Python coders wanted iterators. (This got so bad I've seen memos circulated about channels not being allowed to cross public API boundaries.) 2) A lot of interfaces, because of Java I am really happy about the recent trend towards a more functional style in the language, it's so much closer to what I think the authors intended the language to look like.
- mseepgood 4y ago
  > I am really happy about the recent trend towards a more functional style There is no such trend, at least not from the Go maintainers' side. Trying to write Haskell in Go is just as misguided and futile as trying to write Java in Go. > in the language, it's so much closer to what I think the authors intended the language to look like. I don't think so. The wanted it to be imperative like C or Pascal/Modula/Oberon, otherwise they would have started the design with ML or Lisp instead of C.
  - t8sr 4y ago
    I think you're responding to something I didn't (intend to) say. It is a lot closer in the sense that it is less indirected and simpler. The Go team have circulated style guidance to groups I was part of about how to properly structure public APIs, and for example functional callbacks are nowadays preferred over channels. I completely agree that Go is not designed to be Haskell, and I personally cringe every time I see a library of map/reduce/filter functions. I still prefer this over the older sins of stuff like ITreeIterator. When I say "functional style" I don't mean lambda calculus. I mean more recent libraries don't tend to return interface-typed values as much or use channels as iterators.
    - morelisp 4y ago
      There's a widening generational gap in what "functional programming", in a practical sense, means. "Back in the day" a language got called 'functional' if it had anonymous closures, upwards funargs, tail calls, you could implement a decent `reduce`, etc. Today it means purity and immutability, monadic comprehensions, and type systems to support all that. Go's the first kind of functional language. But so is almost everything else, even Java, now.
c4mpute 4y ago
Higher-order functions improve readability, maintainability and correctness. The idiomatic supposed alternative of using e.g. for-loops instead of map/fold/... is a disease that needs to be shunned, like goto was for cases where better constructs exist. If performance suffers, it is up to the language to implement proper inlining and fusion.
- _a_a_a_ 4y ago
  I assume you're either trolling or have neither commercial nor compiler-writing (edit; nor significant functional programming) experience.
  - c4mpute 4y ago
    I do have commercial experience and I did a class on compiler-writing at the university. Therefore I am not trolling.
    - _a_a_a_ 4y ago
      Well you answered moderately and you didn't hammer the downvote button so perhaps we can make something constructive of this. > Higher-order functions improve readability, maintainability and correctness Perhaps correctness, but readability and its close relation, maintainability, well that's another question. I think it depends partly on the person (I'm not very good at reading code) and very definitely on the quality of the written code. I have seen some very, very horrible functional code. Simply declaring that it is more readable doesn't fly. Back to correctness: well, functional code tends to be shorter than non-functional code, and it's a known fact that the number of bugs seems to be a constant per the lines of code (or at least that's the accepted wisdom, let's go with it) so is the lower number of bugs in functional code directly proportional to its reduced size, or is there something extra work? If it's directly proportional to the reduced size, then you often can do a heck of a lot with procedural code to reduce its size as well, usually by simply defining extra procedures/functions instead of copy/pasting code (which is a disease that functional code can very definitely suffer from also!) > If performance suffers, it is up to the language to implement proper inlining and fusion And in the meantime you lose sales, your competitors do better and start eating your market share – if you were running a company how would that make you feel? You have to be realistic. Anyway, I do appreciate that you weren't trolling and weren't dismissive of my post, so I've upvoted your response.
bitfield 4y ago
For more on the modern functional style in Go, including Map, Reduce, Filter, Sort, and so on: https://bitfieldconsulting.com/golang/functional https://bitfieldconsulting.com/golang/functional

62 points by azhenley 4y ago

Higher order functions are super useful for middleware in Go. Functions are also nillable which makes them useful as options. Combined with variatic functions you can build quite a nice API.

cookiengineer 4y ago
Does that mean you use variadic functions to adapt to different structs and their properties/fields and they all return the same "base struct"? Do you have example code? I am now really curious, but don't know what to google.
- gouggoug 4y ago
  I think you are looking for “functional options”[0] [0] https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis https://dave.cheney.net/2014/10/17/functional-options-for-fr...
  - bryancoxwell 4y ago
    Oh dear I love that. Thanks for sharing.

Hirrolot 4y ago

Built-in support for closures in Golang is indeed a nice feature. In contrast, in C you would have to explicitly allocate/deallocate closures if they are passed upwards the stack [1], and pack all environmental variables in a single structure (used externally as a `void` pointer). This all tends to be quite clumsy in real-world code. The Rust support for closures is more pleasant than that of C but the innate `Fn`/`FnMut`/`FnOnce` dichotomy makes things more complicated. [1] https://en.wikipedia.org/wiki/Funarg_problem#Upwards_funarg_problem https://en.wikipedia.org/wiki/Funarg_problem#Upwards_funarg_...

lloydatkinson 4y ago
I can’t think of any modern languages without closures.
- speps 4y ago
  Zig...
  - lloydatkinson 4y ago
    Ouch
  - dist1ll 4y ago
    You can emulate closures with anonymous structs. struct { fn foo() { /**/ } }.foo If you want closures that capture values, you just need to define the appropriate struct. I'm pretty sure with proper use of comptime reflection and custom allocators you can build pretty performant and ergonomic closures (albeit with a lot less memory and type safety of course).

KingOfCoders 4y ago

I use samber/lo in every project https://github.com/samber/lo https://github.com/samber/lo (Go is still plenty fast with it)

mseepgood 4y ago
That's really misguided. Go is not a functional programming language, it's an imperative programming language. You're going against its design. You're like these people who write Java and "class hierarchies" in Go, just from a different angle. If you like FP you should use Haskell instead of Go. I say this as a fan of Go.
- KingOfCoders 4y ago
  A map() is much easier to read and understand than create slice, for loop, return slice. Coding is about reading code.
  - morelisp 4y ago
    An unfused map-filter chain is a performance disaster waiting to happen.
    - KingOfCoders 4y ago
      In Go or in general? I've written code for companies with 50k+ concurrent writing users, I've bootstrapped and scaled and sold a startup on Scala (which has bad performance b/c of immutable lists but with usual list <100 elements no problem) and I haven't seen this in other languages, but I'm not experienced enough in Go and haven't deployed something major in Go yet.
      - morelisp 4y ago
        Other popular languages will fuse either via JIT or via some kind of linear types. You should preen less in your comments.

t8sr 4y ago

When Go first started to get traction at Google, I saw it mostly replacing Python (and some Java), but not a whole lot of C/C++. As the adage goes, you can write Java/Python in any language, and a lot of people did, and from that time we have a lot of Go code with two specific smells: 1) A lot of channels, because Python coders wanted iterators. (This got so bad I've seen memos circulated about channels not being allowed to cross public API boundaries.) 2) A lot of interfaces, because of Java I am really happy about the recent trend towards a more functional style in the language, it's so much closer to what I think the authors intended the language to look like.

mseepgood 4y ago
> I am really happy about the recent trend towards a more functional style There is no such trend, at least not from the Go maintainers' side. Trying to write Haskell in Go is just as misguided and futile as trying to write Java in Go. > in the language, it's so much closer to what I think the authors intended the language to look like. I don't think so. The wanted it to be imperative like C or Pascal/Modula/Oberon, otherwise they would have started the design with ML or Lisp instead of C.
- t8sr 4y ago
  I think you're responding to something I didn't (intend to) say. It is a lot closer in the sense that it is less indirected and simpler. The Go team have circulated style guidance to groups I was part of about how to properly structure public APIs, and for example functional callbacks are nowadays preferred over channels. I completely agree that Go is not designed to be Haskell, and I personally cringe every time I see a library of map/reduce/filter functions. I still prefer this over the older sins of stuff like ITreeIterator. When I say "functional style" I don't mean lambda calculus. I mean more recent libraries don't tend to return interface-typed values as much or use channels as iterators.
  - morelisp 4y ago
    There's a widening generational gap in what "functional programming", in a practical sense, means. "Back in the day" a language got called 'functional' if it had anonymous closures, upwards funargs, tail calls, you could implement a decent `reduce`, etc. Today it means purity and immutability, monadic comprehensions, and type systems to support all that. Go's the first kind of functional language. But so is almost everything else, even Java, now.

c4mpute 4y ago

Higher-order functions improve readability, maintainability and correctness. The idiomatic supposed alternative of using e.g. for-loops instead of map/fold/... is a disease that needs to be shunned, like goto was for cases where better constructs exist. If performance suffers, it is up to the language to implement proper inlining and fusion.

_a_a_a_ 4y ago
I assume you're either trolling or have neither commercial nor compiler-writing (edit; nor significant functional programming) experience.
- c4mpute 4y ago
  I do have commercial experience and I did a class on compiler-writing at the university. Therefore I am not trolling.
  - _a_a_a_ 4y ago
    Well you answered moderately and you didn't hammer the downvote button so perhaps we can make something constructive of this. > Higher-order functions improve readability, maintainability and correctness Perhaps correctness, but readability and its close relation, maintainability, well that's another question. I think it depends partly on the person (I'm not very good at reading code) and very definitely on the quality of the written code. I have seen some very, very horrible functional code. Simply declaring that it is more readable doesn't fly. Back to correctness: well, functional code tends to be shorter than non-functional code, and it's a known fact that the number of bugs seems to be a constant per the lines of code (or at least that's the accepted wisdom, let's go with it) so is the lower number of bugs in functional code directly proportional to its reduced size, or is there something extra work? If it's directly proportional to the reduced size, then you often can do a heck of a lot with procedural code to reduce its size as well, usually by simply defining extra procedures/functions instead of copy/pasting code (which is a disease that functional code can very definitely suffer from also!) > If performance suffers, it is up to the language to implement proper inlining and fusion And in the meantime you lose sales, your competitors do better and start eating your market share – if you were running a company how would that make you feel? You have to be realistic. Anyway, I do appreciate that you weren't trolling and weren't dismissive of my post, so I've upvoted your response.

bitfield 4y ago

For more on the modern functional style in Go, including Map, Reduce, Filter, Sort, and so on: https://bitfieldconsulting.com/golang/functional https://bitfieldconsulting.com/golang/functional