Elixir – The next big language for the web

> 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).

No it is not how it looks it is that the documentation is lacking. The quick start didn't work for me. If it had been a simple page returning HTTP code 200 that just said OK, it would at least be something.

Sure you can make it work if you invest more time in it, but the point is that there are other platforms that have taken care to make it easier.

In general a lot of people seem to think that documentation is one of the biggest issues with Erlang.

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).

> 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.

I like Meteor and have been learning it but it's not without it's drawbacks. It's basic design of loading a javascript app which then receives data from the server and renders the page makes load times kind of sluggish - compare HN and https://crater.io/ which is Meteor's HN equivalent. I've yet to find a Meteor site that's snappy. Also the design makes things like uploading photos a pain. If you look at the user pics on crater.io they are hosted on Twitter and Wordpress I think partly because doing that on a Meteor server is awkward - I've been writing a Meteor photo uploader and it can be done but most Stackoverflow answer suggest to give up and use S3. I wish them luck though.