I hear a lot about OTP and the "let it crash" mantra, but I just don't quite understand what's so great about it. Maybe it's just due to my problem domain (web development), but it doesn't seem like as big a draw to Elixir and Erlang as pattern matching and FP are.

Because it matches the reality better. Concurrent applications built out of individual isolated processes often map well to real world problems. Not all problems, but quite a few of them. Say if you just multiply a matrix or maybe calculate an average, you don't need concurrency and supervision. If you want to sort a list of files, you don't need etc. Not all systems have to be reliable and fault tolerant.

> Making everything asynchronous and detached makes things more complicated, not less.

The real world is asynchronous and detached. You as an agent are detached from other co-workers or friends. Before you take a breath you don't have to wait for them to finish taking a breath. A car driving down the street is detached from others. They come to an intersection and have to work together in order not to run into each other. But after that they keep going on their way. Also they are fault tolerant -- because your neighbor's car engine crashed, doesn't mean yours should stop working. Seems a bit like a silly example but that maps fairly well to distributed computing -- requests, user connections, work processes, items in a processing pipeline, database shards and so on.

So given that there are these types of problem what framework language should you pick to solve it? I would say first of all one which reduces the impedance mismatch and lets your write clearest, simplest code. And also that one that's most fault tolerant.

You could spawn threads (or green threads) in some languages -- but you'd probably be sharing memory and have some bugs in there. You could spawn OS processes and/or have multiple containers/vms in the cloud, but that gets expensive. You could use Rust for example to achieve some of those goal though, because it will guarantee to a certain degree during compile time that your application will have less memory and concurrency errors. Or you could use something based on the BEAM VM (Erlang or Elixir) for example, and you get a different approach to fault tolerance there.

I think the idea is that if you start with phoenix you don't have pay that cost unless you need it. If you end up needing to scale, the features are there. I think Uncle Bob said once that "architecture is the art of delaying decisions". Phoenix / Elixir let you do this.

Another part of the story is channels. If you're doing websocket work, you can't find a better platform than phoenix / elixir.

Once you start digging in, you realize phoenix / elixir are awesome even if you're not using all the concurrency / distribution stuff. The functional nature / immutability posture of elixir helps you with a large code base and/or lots of devs. There are other features -- pattern matching and macros come to mind -- that make Elixir a great place to code.

All that said, if you have a client, say, with modest needs that is never going to have much traffic, all that might not be worth going with something you're not familiar with. Similarly, if you're talking about a 1-2 dev project, it might not worth learning something new. In those cases, maybe it's rails or django or whatever ftw.

That's been covered pretty well by other commenters, but it seems like it's something you have to experience yourself in order to really understand.

I understand that some people (especially those with a Ruby/Rails background) find Elixr/Phoenix more familiar. But is there more going on here than syntactic sugar?

If it's ultimately a BEAM application, I'm guessing that Elixr can't do anything that you can't do in Erlang, is that wrong?

Phoenix builds and improves on years of web framework iterations from Rails. They did a lot of things right there, but they are hampered by the limitations of the Ruby language.

Elixir is Erlang but nicer. While erlang is awesome (I write it every day), it's still a bit of a clunky language that could be much more elegant.

But I hear what you're asking. I'm not really familiar enough to answer, but I've seen plenty of articles that say it's more than just a familiar syntax, e.g., http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syn...

You can write any algorithm using any Turing-complete machine, including the original tape-based Turing machine or a language like Malbolge. But it is going to take an inordinate amount of time to write and debug.

What FP and message passing buy you is the ease of reasoning. No shared state -> no problem of concurrent updates. No state at all -> no questions like "but does this method update that instance member?". All your state lives in message queues and call stacks, and both provde very stringent and easy-to-understand disciplines.

This also gives you composability: you have easy time putting things together and rearranging them as you see fit, without caring of any hidden data dependencies. Everything is explicit.

(Combined with a static type checker and a right type system, it gives you the effect of "if it compiles, it runs correctly 99% of times", seen e.g. in Haskell or Rust. Elixir is not a statically-typed language, though.)

Yes, it does sometimes come at a cost. Not all immutable data structures can be made as efficient as mutable ones. Usually they are as fast as mutable ones, but pay some space cost; IIRC it's theoretically proven that the cost is no more than a logarithmic one.

