Is Erlang too esoteric?
Is Erlang too esoteric?
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.
* 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.
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.
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.
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? :(
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) :).
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)Elixir:
def loop_through([h|t]) do
IO.inspect h
loop_through t
enddef loop_through([]) do
:ok
endErlang'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.
And honestly I really enjoy the syntax...
Also, all the different import-related keywords are pretty confusing. Maybe that's improved though
I don't find either syntax to be off-putting but that's just me.
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.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.