About your serach at hex.pm, I think the most complete package is GitHub - witchcrafters/witchcraft: Monads and other dark magic for Elixir · GitHub
zandao
peerreynders
People seem to forget that a curried function is a workaround for the constraint in lambda calculus that a function can only have one, single argument. So in its original form (((f(1))(2))(3)) was necessary instead of f(1,2,3).
Languages like Haskell and OCaml popularized a notational convenience where you can use forms like f(1) and f(1,2) to return another function. But somehow people conflate that notational convenience with “currying”.
What is worse is that the obsession with currying seems to obscure the fact that “partial application” is the useful and powerful idea - which can be implemented simply by capturing available parameters inside a closure and returning a function that is ready to accept the remaining parameters.
As far as I’m concerned partial application is the meat and potatoes - currying is a mere frill.
12
easco
These two statements are curious and interesting to me. “Horrible” is obviously a subjective opinion, and, in my opinion, a rather strong superlative to paint the entire API with. I’ve never seen anyone else mention that the the position of parameters in a function call being a “basic concept of FP languages”.
Is it somehow tied into your apparent penchant and desire for partial application?
I’ve not really had any strong problems using the Elixir API. It’s something I do have to think about switching back and forth between Elixir and Elm. Even so, I certainly wouldn’t categorize it as “horrible” myself so I’m genuinely curious to know, what do you find so objectionable?
0
peerreynders
That topic does come up regularly but because on the BEAM different functions can have the same name as long as the arity differs, creating Haskell-style “compile time notational currying” is basically out of the question anyway.
(In Bucklescript, which supports curried functions, parameter position was an ardently discussed topic).
1
jxm
Plus, an additional reason for data-first API in Elixir is consistency with (most of, except a few modules) erlang existing conventions. This is a very pragmatic, down-to-earth consideration, one that in my eyes brings much more value than bikeshedding around not-so-important syntactic preferences. This is a typical example of what I like about the way Jose and the core team are designing things, being pragmatic and resisting the temptation to over-design. In my view, this gives Elixir a credibility that is rare for a young language, the opposite of a toy language or a research-oriented one.
1
pera
Not every FP language is a Haskell-derivative 
so it’s odd that you are expecting the same set of features in every FP language. Have you ever tried Idris or ATS for instance? would you say that Haskell is less FP just because its type system lacks linear, uniqueness or dependent types?
1
easco
There is no requirement to bind an anonymous function to a name before it can be invoked:
def partially_apply_me(left_addend) do
fn (right_addend) -> left_addend + right_addend end
end
IO.puts partially_apply_me(3).(5)
Or simply:
iex(4)> (fn (x) -> IO.puts(x) end).("foo")
foo
:ok
But in these examples, as well as the one above where the function is bound to a variable the .() syntax is consistently applied to indicate that you are applying parameters to an anonymous function.
It might be that in the partial application case you could unambiguously drop the dot, but then that would then be an inconsistency in the syntax of calling anonymous functions.
1
l00ker
So why use Elixir ?
If for no other reason – The BEAM! 
That. That right there is worth overcoming any issues you may have with Elixir or Erlang as languages. It’s the Erlang Run-Time System (ERTS) that separates it from the pack.
[mike drop]
3
SeaGraph
So did you accept the job offer of not? Let us know as there are a of people on this forum that find programming in Erlang/Elixir/Phoenix a joy and my guess is many would accept the offer with little hesitation. I know I would ( well if I don’t have to sacrifice a virgin and goat and yada yada yada to get it ).
There is a course that examines different programming languages down to the compiler/interpreter level and goes into details about the trade-offs. It even shows how to create functional like language interpreters using an OOP language and vice versa. It will take about 3 months to go through it but it’s worth it and here is a blurb about it:
Purescript is an example of a language that is transliterated into another language - javascript. I read the book and did the examples and like it a lot - would love a job using it as well - just don’t know if there will ever be much of a demand for it.
Getting into the syntax difference reminds me of the endless flame wars between Ruby and Python and how having to indent code was a horrible thing - well I loved programming in Ruby but anyone can now see that Python is rising to the top of the list of most programming languages used. I now use and enjoy both and they are way more alike than different and syntax is no issue - at least to me.
But you can and I think should should hold out for a job using pure functional languages only - you will never really be enthusiastic about your job if you don’t. Here is a partial list to get you started:
0
jeremyjh
No not really. I think this is one of the biggest warts of the language.
By the way, glancing over this thread, I’m not sure if you really covered what I perceive as a terminology gap. In FP vernacular, a purely functional language is one that captures all side-effects in the type system. There are very few of these: Haskell, Purescript, Idris (notice these compilers are all written in Haskell), a few others. As a Haskeller who writes Elixir for a living, I can tell you that Elixir does disappoint in many ways that you’ve pointed out. But Elixir has other strengths - in particular it is really easy to learn compared to Haskell, and has really great, production-ready libraries for many practical uses that I find lacking in Haskell. Elixir also has a much more coherent standard library - its easy to remember where everything is. When writing Haskell I still hoogle a lot even for base functions, and I’ve been writing it for five years.
2