With RAM being so much cheaper than developers' time, it's a rather good tradeoff. At least, using JIT in Java or Javascript, or just using Python and Ruby, one usually pays a similar or higher RAM cost, for a fraction of benefits. JS does move towards immutability and FP-ness, though, because the above applies to it, too, and it's not so OOP-heavy as for make FP approaches largely impractical.

I don't think this is true. Clojure uses immutable persistent data structure under the hood, just as most functional languages do, and devs often jump through hoops to circumvent them for performance reasons, opting instead for bit bashing like most other languages.

An immutable data structure representing an array is definitely much slower than a mutable array (a contiguous piece of memory).

Usually != always, unfortunately :(

This might be true, depending on what type of processing you're doing, and if you have a good garbage collector.

Of course, if you're allowed to use mutable trees, then you should just use a hash table which will be faster both asymptotically and in practice.

In the paper A Note on Distributed Computing, Waldo et al argue that having a distributed object system is bound to fail no matter how hard one tries.

  Differences in latency, memory access, partial failure, and
  concurrency make merging of the computational models
  of local and distributed computing both unwise to attempt
  and unable to succeed.
  ...
  A better approach is to accept that there are irreconcilable
  differences between local and distributed computing, and
  to be conscious of those differences at all stages of the
  design and implementation of distributed applications.
  Rather than trying to merge local and remote objects, engineers
  need to be constantly reminded of the differences
  between the two, and know when it is appropriate to use
  each kind of object.
  

BTW, the language can be used in a synchronous context. It works just like another functional language with all code executing from start-to-finish on a single thread of execution.

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7...

The top two for me are:

(1) you start to just program the sunny path. It's faster and more fun to code in this mode. And with pattern matching of function arguments and return values (as well as guards) and you get pre- and post-condition asserts all while programming the sunny path.

(2) What are you supposed to do when your system raises an run-time error anyway? I think in practice, in the majority of cases simply restarting your process in some known state is the best you can do.

And that "start in some known state" is non-trivial for a system that handles concurrent inputs. OTP helps you do that correctly.

Edit: Formating. Add note pattern matching of function args and guards.

Phoenix is quite popular but if you look at the source, it's a testament to Elixir's power as a language how light it actually is, the meatier bits are mostly around working with real-time connections, the cookie-cutter web stuff you can achieve with plug with very little work.

Basic state storage in between requests. Maybe you're building a simple shopping cart application, or maybe something more complex like a SurveyMonkey-style form builder. Each time someone makes a web request that modifies this state, you're storing that state somewhere.. but it's usually somewhere outside of Ruby. Maybe postgresql, maybe redis. If you were using Elixir or Erlang that would still be an option, but another option would be to use a process to store this temporary state. When the user adds things to the cart you send a message to the right process and let it know. This can keep all your code in one system (BEAM), so fewer moving pieces, easy to unit-test the entire thing in ExUnit, and potentially more efficient since there's no I/O to some other database. Then you can continue to save your truly long-term data in postgresql, so for example user accounts and sales made.

Another obvious use-case is not needing to have background workers like resque or Sidekiq. When I was doing Rails stuff I found myself doing tons of stuff in Sidekiq workers when I wanted to get the work off the request-response cycle. Sidekiq was great, and it improved things hugely.. but in Elixir I get all that for free with processes. Want to send an email? Have an email-sender process running and just send it a message. Want to do some fancy image processing, or even just thumbnail generation? Just have another process do it asynchronously. And once again, it's all inside the same code base and it's all super easy to unit test. And once again it makes your system simpler because you don't have another system process to deploy and manage.

Running processes in parallel is cheap in Erlang, so you can run hundreds of thousands of them in parallel on a commodity servers. Generally, if you are running any sort of high-traffic service with a lot of dynamic stuff happening, there are probably parts of it that Erlang/OTP can help make more efficient and easier to maintain.

[0] http://ferd.ca/the-zen-of-erlang.html

There are a lot of very good, very simple ideas in the Erlang ecosystem, it seems.

But that said, for where Erlang shines - backends and distributed services - first-class concurrency is damn near a must-have these days (see: Go, Erlang, etc. recent surge in use and popularity).

I ended up with Go, but had I more time to learn Erlang (or Elixir was 1.0 when I started looking) it would have been a solid contender.

Also, don't discount the incredibly solid and robust BEAM VM. If you are writing distributed services or servers (see: Riak, RabbitMQ) the overhead for spinning off "instances" or "processes" within the VM is virtually zero-cost, and in production systems has like sixty-four 9s of uptime. [0]

[0] ok, nine, but still: https://pragprog.com/articles/erlang

The idea of composing individual applications and programs sounds very powerful, and I like the idea of using it as a way to compose programs written in different languages together (a Rails server talking to a Clojure ML service that uses Rust bindings to do hardcore number crunching, for example). That could be interesting. I don't know what I'd use it for, though.

What? If you don't need concurrency in a web app that means that your app can only serve one client at a time and other clients have to wait in line. That won't scale to more than a couple concurrent users.

You're right that microservices don't make sense for every web app. Especially when you're still figuring out product-market fit. But once you achieve a certain scale (both in number of users and number of developers) microservices/SOA starts to make a lot more sense.

And that's an area where the Erlang VM really shines. Erlang's concurrency model is awesome and fits really well with the hardware evolution to more cores: lightweight processes, immutability, message passing, location transparency, etc.

I do think Elixir and Phoenix have a lot of value because Phoenix has the "get shit done" factor of Rails and yet still allows for your application to scale once you've entered the market, and you don't have to drop everything and move to a more scalable language/architecture and slow down. Plus, Elixir's features and syntax make it a lot more accessible than Erlang.

That's interesting considering the reason Phoenix was made is because the author was having a lot of trouble doing concurrency in Ruby.

I'm the author of Sidekiq and not trying to debate; I'm simply ignorant of how Erlang, BEAM and the ecosystem solve these common problems, which usually persist no matter which language you use.

    %% ping a remote node to connect to it
    pong = net_adm:ping('foo@127.0.0.1'),
    %% start my application on the remote node
    _ = spawn('foo@127.0.0.1', application, start, [my_app]),
    %% my_app is a gen_server, an otp process that abstracts
    %% async request/response and makes it look more like
    %% synchronous function calls
    %% this example assumes the gen_server accepts the JobArgs
    %% and immediately returns 'ok' as acknowledgement, but does
    %% the work asynchronously
    ok = gen_server:call({my_app, 'foo@127.0.0.1'}, {do_some_work, JobArgs})

this example assumes you're uninterested in the responses, but if you wanted to receive the results you could either send a pid (process identifier) along with the request that would be setup to collect the results and do any further processing or you could spawn a local process that made the actual call and blocked until it received the results

as for scheduling a job a week in the future, the naive way would be to setup a timer that, when it expires, spawns a process that can execute an arbitrary function. no one would do this, normally, however. you'd probably want to use something like sidekiq that can store the job off node and poll regularly to see if there's any jobs you should run

It doesn't have a scheduled job API yet, but there is a note in the readme that explains how to do this with quantum-elixir: https://github.com/joakimk/toniq#how-do-i-run-scheduled-or-r....

Start the processes that execute the code, get notified when they are finished. Literally a couple of lines of Erlang/Elixir. Not some large framework that does all that for you, it's in the language. It is built to run a lot of tasks in parallel and across many machines.

> How do you schedule a job to run in a week?

Like anyone else, put it in some permanent storage like redis. You can also keep it in memory, you can also use mnesia which is a distributed database that comes with Erlang.

  my_list_of_job
  |> distribute_tasks() 
  |> Enum.map(fn x -> Task.Supervisor.async(x, my_list_of_job) end)
  |> Enum.map(fn x -> Task.await(x, your_timeout) end)

There is a long running project to work on that to produce a nice job queue lib on Elixir Slack but noone on the interested group have time for now.

To schedule a job to run in a week you have a couple way. An easy first approach is to use Process.send_after/3 to send yourself a message after a week and handle that message in a week. Of course if you want persistence, etc, you will have to do it a bit differently, but not so much....

edit : now use the fn form instead of the shorthand & for ease of comprehension for non seasoned Elixir devs

I heard that Erlang/OTP (and thus Elixir) can transparently distribute work no matter where it gets physically executed but I'd just love to see an example -- freely accessible code, demo site, everything.

It does in languages like JS because they're not built for it. Elixir programs on average don't look very complicated.

In other words, you haven't run into one of the main problems Erlang and Elixir aim to solve. So it makes sense you don't see the appeal.

Just keep it in the back of your mind, when you someday do need to pull off a complicated network, Erlang and Elixir are excellent tools for solving that problem.

This is how it makes fanboys of people in their 30s, 40s and 50s instead of their 20s.

https://speakerdeck.com/mosic/elixir-at-evercam?slide=6

Make more sense now? :) (in addition to the other responses)

