http://elixir-lang.org/blog/2016/06/21/elixir-v1-3-0-released/
is this syntax actually worth learning? ive barely heard of it before, whats the uses?
>>55194628
Elixir is Erlang with nicer syntax. It's based on Erlang and compiles to the same bytecode. Since it basically is Erlang, it's good at handling a shitload of concurrent connections passing information, fault tolerance, and scales well up to large distributed applications. Erl
I hope that Elixir doesn't end up like Erlang. Really powerful, really good at its job, but obscure enough that businesses won't use it because they can't find developers. It might be too weird for people to migrate to.
People don't seem to be making very much buzz about this release.
ded thred ded language rib
>>55194980
see python:
stupid slow, stupidly buggy, but super easy syntax.
The most meme'd language in Silicon Valley
>>55197185
Elixir is a pretty cool bro.
He's my go-to these days for APIs and/or services.
>>55194980
It's just the next hyped up dynamically typed disaster. It will be irrelevant next year when all the retarded Ruby hipsters that jumped to Elixir jump to something else.
You'd honestly have to be retarded to think dynamic typing is still a good idea in 2016 and dialyzer doesn't come even remotely close to cutting it. Also Ericsson barely even uses Erlang anymore and BEAM has been on life support for ages.
>>55199064
>Ericsson barely even uses Erlang anymore
Who the fuck cares? They first stopped using Erlang in 1998. They aren't relevant to the discussion anymore.
>>55199111
Other than whatsapp almost no one is using BEAM for real workloads. It's performance is absolutely horrendous on anything that isn't bottle necked by IO and integrating C and C++ code correctly is very difficult and error prone because of the scheduler.
Erlang and Elixir are tied to BEAM and BEAM is basically dead.
>>55199194
Erlang on Xen would like to have a word with you.
It's fast. Stupid fast. So long as you aren't lazy and actually use efficient data structures and algorithms as opposed to declaring a bunch of stupid variables for buffers and fetching thousands of stuff at runtime you are fine.
Problem with Erlang/Elixir is hipsters that have now become the majority of software development workforces are lazy and don't like to put in work outside of making pretty apps
Erlangs main problem is that it wasn't pretty, that's it. None of this I/O bullshit you are pretending to know about.
>>55200035
>It's fast. Stupid fast
No, it's not. It's reasonably fast at IO bound problems and horrendously slow and inefficient for any problem that is CPU bound. This is common knowledge in the Erlang community and nobody worth shit would even pretend that it's fast for CPU bound workloads.
I'm curious to see which of this crop of "new" web languages ends up coming out on top... Go, Rust, Swift, Elixir, and Crystal all have their interesting aspects.
Go is already doing pretty well but isn't a good fit for every type of project. I'd put my money on Rust or Swift personally.
>>55200167
Go and Swift will be reasonably popular. Rust will probably remain niche. Elixir and Crystal will remain irrelevant.
Swift is the only one that has a real chance at becoming as popular as something like C# or Java and that entirely depends on how good the ports to Linux and eventually Windows are and if those communities start to adopt it. I think it will be largely ignored by Linux and Windows users so it will remain as nothing more than a language to program iOS and MacOS apps.
>>55200250
>I think it will be largely ignored by Linux and Windows users so it will remain as nothing more than a language to program iOS and MacOS apps.
Doubtful. Remember that a good number of the guys working on iOS apps would like to be able to work on the back end without tearing their hair out trying to deal with the undisciplined looseness that's popular there (especially in silicon valley). A backend written in Swift also allows sharing of model code between server and client which is always awesome.
elixir is pretty cool. we use it at work for our soft-realtime system.
beam/erlang is definitely first class for that.
all the people saying "go and swift" are the future are idiots.
>>55200093
wew lad, you sure spewing a lot of stupidity there. Did you just read up on why Erlang failed in the late 90s and figured you'd use that as an excuse not to adapt?
What you said is true, but it's 2016 and multi core CPUs are a thing, shit son, there's an 18 core CPU coming up, and Erland/Elixir thread better than anything else out there.
Cloud computing also allows for numerous asynchronous processes at scale.
Get your shit together senpai
>>55200341
>Erlang/Elixir thread better than anything else out there
99.9% of serious multithreaded applications are written in C, C++, C# and Java and they all have far better performance and far better libraries. There's literally nothing written in Erlang that isn't trivial.
Implementing a dynamically typed actor model isn't terribly difficult nor is it interesting. Akka alone is already far better than OTP.
>>55200407
>C# and Java threads
wew lad
>>55200467
Yes, using native threads with a thread pool isn't terribly difficult and there's Quasar if you want lightweight threads. If that's too low level you can use one of the abstractions on top of those like Akka.
All far better than the bullshit coming out of these shitty dynamically typed fad languages.
>>55200407
>99.9% of serious multithreaded applications are written in C, C++, C# and Java
I can't say for sure that you're wrong, but I really doubt you mean the same sort of scale. Two or three concurrent threads are a very different beast from two million. I would be interested to know what languages are popular for massively parallel computations, though. As far as I know, raw computation is not erlang's strong suit.
