
Elixir – The next big language for the web - laut
http://www.creativedeletion.com/2015/04/19/elixir_next_language.html
======
losvedir
As a rails developer primarily, and someone dabbling with Elixir/Phoenix on
the side, I get this feeling, too. It's taken the best of rails, dropped the
annoying parts (e.g.: weird pluralization stuff, magic connection between
instance variables in controllers and views, an explosion of path helpers
(Phoenix's approach is basically post_path(:index), post_path(:show, 5),
etc.)), and then put it on the rock solid Erlang VM.

I remember hearing the "genesis story" of Elixir. IIRC, José was working on
ensuring Rails was thread safe. He did so, but was dismayed with the
difficulty and felt like he was fighting Ruby. So he stepped back, and thought
that if concurrency is the future, he should find a better language for it. He
looked into immutable, functional languages (Haskell, Clojure, Erlang), and
realized that Erlang is built for an arguably harder problem: distributed
computing, and made the connection that concurrency is sort of a smaller case
of that. He worked with Erlang for awhile before deciding that it could be
improved by building on it.

Going through the Elixir tutorial and seeing how you could "simulate" state,
by spinning up an infinite loop in another process and sending messages to it
was mind bending. And learning about Erlang's OTP principles has made me
really think about robustness differently. I really do hope Elixir/Phoenix
become the next big language and web framework.

------
tatterdemalion
I don't know much about Elixir but it seems like a really interesting
language. The space it's trying to fit is definitely something needed: a good,
flexible, high level language like Python/Ruby but with strong concurrency
support and a functional paradigm.

Can anyone give more information on the nature of Elixir's type system?
Without digging into the docs I see elixer-lang says that its dynamically
typed, but how strongly typed, is it robust, does it have ADTs, inheritance,
etc?

edit: looking an inch deeper, I see that it has 'protocols,' which seem like
typeclasses, and 'typespecs,' which seem like gradual typing

~~~
ryanworl
For type-safety, you can (optionally) add what are called type specs to your
code with are processed with an analyzer tool called dialyzer [1]. This will
identify errors related to types, as well as a few other kinds of errors.

This doesn't work with Elixir directly, but rather BEAM byte code (Erlang VM)
which Elixir compiles down to.