tl;dr Evercam replaced Node.js, Sidekiq, Pusher and Upstart with Elixir, huge net gain in stack simplicity which is arguably a strong plus from a long-term maintenance perspective.

In fact, Mike Perham himself (the creator of Sidekiq) is asking the question how do you do scheduled future background processing in Elixir, right in this thread: https://news.ycombinator.com/item?id=12072359

OTP is actually a lot lot faster than you'd expect and allows you to use all CPUs very simply and also provides network transparency (on top of supervisors and "let it crash").

Plus, having reliability and coming back up if it goes down doesn't solve the root problem, which is that there's a bug in the code, or some sort of unhandled edge case. 99.9999999% uptime doesn't help if your code doesn't work right.

...or did it? Eventually, we noticed instances of the app locking up, not responding to any request. There was no obvious error, it just kept running but did not log or do anything. It turned out to be due to the callback bug: the exception was being caught alright, but we were leaking file descriptors like a sieve and eventually running out. Due to this a minor bug affecting only some requests was able to take down the entire app.

That's the kind of problem Erlang solves well. Every request runs in its own lightweight process. The process can open (and thus own) files, sockets, OS processes, in-memory DB tables, etc. If the process crashes or dies for any reason, its memory and any other resource it owned gets cleaned up by the VM. If the process tries to hog the CPU or even enters an infinite loop, the preemptive scheduling means other requests will still get a chance to run.

