In Erlang’s defense it has tons of libraries for stuff a telco programmer cares about. Megaco for telephony, ASN.1 for weird protocols, httpd/httpc for simplistic webby interface, diameter authentication, SNMP management all built in.
We just happen to muck around in a very different space.
Back at the point:
Haskell is actually super simple. The basics are just sugared typed lambda calculus (actually sequent calculus, but, one of those things I haven’t looked into yet)
The simplicity, leads to rigorousness, leads to ppl being able to do v complex things with solid foundations
So at some level you can choose your poison in Haskell. No need to jump into the deep end.
Elixir to me can be incredibly complex, when types aren’t checked possible and something very deep in the stack errors.
Where Elixir wins against Haskell is the culture. Great tooling & libs, and a big early focus on the web also..
Java is not expressive as Ruby at all, while Haskell is one of the most expressive language.
Haskell is not complex at all. It’s just having some initial barrier. Fundamentally it’s simpler than most of the languages.
Once you know how to deal with monad (don’t even need to understand it well), you can write a lot of useful things just like other functional programming languages.
Once you know more about typeclass and monad transformer, you can write beautiful programs.
As for Template etc, it’s not a hard requirement for programming language. And referential transparency makes the need for macro lesser. (Think about the if macro in Elixir tutorial, in Haskell it could be actually implement as a function due to it’s lazy nature)
The great thing of Elixir is not only based on the language itself, but also the platform (Erlang/OTP), great tooling etc.
Compared to Haskell, Erlang/OTP makes Elixir a more practical language. There are some projects like Cloud Haskell could be an alternative to Erlang/OTP in the future, but it’s far less mature right now.
Compared to Erlang itself, Elixir tooling and documentation is far easy to learn and use.
Oh absolutely, node as well, OCaml has no JIT, it compiles to machine code so given two languages with a GIL it should on average be faster for equivalent quality code. I still can’t wait for Multicore OCaml with no GIL to finally be merged in (piece by piece it is coming in… slowly…).
Yep, OCaml, NodeJS, Python, Crystal, Ruby, etc… etc… All of them you can fork out more processes of course, but a singular process will only be one executable thread at a time (with many possible I/O threads of course).
Heh, Mirage looks awesome, I’ve still yet to touch it but it always looks so enticing when I run across it. MirageOS is a microkernel made mostly in and made to run OCaml in a massively parallel way, whether directly on bare metal, a hypervisor, whatever. Think Nerves for the BEAM, but for OCaml, and even more low level and faster from my understanding.
Heh, there are quite a number of PPX’s that have basically become ‘Standards’ for projects nowadays I’ve been noticing… ^.^;
I’ve used so many of those weird protocols too! Using ASN.1 was a slight bit of a pain in Mix, had to write my own mix compiler to just call into erlang’s compiler even though erlang can already do it but mix’s erlang plugin ignores those definition files… >.<
Eh not really. Like take just one of its ‘base’ features, HKT’s, those are way complicated to compile and even more amazingly complex to do efficiently (which Haskell does not). Haskell is a very non-simple language, from choosing rather inefficient FP constructs as defaults (HKT’s, lazy-first, etc…) to horrible syntactical choices like significant whitespace… >.>
And then you get into ‘fun’ stuff like the GHC compiler extensions that about every Haskell program uses with impunity nowadays, some of which are not quite ‘type safe’.
Yeah I agree here, types in a language make debugging SO much easier. Debugging in Elixir can be an absolute royal pain at times, debuggers and tracing or not.
If it were then you wouldn’t require non-standard GHC language extensions to be able to do some types of work (of which, as an example, OCaml does not need).
Harder to Parse, harder to implement, harder to reuse code because of significant whitespace, lack of built-in code extensions ala OCaml Functors, etc… etc… etc… Doesn’t really seem ‘not complex’?
Monads aren’t just a haskell thing, they are a concept that ‘most’ languages anymore use with impunity, even if they don’t call them that.
Except depending on what the type of what you pass in is then sometimes it wouldn’t be lazy, and you wouldn’t be able to tell at the function definition site (without using compiler extensions). 
All valid points.
There is definitely a niche market for some enterprising Jose-Valim-type to clean Haskell up a lot, and make it look like Ruby 
The big picture remains. There are pitfalls, but it’s not the crazy beast ppl make it out to be
Which is perfect, IMO. As an end user (a polyglot app developer) I have no concept of the BEAM’s complexity and I don’t need to.
Cf. Haskell, Ruby, and git, which all but require a firm knowledge of the implementation details. For me, that’s important evidence of poor or unfinished design.
If only the basics were sufficient, I’d agree with you.
IMO, Practical Haskell is a morass of hacks and implementation leaks. Consider just a simple function invocation:
m n o p q
That syntax, which doesn’t differentiate between the function and the operands, is not a product of top-down design, but rather bottom-up implementation leakage. (The language being based on simple curried functions.)
Coding in Haskell often feels like JVM Bytecode - a syntax defined according to the needs of the underlying machine.
But my needs are different than the machine’s. I think at a higher level of abstraction. No files, relative paths, etc. Instead - interfaces, abstractions, classes, and objects (if OO). Smalltalk got this.
Funny that’s how I felt about Rust when I tried learning it this year! I enjoyed some initial experimentation after reading a good amount but when I started poking around pull requests, issues, RFCs and community posts, I got so confused and frankly intimidated by how much I couldn’t understand that I decided to drop it.
Elixir really is amazing in this way. It doesn’t take long to learn because the core of the language is just so simple. Yes there are a few small warts which take some learning but the language design itself is so easy to wrap your head around. Looking over the issues and pull requests on the Elixir GitHub, I can understand everything, and that is a powerful, and rewarding feeling. One that I think is undervalued in today’s world of many languages.
I’m completely with you. I have the same experience with the Haskell subreddit, r/haskell. I can’t understand most posts - they’re meaningless to me. Yet I’ve been writing apps with Haskell for years.
But that’s what I love about it…
Arguments and functions are somehow fungible.
Larger abstractions (e.g. Elixir behaviours) are just records with lambdas..
Etc. etc.
Maybe there’s a better balance to strike though.