[1]:
[http://www.erlang.org/doc/man/dialyzer.html](http://www.erlang.org/doc/man/dialyzer.html)

------
vezzy-fnord
_I think part of it is that with Erlang it is not as easy to get up and
running with a new website._

I'm doing this at present and there is no special difficulty.

 _And things like package management, build tools, meta-programming, unicode
handling and web frameworks are not as straight forward as in languages such
as Ruby._

Erlang's module system means that a chunk of the raison d'etre behind
language-specific package managers is already alleviated. The rest -
dependency management and building, is handled quite well by tools like Rebar.
One can also leave Rebar as a dependency tool strictly (which is its primary
purpose anyway) and use whatever they like for a build system. Plain old
Makefiles can work just fine, and it's not like most language-targeted build
systems aren't some shiny variation of make, anyway.

Metaprogramming isn't quite as easy as in many OO languages, but it's hardly
out of reach. The parser, the lexical scanner and other components are all
exposed as Erlang modules, and there are projects such as the BossDB ORM that
use parser transforms to provide features such as parameterized modules, which
allow for using Rails-like ActiveRecord patterns, among other things.

Unicode handling? I think this might be a knock on Erlang's string handling.
Strings are represented as iolists of Unicode points (integers) which goes
with much of Erlang's philosophy in lists and tuples as being the prime data
types. Space efficiency and real-world usage usually has strings passed as
binaries, but most web frameworks and libs can handle them plainly
nonetheless.

Web frameworks? Chicago Boss for a Rails-like, Nitrogen and N2O for real-time
and extremely high load applications, or even just plugging in to web servers
like Cowboy or Yaws can be enough for a RESTful backend.

~~~
pawelkowal
> Erlang's module system means that a chunk of the raison d'etre behind
> language-specific package managers is already alleviated.

Sure, modules provide a way to "package" functions, but that is 5% of what a
package manager does. Being able to distribute, fetch and do dependency
resolution is certainly the bulk of it.

I definitely prefer my deployments to rely on packages than fetching git
repositories from Github and Bitbucket. There are recent discussions in Erlang
mailing list regarding packages and the OTP team (the team behind Erlang) is
looking into package managers too.

> The rest - dependency management and building, is handled quite well by
> tools like Rebar.

Sorry, Rebar does not handle dependencies well. Rebar does not even guarantee
repeatable builds. Once I fetch dependencies on my machine, my co-worker can
end-up with versions different than mine and that is dependency management
101.

Rebar 3 seems to improve in this area but is still alpha. erlang.mk idea of
package manager is a file on github in tsv format (and still no repeatable
builds).

> Unicode handling? I think this might be a knock on Erlang's string handling.

Erlang needs better unicode support, regardless of using lists or binaries.
Strings support only latin1 in literal format. If I want to write my name as a
binary, it needs to be written as <<"paweł"/utf8>>. This is nowhere close to
acceptable to anyone that has to write strings in formats other than latin1.

Things are getting better in Erlang 18 but there won't be any conveniences for
handling unicode. There is no function to calculate the grapheme length
(essential if you want to support languages like japanese or korean and do a
size validation on an input), to convert to lowercase/uppercase and so on. Be
it if the underlying representation is a list or a binary.

~~~
pbowyer
> Sure, modules provide a way to "package" functions, but that is 5% of what a
> package manager does. Being able to distribute, fetch and do dependency
> resolution is certainly the bulk of it.

Please God the Erlang/Elixir community don't invent another package manager.
Pip, easy_install, gem, npm, composer, bundler, bower, maven and all the
others I don't know about - we've got enough as users to remember the
variations in syntax for. Let alone the duplication of effort in developing
and maintaining the package managers, when their clever creators could be
working on other problems.

~~~
yellowapple
You're too late ;)

Maybe someday someone will just create one package manager to rule them all,
one that's not tied to a specific language, but can instead manage anything
running on your computer.

Oh, wait.

------
pbowyer
Given some were touting Go as the next big language what - 12-18 months ago -
can anyone enlighten me why Elixir would be different to Go. Or where Go
didn't live up to its promises?

~~~
lectrick
Some of this is opinion, but I looked at Go and didn't like its exception
model (or total lack thereof). Checking for errors after every possible bit of
code that could go wrong seemed like an ugliness to me (disclaimer: beauty is
in the eye of the beholder, and I'm certain a Go guy will chirp up here in its
defense... which is fine!).

Elixir/Erlang almost couldn't be more different in this regard, which
basically embrace runtime failures (things fail, so... "Let it fail quickly").
An uncaught runtime error in Elixir/Erlang causes the node to shut down after
logging the error and, if it has a supervisor node (which is quite likely),
the node is restarted in a fraction of a microsecond. The developer is
expected to monitor the logs and watch for common faults and fix those. This
is in fact where the "nine nines" reliability comes from- restarting nodes
extremely quickly after runtime errors.

The Erlang philosophy is basically, "these systems exist in the real world,
which is sometimes unpredictable and flaky... accept it and allow the code to
move on quickly." This happens to be a good strategy for website code-
Remember that Erlang was built to run cell networks... How often are cell
networks down these days?

I was also a "disenfranchised" Ruby guy, tired of working on classes of bugs
that would never even see the light of day in a functional language, which is
why Elixir's syntax was appealing (I had already looked at Erlang, but I
didn't like its syntax). Again, there's taste and opinion here, of course.
Coding has become awfully fashion-driven, of late.

There's a class of programmers who don't care about syntax or don't see the
point of it. Ruby/Rails folks are _not_ typically that type of programmer, and
that's the first group who will likely migrate to Elixir.

Finally, what _really_ raised my eyebrows about Elixir was its macro facility
[http://elixir-lang.org/getting-started/meta/macros.html](http://elixir-
lang.org/getting-started/meta/macros.html) Prior to Elixir, full-fledged
macros were only a feature of homoiconic languages (the Lispy ones where the
syntax is also a data structure). Elixir came up with a clever way to do
macros, while retaining syntax.

~~~
pbowyer
Thanks, that's a really helpful answer.

> Again, there's taste and opinion here, of course. Coding has become awfully
> fashion-driven, of late.

I agree and that's a really enlightened view. But I'm quite glad - it means
the ecosystem is maturing if we now can be fashion driven, rather than having
to care about "does it work?"

~~~
lectrick
> Thanks, that's a really helpful answer.

I really like this language, I've met Jose Valim and he's a super nice, super
smart guy, as is Chris McCord. So I feel naturally motivated to promote it.
Also, it's just lots of fun to work with!

> it means the ecosystem is maturing if we now can be fashion driven, rather
> than having to care about "does it work?"

Well in my case, as I said, I got tired of certain classes of Ruby bugs, and
certain, shall we say, "uglinesses" which presented themselves, but only after
(sigh) YEARS of working with Ruby. In a way that's an argument FOR Ruby! It
will only start to look ugly years after you work with it. ;) More than can be
said for MANY other languages!