In short: having strong isolation between processes means it's unlikely for a bug in a minor feature somewhere to affect the overall application health.

Programmer wakes up next morning, comes to work, reads the exception log, fixes this edge case, optionally hot-upgrades the code in production if it's easier than doing a full restart, problem solved.

Other frameworks have to carefully implement the same semantics (that is, prevention of propagation of bad state/cascading failures). Elixir/OTP/Erlang come with it by default, and coding style encourages it.

Yeah but you don't have to wake up at 4am in the morning to fix the problem if the system stays up and still works (even if a bit slower or some feature is degraded). I've seen systems that had parts crashing and restarting for a weeks and months. Yeah it is bad nobody noticed, but it was secondary service that didn't affect most users. Having the backend with an exception or segfault because if it would not make sense.

> Don't we have modern frameworks and systems now that can tolerate individual failures instead of completely dying just because someone tried to POST some bad data?

Yeah we do. Nothing Elixir does is magic or absolutely impossible with other systems. You can spawn an OS process to handle a request. Can have a load balancer or something to check the health of backend nodes, and redirect. Or wrap everything in exceptions and try to restart and so on. It is kind of doable. But now there are multiple libraries, frameworks, services to also maintain and look after, maybe that thread just crashed made a mess on the heap and now maybe restarting don't really fix the problem. So doable, but more awkward.

> Plus, having reliability and coming back up if it goes down doesn't solve the root problem,

Obviously, nothing will write the code to fix the problems except the programmer. Is it worth to completely crash the system because some bug in one thread or some unimportant component failed? It is a bit like having a human drop dead the first time they scratched their finger. Yeah they can't write as fast for a while, but they can still largely function.

I mentioned Rust in another comment. Perhaps you'd prefer to have the compiler check correctness, that's very reasonable, something like Rust or Haskell might be what you'd like to use to sort of ensure you have less bugs when the system runs. Higher level of proof of correctness are possible, that is done for avionics software, crypto and other life-critical systems. So it is a continuum there. But there usually dollar signs attached to it.

Someone posting bad data may or may not be expected. The primitives are such that you can _choose_ how much or how little supervision you want, for a given complexity or maturity of a project, or what you learned as users put the system through the wringer. This is a _choice_ you make as an engineer, and OTP makes it easier for you to make such a tradeoff. Other systems and framework do not necessarily let you make such a tradeoff as gracefully.

This not only allows the software to scale gracefully with the number of users, this allows the software to evolve gracefully in complexity and maturity.

Overhead you are talking about can only be mental as processes in Elixir are very light. I think compared to other similar languages, at least for me Elixir doesn't require as much overthinking. Now, you could also say that I wasn't working on complex apps with it, so that might be why.

Anyhow, this is my view.

However, let's take Ruby on Rails as an example. I have gotten MVP-quality software out in production. We can quickly validate whether this is something customers want. However, when the app starts getting traction, I have found that I need to reach for things outside a RoR monolith. Usually, the first thing is getting some kind of background processing job going, with Sidekiq and Resque.

At this point, we have shifted from a synchronous, no-shared-state architecture to one that requires background processing. This is where we start thinking in terms of concurrency and how to deal with it.

