Hacker News Reader

Comment by chrisseaton | Hacker News Reader

You can write exclusively functional code in pretty much any language can't you?

Go is probably one popular exception.

You still can if you wish to. First-class functions are there.

I wish that were true. Unfortunately, functional composition breaks down when functions have multiple return values, as is the case for everything that returns an `err, res` pair. So even with generics added, Go is still hostile to functional programming.

If Go gets a Result<T> generic type similar to the one in Rust to replace (err, res) that would work. That seems highly unlikely, however. The node.js community went through a similar migration from (err, res) callbacks to promises and it was quite painful, I think its highly unlikely this will happen in Go.

(res, err) is Either monad, isn't it?

Its not a single value, so its not anything.

That may've sounded overly harsh - but as a first step, try for example to use the output of a Go function that returns two values in another expression.

e.g. assuming `g` returns (err, res), try writing `f` in such a way that you can call `f(g(x))`.

This has implications on how higher order functions like `map`, `filter` etc can be written in a way that makes them usable with any value (including those that represent an error)

func composeE[T](fn1, fn2 func(T, error) (T, error)) func(T, error) (T, error)

func liftE[T](func(t T) T) func(T, error) (T, error)

I'm not a big fan of functional programming though.

I think you might want the opposite of liftE, i.e. to be able to convert any function with two returning values into a function with a single returning value.

Then you can use those functions normally with standard FP tools such as `map` etc.

Yes, the node.js community did something like that with (err, res) and it still does it. Its pretty awful to be unable to use any of the standard library or community library functions (that can error) in a... functional way without wrapping them.

It used to be impossible to do anything remotely like FP in Go before generics, but now I believe it's indeed quite possible.

But everything you can do with generics you can do manually by copying and pasting code?

Oh that's true. But you're a terrible masochist if you consider that an option.

Or lets look at persistent data structures, a staple of functional programming:

https://github.com/tobgu/peds

Notice how you'd need to generate the DS for every type you'd like to use it with, which is not the case with built in mutable maps and slices.

To make them type-safe, you need to generate them for every type you use. While this is technically possible, it does make the language quite hostile towards functional programming. With generics, this is rectified but the problem with non-composable multi-return-value functions still remains

Lets take `map` for example. Before generics, you would have to reimplement map for every type combination. Each implementation would be done with a for loop. Now, while I'm willing to look over having one `map` implementation being done in imperative code and then everything else using that, I'm not exactly comfortable calling reimplementing map with imperative code for every type combination functional programming.

Reminds of

https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Reply on news.ycombinator.com