[erlang-questions] The quest for the perfect programming language for massive concurrency.

[David Cartt]

On 30 Jan 2014 17:22, "kraythe ." <> wrote:
> I think one of the issues with Java can be expressed in one little programming puzzle I came across recently:
>
> *In a relevant language, create an array of 1000 numbers. Initialize all of
> the values in the array to zero. Create two threads that run concurrently
> and which increment each element of the array one time.*

This puzzle is a great example of how much Erlang differs from other
languages, and how thinking about a problem in terms of using Erlang
design principles differs from using a traditional approach.  Very
shortly after I started thinking about a solution in Erlang, I
thought: "Wait, now why do you want to do this?".  It just didn't seem
anything like a real problem that Erlang would be used to solve.  The
puzzle could be representing two very different problems.  First, a
low-level, high performance, very constrained application like a
hardware driver or math calculation, for which Erlang is not
applicable.  Or second, a system keeping track of a large number of
independent states along with a number of processes simultaneously
interacting with those states.  That's something Erlang excels at and
is trivial to solve with no concurrency issues.  Just for fun, lets
make it a bit more challenging and say the system is tracking X number
of states, with Y number of processes interacting with those states,
spread across Z number of networked machines.  Load balance X states
and Y processes across Z machines, and all X, Y, and Z are dynamically
changing.  That's a puzzle that's pretty easy to do in Erlang but
would be a huge project in other languages.

> *Erlang:*
> *Cons:*
>    1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
>    back to coding with VIM and makefiles is primitive. Rebar is crytptic and
>    just the pet project of a guy on GIT. Compared to Gradle, Maven and even
>    (though I don't care for it much) SBT, rebar is ... lacking. I want to
>    spend time working on my business logic, not fighting tools. There are
>    plugins for eclipse and intellij but they have minimal functionality and i
>    keep reverting back to vim.
Those powerful build tools are great, after taking the time to learn
them, until the time they stop working and you're left wondering what
went wrong.  I really like Erlide but a couple of times something in
that massive pile of code that is Eclipse plus Erlide has stopped
working and taken a huge amount of time figuring out what.  VIM,
makefiles, and bash are primitive, and that's their strength.  They're
all simple and comprehendable.

>    2. Much harder to staff than Scala because it is not Java based.
This could actually be an Erlang advantage because Erlang self-selects
better programmers.  It's radically different (what interested me in
the first place), takes a lot of work to get what it's about (all of
it loads of fun to learn for that very reason!), and isn't trendy (who
cares - I want something that solves large scale, fault tolerant,
business critical, distributed, concurrent, real world problems).
Learning Erlang takes a lot of effort - misery for someone who doesn't
love programming but fun and rewarding for someone who does.

>    3. Fewer general purpose libraries and no major central repositories.
>    I don't want to write code to create JSON, that isnt part of my business
>    scope. I will pick that one of the shelf If i can.
There are lots of libraries, certainly many for dealing with JSON.  No
need for a central repository - just do a web search.

>    4. Records as the only structured data type is ... annoying.
That's probably for the best because most likely if you're coding in
Erlang using a shared structure across multiple source files then
there are better ways of doing it, and good reasons for doing so.  If
you really need to, use property lists, which have no shared structure
to keep synchronized across multiple
files/processes/machines/versions.  The obvious struct/class OOP
design of traditional languages is transformed in Erlang/OTP in to
something much more powerful, maintainable, and far better at dealing
with complexity.

-David Cartt