Elixir is "better for FP" as an argument to the value of a platform that primarily oriented towards FP. Some arguments against late-day FP adoption are the performance of FP languages (well, less the language itself but the underlying platform). Elixir comes with some improvements, including better use of concurrency (without noticeable performance degradation) under BEAM.
Maybe Guido van Rossum had a thing against FP. But despite that article from 2005, all those functions are faring well in Python. They do what they're meant to do so the support is there. But there's an argument to be had about what it means for a language to be a FP language. Map-reduce (with extended map/reduce/filter) is a pattern. If the language provides the implementation of the pattern, that's great but as long as it can be implemented without productivity or performance penalties, that's fine by me.
Go has nowhere near the same support for FP patterns (oficially) but there are quite a few libraries providing monads in Go. Guess what, it works :)
Elixir comes with some improvements, including better use of concurrency (without noticeable performance degradation) under BEAM.
Both Erlang and Elixir use the same BEAM so there is likely no performance difference. The Elixir compiler would have to produce AST/bytecode that is somehow more efficient than Erlang's output - and I somehow doubt that. The entire point of the BEAM is to create a highly concurrent (and resilient/fault tolerant) operating environment; using FP was motivated by the benefits afforded by "immutability by default" (and consequently persistent data structures) in a Shared Nothing architecture. Even back in a 2014 Talk Bryan Hunter claimed that
60% of the world's mobile traffic is going through Erlang
… obviously with a fairly limited pool of developers.
Robert Virding
@rvirding
@YungTseTech @jlouis666 Well then, just more cases where it's in wide use but you don't see it or know about it. It's really great it's being used but a bit depressing that no one knows about it as you continually hear "what's Erlang, why should I learn/use it as no one uses it?"
11:36 AM - 13 Jun 2019
One of the more notable improvements in Elixir are hygenic macros - but that has nothing to do with FP.
… and perhaps they all have a point that Python isn't an ideal foundation for "functional programming" - while the occasional "functional tactic/trick" can be helpful.
JS has the advantage that Brendan Eich had Scheme on the brain when he designed it, so it can lend itself to some Scheme-y approaches but JS is still an imperative language as in general neither immutability nor recursion are particularly efficient.
there are quite a few libraries providing monads in Go. Guess what, it works :)
The beauty of algebraic structures is that they are like patterns with superpowers. Implement an algebraic structure to strictly conform to its specific set of "laws" and you get some implicit and powerful benefits.
The problem is that using these implementations without the safety net of a language or environment that yells at you when you start to "break those laws" can get you into trouble when you need those guarantees the most.
Elixir is "better for FP" as an argument to the value of a platform that primarily oriented towards FP. Some arguments against late-day FP adoption are the performance of FP languages (well, less the language itself but the underlying platform). Elixir comes with some improvements, including better use of concurrency (without noticeable performance degradation) under BEAM.
Maybe Guido van Rossum had a thing against FP. But despite that article from 2005, all those functions are faring well in Python. They do what they're meant to do so the support is there. But there's an argument to be had about what it means for a language to be a FP language. Map-reduce (with extended map/reduce/filter) is a pattern. If the language provides the implementation of the pattern, that's great but as long as it can be implemented without productivity or performance penalties, that's fine by me.
Go has nowhere near the same support for FP patterns (oficially) but there are quite a few libraries providing monads in Go. Guess what, it works :)
Both Erlang and Elixir use the same BEAM so there is likely no performance difference. The Elixir compiler would have to produce AST/bytecode that is somehow more efficient than Erlang's output - and I somehow doubt that. The entire point of the BEAM is to create a highly concurrent (and resilient/fault tolerant) operating environment; using FP was motivated by the benefits afforded by "immutability by default" (and consequently persistent data structures) in a Shared Nothing architecture. Even back in a 2014 Talk Bryan Hunter claimed that
… obviously with a fairly limited pool of developers.
One of the more notable improvements in Elixir are hygenic macros - but that has nothing to do with FP.
The "hostility" continues to this day, e.g.:
… and perhaps they all have a point that Python isn't an ideal foundation for "functional programming" - while the occasional "functional tactic/trick" can be helpful.
JS has the advantage that Brendan Eich had Scheme on the brain when he designed it, so it can lend itself to some Scheme-y approaches but JS is still an imperative language as in general neither immutability nor recursion are particularly efficient.
The beauty of algebraic structures is that they are like patterns with superpowers. Implement an algebraic structure to strictly conform to its specific set of "laws" and you get some implicit and powerful benefits.
The problem is that using these implementations without the safety net of a language or environment that yells at you when you start to "break those laws" can get you into trouble when you need those guarantees the most.
Thanks for sharing all this useful information 📚👍