The article picks on Javascript (of course) however you can write almost exclusively functional code in Javascript with the help of Rambda, fp-ts or the like. Yes, there is no "compiler" (outside of tsc) that will help you (yet) but stylistically, it's possible.
> There is nothing magical about functional programming
How come not? I read that F# gives you compiler exception when you didn't match all possible values. Or when you didn't handle __maybe__ cases. JS even doesn't mind comparing strings with ints and incorrectly summing them together and not throwing a runtime exception less alone a compiler complaint.
You can add error checking (e.g., compiler exceptions), but you cannot remove the parts of JS/other languages that cause that error checking to be important in the first place, not without fundamentally breaking the language/existing libraries.
TFA describes a paradigm where those features don't exist, and so the error checking is not important. That's a truly safe language. It's also hypothetical at this point, IMHO.
Well, we are talking about functional programming improving program correctness. Such behavior doesn't help. Better choose another language that is a fit for it.
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.
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)
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.
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.
Javascript is already functional enough without these libraries. Rambda et al make simple code unnecessarily complex or verbose, and complex code unreadable