Since Rails is built on top of Ruby, Ruby does not have a sufficiently robust concurrency primitives that work well at scale. To use something like Sidekiq, we rely on using Redis. I have had projects where I need to pass data through a series of background jobs, like a pipeline. Now I am implementing what are effectively mutexes as a database column. I'm processing data that are effectively being streamed from third parties, so each individual Sidekiq job now has to have guards so that it can be idempotent. I have to be mindful of queues, analyzing where the bottlenecks, and how to structure the queues and tune how many of what kind of jobs should get resources. I have had to rely on outside monitoring solutions to make sure these processes stay up and running, and write things in a way so they can still recover on restart. I had to fork Sidekiq and rewrite core parts of it in order to create a different set of guarantees to fit a use-case -- a big deal to every Rubyist I had talked to, and yet, seems normal in the Erlang world.

In other words, in the Rails world, concurrency is handled in a very coarse-grained way, often relying on software outside of Ruby (such as Redis).

I found myself reinventing, in a very crude ways at a coarse-grained level, what OTP already offers. I adopted subversion and later git because I was crudely reinventing version control (shell script and tar); I dropped PHP and Perl CGI scripts in favor of Rails back when Rails was version 1.1 because I knew what a project that doesn't use what Rails offers would look like (a messy puddle). And likewise, now that I've found myself badly reinventing ideas OTP already has, it's the tool I'll reach for now.

With Erlang and Elixir, it is easier to reason with concurrency because the primitives are baked in deep, and it costs little to spin up something asynchronously. Reasoning with concurrency in the Rails world is treated more like black magic -- obscure, non-obvious, forbidden, potentially dangerous, and socially unacceptable.

