Ask HN: What do FP languages have that JavaScript doesn't?

Functional Programming (FP) can be extremely elegant, and you should do your best to at least get familiar with it to see how using it can improve your code quality. There's a lot of theoretical reasons why this paradigm might be particularly great in a future where all devices seem to be adding lots of processing cores. For instance, without a function having side-effects, the potential for conflicts between threads or processes could be completely eliminated, so FP can potentially have some real-world benefits beyond just more elegant code.

That said, you should also think in terms of "What does JavaScript have that functional programming doesn't?". As a working-stiff programmer, most of the time the problems you're going to encounter are going to be a lot easier and faster to solve if mutating state is available as an option.

One easy advantage is predictability due to thing not changing. Let's say there is an array (maybe I should have written list). Since that array cannot change in fp, when you do operations with that array, you don't have to worry it changed.

Then the language itself will also know this and manage memory accordingly.

So if you have array with 1,2,3 and an array with 3,4,5 if you unite the arrays memory can just reference the two array as if they were one instead of creating a new one, because for sure they will never change. Imagine this on very big arrays

Most likely you know that Functional Programming (FP) is a Programming paradigm, that is, an approach to write the programs you have in mind. You have already mentioned some features of such paradigm, I am revisiting JavaScript myself (Since it was a long time since I use it) these days. And I am glad to find famous functions associated with FP, like flatMap, already available in JS. Since you already mentioned lots of these features, the only one that comes to my mind is Lazy Evaluation, which gives you the ability to work with "Infinite structures".

Perhaps you are already aware of these resources, but I will never get tired of recommending the following: * FP101x by Mr. Erik Meijer (The course is archived on edx.org but you can work your way through it). * The above is based on the outstanding book by Graham Hutton, Programming in Haskell. * And, if you can afford it in terms of time, a book from Mr. Peter Van Roy, Concepts, Techniques, and Models of Computer Programming. (There is a section devoted to FP).

Last but not least, I do love JavaScript.

Hope that helps.

Purity is about knowing that functions cannot change the state of variables. It is not about what you can do in the REPL.

The best way to answer these questions, I think, is to just try them out. For instance, Haskell has a very advanced type system that you won't get from Typescript, and it might change the way you approach your work in other languages.

FP is a way of thinking, which FP languages give nice features/syntax for. You can do non-FP style programming with an FP language.

In fact, many FP language features have been borrowed by non-FP languages to the point people don't consider them "FP" anymore[0]. (Like JS `.map()` and `.reduce()`. Even Excel macros now support first-class functions[1].)

Three features that would make FP thinking in JS easier:

1. immutable tuples and records[2]

2. pipe operator[3]

3. pattern matching[4]

Major epiphany: According to Grokking Simplicity[5], good functional programming isn't about avoiding impure functions; instead it's about giving extra care to them. Impure functions depend on the time they are called, so they are the most difficult to get right. In the end, the purpose of all software is to cause some type of mutation/effect (flip pixels on a screen, save bits to storage, send email, etc).

"Functional Core, Imperative Shell"[6] is probably the most useful FP concept. It is about pushing mutation/errors/impure functions to the outer edges of your code, so the inner code can focus on the "happy path." Complex business logic lives in the inner core; the outer shell is often simple/branchless so unit tests aren't even needed.

[0]: https://hw.leftium.com/#/item/21280429

[1]: https://hw.leftium.com/#/item/26900419

[2]: https://hw.leftium.com/#/item/23924933

[3]: https://hw.leftium.com/#/item/34454184

[4]: https://hw.leftium.com/#/item/16921652

[5]: https://www.manning.com/books/grokking-simplicity

[6]: https://hw.leftium.com/#/item/18043058