I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant.
Having spent quite a bit of time searching for Erlang packages on Github recently, I've found quite a few Erlang packages haven't had commits since around 2013. I believe there was a spike in adoption around 2012-2013 which resulted in a bunch of activity on Github. Which seemed to have tapered off recently. But you still find many core packages that are active - things like JSON parsers, templating libraries, and web frameworks are all lively. And OTP and Erlang itself are always being improved.
Plus there is an up-to-date package manager/global repo (https://hex.pm/) which is used by both Erlang and Elixir. Plus Rebar3, the primary build tool for Erlang projects, is actively developed.
But Elixir packages are very active in general since it's relatively new and these packages can be used within Erlang apps relatively easily as well. Plus the Erlang packages from 2013 that I've used have all been pretty stable. The quality of libraries available on Github have all been very high from my experience. I believe Erlang attracts experienced developers, which is reflected in the typical code quality and documentation.
My only wish is for the Erlang website (http://www.erlang.org/) to get a redesign. It gives the language an esoteric apperance to newbies. Which is a shame because I absolutely love the language and think it's far superior for many of the types of projects for which people have been using Node.
I am excited for a continued improvement and enhancement to the language.
Erlang 18 brought maps, people complained about that for years. Erlang 18 also brought (via a feature flag) dirty schedulers so can have long running C function embedded in without messing up process scheduling also an often requested features. Probably the best thought-out handling of time in any language I've seen so far ( synchronization, warping, moving backwards: http://erlang.org/doc/apps/erts/time_correction.html )
Erlang 19 is exciting as well -- 10x faster tracing, dirty schedulers turned on by default, a new state machine OTP module, an external plugin (with LevelDB as one example) for Mnesia storage also something people complained, 2x-3x faster spawning external processes + many others.
The impressive part is that these changes are done to a 30 year old language.
mnesia_leveldb is scheduled for OTP 19? That's great news!
I can't tell you how many times I've cursed at the overfilled-hours-ago-but-mnesia-didnt-care DETS table shard. Getting a on-disk backend that can store more than 2GB at a time will be great!
It'll be even better if the writer code actually notices failures to write to the backing store and aborts transactions when they happen! [0] :)
[0] Seriously, who thought it was a good idea to ignore the return value from dets:insert/2? :(
Man, whoever redesigns erlang.org needs to think really hard about how they're going to re-work the documentation section. It's really good as is:
* Color scheme and fonts are easy to read.
* One can switch between API reference for the current module and Users Guide for its containing application with one click.
* On the left-hand-side one has a scrollable tree of modules in the current application, each of which is expandable to reveal the API calls within any given module.
* Sensible URL scheme: doc/man/$MODULE.html for a module's API docs and doc/apps/$APP/users_guide.html for an application's Users Guide.
It doesn't need much, just very slight tweaks to the typography so it's a bit cleaner + a bit more visual separation between function descriptions + slightly better handling of the navigation. It's just all a little bit jammed together atm, IMO. As I say, wouldn't take much.
One thing I've found I love are the PDF documentation downloads; I wasn't expecting much, but (for example, the xmerl one) they're great, step by step useful examples that I can shove on an ereader to go through. Really solid.
Do you hire people who know how to code in language X and are really good at coding in language X but nothing else?
Or, do you hire people who are go-getters, want to use the best tool for the job, and want to learn?
Because if the latter, Erlang/Elixir might be esoteric, but Elixir specifically is a simpler language than currently more popular languages like Python or Ruby. It's also more elegant. I like to think of it as Scheme + Ruby syntax + pattern matching + concurrency. If that excites you, carry on. If that scares you, go for something more traditional (and no hard feelings) :).
Seems like a strange view to have. The best paying work is generally in boring, enterprise approved languages. It's probably a competitive advantage for a small company to pick a niche language - I wager they would hire better quality engineers for less money.
Sometime I wonder why Elixir tries too hard to have Ruby syntax.
Erlang:
loop_through([H|T]) ->
io:format('~p~n', [H]),
loop_through(T);
loop_through([]) ->
ok.
It seems convenient to use ';' to separate multiple definitions of a function compared to using 'end' in Elixir(function definition continues in the next block)
I believe, like Steve Yegge has said elsewhere, that programmers are lame, (and now paraphrasing) because they refuse to touch things that look odd.
Erlang's syntax may be more efficient, but a lot of people won't touch it becuase the syntax is unfamiliar. Elixir has a huge advantage in this. It might not matter to you specifically, but in the realm of adoption that is huge.
I mostly enjoy the syntax. Kind of hate that they made parentheses for function calls optional, especially since no-parentheses has ambiguous cases that behave weirdly (like with chaining syntax). Should be enforced.
Also, all the different import-related keywords are pretty confusing. Maybe that's improved though
True. I personally like Erlang's syntax more. I like single assignment variables, I like the structure and feel of it and so on. But Elixir is great too. I am glad it is there and is taking advantage of the BEAM VM. It definetily appeals to many Ruby-ist or those who used Python and are otherwise scared by a different syntax.
Still pretty new to Elixir, so I welcome any suggestions, but from my understanding (and based on Elixir's guides [1]), I think that the more idiomatic way to approach this is to avoid writing such a loop_through/1 function and instead just use:
Enum.each(<the list>, &IO.inspect(&1))
or likely
<series of data transformations resulting in list> |> Enum.each(&IO.inspect(&1))
Both return the :ok at the end of the loop, so Enum.each/2 looks to be functionally equivalent.
Embedded systems programmer here. I'm learning Elixir and am very excited about the nerves project:
http://nerves-project.org/https://www.youtube.com/watch?v=kpzQrFC55q4
Edit: There also seems to be a good Elixir/Erlang community here in Berlin Germany where I live at the moment.
Do you have some link or contacts in/to this community? I am in process to develop a quite interesting application on Erlang and I am struggling to find a community (in Germany) where I can either ask questions or have a pool of possible people to hire.
We've pushed a couple of Elixir apps in the past six months. There was definitely a bit of worry that no one would be able to maintain it, but I have to say that the code is very readable. So many languages integrate some functional aspects that the code doesn't look foreign in most cases.
Also, the Phoenix Framework (if you're building a web app) is really, really nice.
Here in New York, it's not too hard to find Erlang enthusiasts, particularly ones that work on Wall Street.
That said, no one seemed to have even heard of the language in Dallas when I lived there.
So the long-story-short of this is that if you don't mind doing some remote-hiring, it's not too hard to find workers, and things like Ejabberd have a ton of tutorials on writing modules.
Is Erlang too esoteric?