Now however, I am regularly mad at Rails (and somewhat at Ruby; 10+ years should've been enough to adopt a proper concurrency model, or something close to OTP) and I am finding myself almost constantly working around imperfections. Sooner or later the question of "am I using the right language and/or framework?" was bound to become relevant.

That seems like the perfect domain for this, to me.

HTTP is (traditionally) stateless. So, in the past CGI apps were independent entities. Every new hit was a new world in which the app ran. And, every interaction between each CGI app happened via a standard communication medium (a database or writing to files rather than messages, but if you squint and don't look too closely, you might see the analogy there). There are negatives to that...but, there are real benefits, too. That provided a tremendous level of flexibility in how apps were built and in how they interacted with each other. I'd argue that in some regards (though certainly not all), going to an always-on appserver model was a step backward.

So, to me, in some ways Elixir looks like CGI, only without most of the negatives of CGI. A lot of the mental overhead, like parsing parameters and setting up database connections, can be abstracted away with a modern/fast language designed just for this kind of work. And, the end result is a robust system without a lot of mental overhead other than learning the abstractions and how they interact.

You call out supervisors and message passing and the like as being negatives; complexity you don't want to have to deal with. But, you aren't really comparing apples to apples. Node.js is also asynchronous, and in its bare state is a mess; callbacks are vastly more difficult to interact with and reason about than a system like Erlang/Elixir, and a lot of other languages use the callback model for asynchronous programming.

So, I guess what I'm trying to say is that if you're doing asynchronous programming, Elixir is going to be easier than most (though ES6 has concurrency primitives that are starting to make sense, and Python 3 and Ruby have started getting them, Perl 6 has good options, Perl 5 has somewhat clumsy modules for it, etc.).

All that said, I'm mostly spending my time learning JavaScript/ES6/Node lately; despite its warts, the ecosystem is huge, and there's so many smart people working on the language that by the time of ES7, there will be a very convincing concurrency story. Maybe still not as convincing as Erlang/Elixir and the OTP. But, probably good enough for web apps and services.

I looked into Elixir and Phoenix briefly; watched a few videos, read a few tutorials, never wrote any code. And, came away with a distinct impression of a tiny, tiny, ecosystem. I'm accustomed to going to CPAN or Ruby Gems or PyPI or npm, and finding not just one, but several options for whatever task I want to accomplish, even relatively obscure stuff. It'll be a while before Elixir comes close to even CPAN (which is smaller than all the others these days, though still manages to have modules for nearly every problem I tackle).

Even if you loved Erlang, I'd argue the language is just too esoteric and jarring to most programmers to ever gain serious traction. I remember reading about Erlang's magic back in ~2007 (maybe [1]) and giving it a brief shot but deciding there was no way I wanted to look at that kind of code 8 hours a day. But coming from writing fairly FP-style Ruby/CoffeeScript/ES6-7, Elixir is feels only a step or two more down that path - in many ways actually conceptually simpler - and with enormous benefits.

[1] https://pragprog.com/articles/erlang

I find Elixir uncomfortable because I left behind that syntax and have no desire to return to it.

I also like Elm's syntax, which I use for doing front end work on my Elixir projects. Both make me happy, and that's important when I have to stare at both of them all day, every day. If something else makes you happy, then that's what you should do all day, I suppose.

I use Elixir and I like it, but I wouldn't tell you to use Elixir over Erlang. There's no competition, what's good for one language is good for the other. So use whatever makes more sense to you and hopefully all of us in this Erlang community win.

* Dependency managment

* Rake-like cli tasks (mix)

* Compile-time metaprogramming

* Clean and consistent standard library

* Really good UTF8 support

* Well, syntax in a sense "easier to understand for switchers from ruby/python/etc"

Here is a short article that outlines some advantages. http://theerlangelist.com/article/why_elixir

These are awful techniques IMO but I can't deny that they are life-savers in the Ruby land sometimes.

Some people like one syntax, some the other. Elixir has some constructs like pipe and in some cases macros can be nicer, don't feel like I need them and am quite happy using Erlang. I rather like that syntax is not like Ruby or Python or other language I know, it helps my mind switch contexts. So that is a personal choice. Also Elixir has very welcoming community for beginners. That's big bonus if you are starting out, but Erlang also has more existing literature, books and learning materials.

Take a look at both and see which one appeals more to you. At the end of the day, they both use the excellent BEAM VM and you'd end up learning largely similar concepts anyway.

    defmodule LoopCounter do
      def go, do: go(0)
    
      defp go(n) do
        IO.puts("n is #{n}")
        :timer.sleep(1000)
        go(n + 1)
      end
    end

  tasks = for i <- urls do
    Task.start(fn ->
      :timer.sleep(5000 * the_counter)
      # more stuff
    end)
  end

https://gist.github.com/tomku/21eab22e98950f31a072a2ac63900b...

The key ingredient is Enum.with_index, which pairs your enumerable with the indices that you'd have in an iterative 'for' loop in another language. I've also changed from Task.start to Task.async so that I can collect the tasks and wait for them at the end of the script.

Edit: The recursive approach jdimov10 explained is really useful too, you'll see that pattern of using a recursive function's arguments to hold state all over the functional programming world.

    for {item, counter} <- Enum.with_index([:a, :b, :c]) do
      IO.puts("#{counter} -> #{item}")
    end

    0 -> a
    1 -> b
    2 -> c

   [:a, :b, :c]
   |> Enum.with_index
   |> Enum.each(fn({item, counter}) -> IO.puts("#{counter} -> #{item}") end)

(Yes, not what the parent poster asked but I still found it useful.)

  defmodule Counter do
    def loop(num) do
      Enum.each(0..num, fn (i) -> IO.puts(i) end)
    end
  end

  defmodule Counter do
    def loop(num), do: _loop(0, num)
    defp _loop(idx, num) when idx == num, do: IO.puts idx
    defp _loop(idx, num) do
      IO.puts idx
      _loop(idx + 1, num)
    end
  end

Why don't you guys take the discussion elsewhere so that interested readers can focus on what is new and relevant about this release? The subject of the post is about a new release,not about people showing of their knowledge and opinions about computer programming and languages etc.

It just makes this forums intolerable especially those which are about new releases new products etc.

IMO people discussing here aren't "showing off their knowledge". Posting a version upgrade serves as a visibility reminder and people start inquiring about the features of the language/framework. Eventually a technology gains enough critical mass so that more people start using it.

Absolutely nothing wrong about that.

i learned lisp instead and now i'm learning lfe (lisp flavored erlang)

do i miss something by not learning elixir?

Verses LFE? Not really, at the end of the day they're both ways of making programs for the Erlang VM that aim to improve on Erlang. You can use any of erlang, elixir, and LFE libraries from any of the three[0]. See Jose's comment at https://groups.google.com/d/msg/lisp-flavoured-erlang/ensAkz... .

[0] though beware string types -- LFE string functions generally take charlists, same as Erlang; Elixir ones take utf-8 binaries. So you lose a bit of unicode-just-worksness compared to Elixir, but it isn't really a problem, you just need to be aware of the mismatch and be prepared to handle it