So far I haven't seen too much "ugly" in Elixir (which is good, as it _should_
be in the "beautiful bouncing baby" phase!). In fact, in some ways it's even
more Rubylike than Ruby is, such as with being able to define your own sigils:
[http://elixir-lang.org/getting-started/sigils.html](http://elixir-
lang.org/getting-started/sigils.html) And of course the macro facility is
pretty much the ultimate definition of Ruby's oft-touted "metaprogramming."
Chris McCord already has a book out on it, actually:
[http://smile.amazon.com/Metaprogramming-Elixir-Write-Less-
Co...](http://smile.amazon.com/Metaprogramming-Elixir-Write-Less-
Code/dp/1680500414?sa-no-redirect=1)

------
amarsahinovic
[http://elixir-web.github.io/weber/](http://elixir-web.github.io/weber/)

~~~
adamkittelson
I used Weber when I first got into Elixir a little over a year ago. It was a
cool framework and I even contributed to it (mostly keeping it up to date as
new versions of Elixir were released).

But... the last commit was 9 months ago. Weber is dead. If you're interested
in doing web stuff with Elixir today Phoenix is what you want.

[http://www.phoenixframework.org/](http://www.phoenixframework.org/)

~~~
yellowapple
Now would be a good time to plug Sugar, another framework for Elixir that's in
active development.

[http://sugar-framework.github.io/](http://sugar-framework.github.io/)

(disclaimer: I'm one of the collaborators on the project)

~~~
lectrick
Good luck! I think this is a great time to start a new Elixir framework, and
competition (or perhaps, "coopetition") is good.

~~~
yellowapple
Thanks! "Coopetition" is certainly the goal, I think :)

------
sergiotapia
I think the next big thing is Meteor. Here's why:

1\. Real-time baked in.

2\. Uses Javascript (tons and tons of developers know at least enough to use
Meteor)

3\. Sane templating engine.

4\. Same wow effect I had when I first started Rails.

5\. Fantastic build system.

Pheonix and Elixir may be the bees knees, but unfortunately because it uses a
functional language, it drastically cuts down the mindshare of developers. I
don't even know any developers in real life that use functional languages.
Looks interesting but that's the reality.

~~~
lectrick
> but unfortunately because it uses a functional language, it drastically cuts
> down the mindshare of developers. I don't even know any developers in real
> life that use functional languages.

1) Once upon a time, almost no one used object oriented languages except for
Smalltalk weirdos.

2) Ruby, javascript and a host of other languages have "functional" features.
Does your language have a "lambda" feature, where you can define nameless
functions and pass them around as arguments to other functions? Then you are
_already working with functional language paradigms._ There's nothing really
"magically hard" about it, you're overselling how hard it is. This is not
rocket science. Most existing programmers can handle it.

The hardest thing I had to wrap my mind around when switching my work to
Elixir was _letting go of mutable state._ And attributes and methods on
objects. And guess what... It seems that it's a good idea, generally!

If you see enough bugs that are only there because something modified an
attribute in some unpredictable way which impacted upstream code... You will
realize mutable state is bad.

If you still aren't convinced that mutable state is evil, watch this Rich
Hickey presentation [http://www.infoq.com/presentations/Are-We-There-Yet-Rich-
Hic...](http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey) which
basically proves that mutable state actually makes state a function of a
hidden/conflated "time" variable, proving it's not just wrong from a practical
standpoint (in the form of extra bugs that are hard to reason about, and all
this brittle mutex code) but from a theoretical one, too. Mutable state comes
from a time when memory was expensive, and it's time to ditch the training
wheels so we can get the real work done.

Both Javascript and Ruby use mutable state extensively, and it's unfortunately
not something you can just slap onto the language after the fact (although
ClojureScript must make a valiant effort!) And if the high-level language
wasn't built with it from the get-go, then you're stuck dealing with legacy
libraries using the poorer-written code (see: Ruby gems).

~~~
ab5tract
Right...

Another fad brought up for the sheer fashionability of it.

Saying "mutable state is bad" is just as inane as saying "immutability is
bad". There are tradeoffs for either. There is absolutely no reason to pretend
that one trumps the other in all cases.

Other than looking cool to your peers, I guess.

~~~
yellowapple
Nobody's "pretending" that immutability trumps mutability. Rather, we're
observing it firsthand. By making immutability the rule rather than the
exception thereof, one eliminates a huge swath of bugs and makes an even
bigger swatch much more difficult to achieve.

That said, you're right that there are tradeoffs, which is why languages like
Rust - while defaulting to immutability - allow a programmer to define
variables as mutable, and why Elixir (unlike Erlang) allows variables to be
reassigned (though the data stored _in_ those variables is still immutable;
this is something that's enforced by BEAM).

And of course, you can still get many of the benefits of immutability with
mutable variables by being careful about how you're using those variables; the
difference, however, is that a language which assumes immutability will be
able to catch those bugs more easily, forcing the programmer to fix them
(either by making the variable mutable (in applicable languages) or
refactoring until mutability isn't necessary).

------
cgag
Does dialyzer work with elixir?

~~~
lectrick
"Elixir Sips" is a nice little screencast site showcasing and howto-ing
various Elixir features. They have an episode on Dialyzer:

[http://elixirsips.com/episodes/125_dialyzer.html](http://elixirsips.com/episodes/125_dialyzer.html)

------
ksec
I thought Erlang was abandon within Ericsson, and it was Open Sourced so
people can continue to use it. Can anyone explain what is Erlang Public
License? Why not something like Apache, GPL or MIT?

~~~
yellowapple
> I thought Erlang was abandon within Ericsson, and it was Open Sourced so
> people can continue to use it.

It was temporarily "abandoned" because Ericsson had (has?) a policy forbidding
the use of non-free languages. In response, the Erlang devs open-sourced it,
and now (IIRC) it's not banned anymore.

> Can anyone explain what is Erlang Public License?

It's derived from the Mozilla Public License. It differs mainly in terms of
legal jurisdiction (i.e. Swedish law being specified as the applicable legal
jurisdiction).

> Why not something like Apache, GPL or MIT?

Good question. The answer's probably similar to the reasons why Mozilla
created the MPL (partial copyleft, in contrast with the GPL's strict copyleft,
and with the Apache's and MIT's and BSD's and crowd's copycenter/copyfree).

------
filereaper
I've been monitoring Elixir on HN for a while now, looks like an interesting
direction to take.

I wanted to know which direction Elixir is going to take? Will Elixir be
mostly compatible enough with Ruby so that Rails can run directly off on
Elixir?

Is there a plan to change Rails enough to run on Elixir?

How does the community feel about Elixir? I'm certainly interested in the
concurrency aspects of Elixir (ie. no GIL) and everything else that Erlang has
to offer.

The developers of Elixir were core Rails developers so please forgive me if
I'm getting the wrong impression here.

~~~
dragonwriter
> I wanted to know which direction Elixir is going to take? Will Elixir be
> mostly compatible enough with Ruby so that Rails can run directly off on
> Elixir?

Elixir is not even approximately compatible with Ruby, nor is it intended to
be. It just has syntax that is _very loosely_ reminiscent of Ruby. Someone
might one day write a Rails-like framework for Elixir, but it will never be
the same Rails that runs on Ruby.

OTOH, if you want something no GIL that can run Rails, there is always JRuby.

------
pron
Not about Elixir specifically, but don't people get tired of switching
languages? What, people will now have to port all Ruby libraries to Elixir
(or, at the very least, relearn them), and then a few years down the line to
the next thing? Isn't this a huge waste of effort? Not to mention the poor CTO
who gets a job at such an early-adopter company in 15 years, and finds out the
codebase is made up of 7 different languages, four of them have been defunct
for years? I mean, a language's benefit must _at least_ cover all the
switching costs, the fractured codebase costs and then some to justify
adoption. Are all the new languages such huge advances over older ones that
they do that?

~~~
yellowapple
> Are all the new languages such huge advances over older ones that they do
> that?

I don't know about other languages, but having personally migrated from Perl
and Ruby to Erlang/Elixir, I at least believe that to be the case in that
particular circumstance.

A big part of it is that parallel programming is starting to catch on as
mainstream rather than something to be shunned or avoided; whereas in the past
folks were conditioned to avoid having to deal with threading or forking
because of having to think about thread safety, there are now languages like
Erlang (and its kids Elixir and LFE), Rust, Go, Scala, Julia, etc. that are
meant to make parallel computing easier to reason about or less dangerous (or
sometimes even both).

On top of this, though, Erlang-and-kids' reliability features allow them to
achieve the legendary "nine-nines" of uptime (99.9999999%) relatively easily
(I say "relatively" because - while you certainly still have to think about it
(particularly if you're trying to push a change to, say, how data is
represented on the (D)ETS or Mnesia or CouchDB or SQL or whatever side of
things) - it's much easier than with a lot of other languages). That level of
availability has _huge_ implications for a company's bottom line, particularly
those companies that measure downtime in "thousands of dollars per second"
instead of just seconds. A well-written Erlang/OTP (or Elixir/OTP or LFE/OTP
or anything/OTP) application can do this on the software side rather
effectively (on the hardware side, you'd still want redundancy wherever
possible/feasible, including on the network side of things; most well-run
hospitals, for example, will have connections with at least two different ISPs
so that if one goes out, they still have the other, and will only lose
connectivity in very extreme circumstances).

In the case of Elixir, it makes for a very solid migration target from, say, a
Rails codebase; the syntax is a bit more modern (I personally prefer Erlang's
in many cases, but Elixir's pipe operator is a godsend) and familiar to
Rubyists ("do" blocks, more flexible pipelining with the |> operator, etc.),
while being fully compatible with the existing Erlang and growing Elixir
ecosystems.

~~~
pron
Don't get me wrong, it would be great if all Ruby developers switched to
Erlang/Elixir, but what next? I mean, does switching a language more often
than once a decade result in net benefit to the industry or net loss? I fear
it's the latter.

~~~
yellowapple
It depends on how drastic the switch is.

Most of these switches are driven by a shift to some new programming paradigm.
We started with procedural programming, then made a big shift to object-
oriented programming, and now we're starting to see a big shift toward
functional/declarative programming. Who knows what'll be big next?

If this happens too frequently, then there are certainly going to be problems,
yes. The current trend, however, indicates that it's not happening too
frequently, at least not yet; the current shift from object-oriented
imperative to functional/declarative programming (with some object orientation
here and there, though this isn't very pronounced in Erlang and its family
tree) seems to be by necessity rather than adopting shiny for the sake of
shiny, and I think that's what makes the difference here.

Basically, the more dramatic the switch is, the more likely the switch to be a
net gain rather than a net loss, since it indicates that the switch was truly
necessary. Switching from Python to Ruby, for example, would be a net loss,
since - while they have different syntax and in some cases different
programming styles and ecosystems - they're both imperative scripting
languages and you're not really changing all that much besides a bit of syntax
and semantics. Meanwhile, a switch from Python to Haskell, for another
example, is more likely to be a net gain, since you wouldn't even consider
that switch unless you felt the need for the massive paradigm shift that's
required to make such a switch.

As a disclaimer, my claims above are mostly conjecture, though I think they
correspond well with reality, at least by my own observations.

~~~
pron
> Most of these switches are driven by a shift to some new programming
> paradigm.

Most of the switches should be driven by one thing, and one thing only:
reducing the cost of software development (or increasing the quality, which is
really the other side of the same coin). Whether a new programming paradigm
actually achieves that or merely advertises itself as achieving that is the
cause for the very high churn in fashion-driven SV and low churn elsewhere
(where people are actually interested in cost reduction only).

> the current shift from object-oriented imperative to functional/declarative
> programming

As someone familiar with the software industry, I can tell you that there is
no such shift happening other than in the minds of some wishful-thinkers. Are
functional concepts being adopted by OO languages? Sure! (although Gilad
Bracha would tell you, correctly, that most of these concepts were already in
some OO languages -- i.e. Smalltalk -- long before people in the industry
started using the term FP). But people aren't really switching languages
outside those sectors that have made switching languages every few years a
lifestyle choice.

> Basically, the more dramatic the switch is, the more likely the switch to be
> a net gain rather than a net loss,

I completely agree with that.

> since it indicates that the switch was truly necessary.

But not with this. Dramatic changes do have the _potential_ to make a dramatic
impact, but 1/ they rarely do, and 2/ when they do, it's mostly in the runtime
-- not the language. Erlang is certainly an excellent runtime that has a big
impact (though personally, I prefer the JVM, which can do anything BEAM does
only better), but Haskell? Haskell is a very, very unproven language. I
remember that about 15 years ago everyone was talking about it, saying how
it's going to be the next big thing. 20 years into its existence, though, the
largest single Haskell program is still its own compiler, which is not
particularly large. The truth is that nobody really knows Haskell's actual
benefits (in terms of real impact to project development) because in twenty
years no one has tried to actually use the language for anything big (and
small projects are usually cost-effective in any language). Its impact could
be great but it may well be negative. Nobody knows. So if anyone tells me
they've switched to Haskell out of _necessity_ , I call BS.

But switching to BEAM is always a good idea (sooner or later) for large
projects (unless you're already on the JVM), although if you're making the
switch, I'd advise on the JVM, as it's a safer bet (both in terms of future,
as well as likeliness of addressing the needs you may actually face; BEAM is a
slow runtime, and many Erlang shops rely on C for important parts of their
code).

~~~
yellowapple
I agree with most of your points. However:

> though personally, I prefer the JVM, which can do anything BEAM does only
> better

In my experience, this couldn't be farther from the truth. Java's threading
model is bloated and slow compared to Erlang's process model, and that process
model - the ability to spin up processes so lightweight that they make even
Java threads look heavy in comparison - is the key to its success when it
comes to parallel and distributed computing.

Now, this isn't to say that a JVM implementation can't do the things BEAM can
(otherwise, projects like Erjang wouldn't exist), but I've found Erlang
applications with BEAM to perform far better in that domain. This isn't
particularly surprising, seeing as BEAM was designed to run declarative,
distributed, concurrent languages (like Erlang and eventually Elixir and LFE
and the like) right from the start, whereas the JVM, .NET CLR, etc. were
originally designed for imperative languages (like Java and C#, respectively)
and have been gradually adapted for fuctional/declarative programming (like
with Scala or F#, respectively).

> no one has tried to actually use [Haskell] for anything big

Maybe because the equivalent Haskell codebase to a "big" project in most non-
declarative languages ends up being "small" in comparison? Or are you talking
about importance?

~~~
pron
> the ability to spin up processes so lightweight that they make even Java
> threads look heavy in comparison - is the key to its success when it comes
> to parallel and distributed computing.

Except you can do the same in Java -- see Quasar or Erjang -- the JVM is so
powerful that true lightweight threads -- just like Erlangs -- can be added as
a library.

> I've found Erlang applications with BEAM to perform far better in that
> domain.

I've found the exact opposite. Java with Quasar fibers handily beat Erlang
code. The more actual work being done, the bigger the difference (BEAM is
excellent at scheduling, but pretty terrible at running user code; it's
notoriously slow, which is why all important Erlang library functions are
implemented in C, and why heavyweight Erlang shops do a lot of C coding; when
you do Erlang, it's often Erlang _and_ C if performance is important).

> whereas the JVM, .NET CLR, etc. were originally designed for imperative
> languages

So was your machine, yet BEAM runs on it just fine. You can like the
imperative style or not, but it's more general than the functional one when it
comes to implementations on real hardware. BEAM runs on an imperative, shared-
state machine, and creates a nice abstraction. You can do the same on the JVM
without loss of generality, and, as it turns out, with a nice boost to
performance (because HotSpot's JIT and GCs are state-of-the-art). The only
advantage BEAM has over the JVM (or at least HotSpot) is a better level of
isolation between processes (i.e. it's a bit harder for one process to impact
the performance of another, because they have sort-of separate heaps). But
again, BEAM is a fine, beautiful runtime that is perfectly suitable if you
need good concurrency but aren't worried about processing speed.

> Maybe because the equivalent Haskell codebase to a "big" project in most
> non-declarative languages ends up being "small" in comparison? Or are you
> talking about importance?

Well, both. Haskell has never been used to write a large ERP, airport
management system, manufacturing automation, an air-traffic control system,
device drivers, an OS, a database, a banking system or a large social network
-- take your pick. It may have been used to a small extent for some specific
projects in banking, but that's about it. The only large, complex,
"interesting" from a cost estimation perspective ever written in Erlang is its
own compiler (and possibly other compilers). Now, I may have missed one or two
specific projects, but their rarity only demonstrates the problem. Go, a much
younger languages, is already more battle-tested than Haskell and even Go is
far from being truly battle tested, so this says a lot.

~~~
pbowyer
> (BEAM is excellent at scheduling, but pretty terrible at running user code;
> it's notoriously slow, which is why all important Erlang library functions
> are implemented in C, and why heavyweight Erlang shops do a lot of C coding;
> when you do Erlang, it's often Erlang and C if performance is important).

That's really useful to know - I'd not heard about this before, only that
Erlang was fast!

~~~
pron
Erlang is actually quite slow; it just responds quickly and has excellent
concurrency. The programming language shootout places Erlang HiPe (high
performance) at 2x-22x slower than Java
([http://benchmarksgame.alioth.debian.org/u64q/erlang.html](http://benchmarksgame.alioth.debian.org/u64q/erlang.html))
and sometimes faster and sometimes slower than Python
([http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=hipe&lang2=python3)).

That's why Erlang is often used as the application control plane, routing
requests and the like, while actual data processing is done in C.

------
JustSomeNobody
This isn't a criticism of Elixir (I've never used it, so I can't do that), but
how can one just declare something "The Next Big" thing?

~~~
davidddavidson
Did you read the article? The first sentence is literally:

"In this article I will explain why I think the Elixir language will make a
big impact in the world of web development."

~~~
JustSomeNobody
That's called backpedaling.

