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

[Loïc Hoguin]

CCing back the mailing list as I would like my response to be archived 
for future users.

On 01/30/2014 07:22 PM, kraythe . wrote:
>              /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./
>
>
>     That's not the kind of problem Erlang solves. That specific problem
>     requires a parallel solution, not a concurrent one. Plus Erlang
>     processes are isolated so they don't have access to the same data
>     without a third party (another process, an ets table, ..). Really
>     for that kind of problem I would instead suggest something like
>     Haskell or OpenCL.
>
>
> I put that in only as an example of why NOT java. But I would be
> interested in your take on how to solve it in erlang. Theoretically
> parallel = concurrent. The only question is how to break up the task to
> federate it. Shared memory is one way, but not the only way. Introducing
> more than one language to this mix is something I would like to avoid.

Well I would simply not use Erlang for it. Erlang is good at pretty much 
anything except CPU-bound problems. Thankfully these are very specific 
to certain fields and types of applications so Erlang does the job just 
fine most of the time.

If I had that kind of problem to solve inside my application I would use 
Erlang to manage OpenCL or similar. Erlang is very good at running in a 
mixed environment, including C libraries, external programs, and can 
easily speak to any other language thanks to C/Java nodes. So there's 
really no need to bother trying to solve that problem efficiently in 
Erlang. Just use something more appropriate and make Erlang speak to it.

> Naturally its my opinion. :) One subject to change I might add. Either
> the tools are not there or not readily findable. A critique of Erlang is
> that if you don't make the ecosystem accessible, you inhibit adoption.
> IMHO there should be a "getting started in erlang" tutorial that takes
> you from nothing installed to setting up tool set to your first app
> running and then modified. I googled until my fingers bled and found
> nothing like that, only other smaller tutorials and entirely language
> and shell tutorials (which were great btw). That "new to erlang? Start
> here," tutorial should be prominent on the first page of erlang.org
> <http://erlang.org>.

You come from a very different world, most languages don't have their 
specific IDE and graphical tools to do things. Erlang does come with an 
Emacs mode 
(http://www.erlang.org/doc/apps/tools/erlang_mode_chapter.html) but 
that's only good for Emacs people.

The shell tutorials are the best getting started you'll get. Erlang is 
unique, there's absolutely nothing that comes close to it, you have to 
learn how it works before you can get started. And the shell can be used 
to learn a lot of it. One time I spent the first day of teaching a 3 
days training using nothing but the shell.

If you want a getting started to OTP applications and releases, you can 
take a look at this: 
http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ - That's 
pretty much what a "getting started with writing Erlang applications" 
would look like, and as you can see it doesn't cover much of what is 
covered when learning Erlang.

>           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.
>
>
>     Well good for you then because there's about a dozen JSON libraries.
>
>
> Oh good. I googled for a vector math library. In java I can go to a
> maven Repo and get an index of thousands of libs. Where is the erlang
> equivalent ? And do I have to compile them? Can I just use the binary
> beam files?

Like I said earlier, CPU-bound operations, write a binding to a C vector 
math library and call it from Erlang.

Erlang code is almost exclusively obtained from source. There are no 
central repository, despite many attempts, for two main reasons:

  *  It is very common to run your own fork of a project with a specific 
set of additions, fixes or performance improvements you can't live without.

  *  What you push to production is called a release, and is a self 
contained package containing everything your node needs to run. You can 
just push it to a new system without anything Erlang installed, start 
the release and it just works (you might still need openssl on some OS).

What follows from that is that you won't install much Erlang libraries, 
you just mark them as dependencies to your release and the build tool 
fetches everything as needed.

To illustrate, I do have a package index file in my erlang.mk build 
tool, but no open source author sent a PR to put their project there. 
(Of course this index file has other uses so it's not a wasted feature.)

The package manager question comes back regularly, and there's a new one 
from time to time, but what these projects try to solve is generally 
what they think is a technical issue of previous package managers that 
failed to get traction, while the actual issue is entirely cultural.

> Maps would be good and solve much of my record tuple annoyance. +1 for
> that. What I would really want, though, is a constrained map. A map
> where I can bind the keys to only a certain set of atoms. Records aren't
> too horrible except their syntax is ... weird.

You can create a map with a default for all the keys you accept and then 
update using only := which requires the key to already exist in the map.

-- 
Loïc Hoguin
http://ninenines.eu