[erlang-questions] The quest for the perfect programming language for massive concurrency.
Thu Jan 30 20:49:05 CET 2014
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.
> 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
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
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
> 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.
More information about the erlang-questions