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

[Loïc Hoguin]

Some replies inline.

On 01/30/2014 05:19 PM, kraythe . wrote:
> Ok right up front, I'm a Java Guru, not a Scala or Erlang one. What that
> means is that I know more than most debs about the core java language,
> but enough to know where the problems are. And certainly java has many
> issues but it also has massive momentum. 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./

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.

> The goal being to select a language for
> the development of a concurrent TCP/IP based application with thousands
> of users interacting in a small space.

Well that's completely different from your problem. And that's actually 
something you get pretty much for free with Erlang. I had no problem 
getting 10K connections with absolutely no load on the server in a 
production application. And since there was two of them, that means 20K 
connections, no load and about no distributed programming required.

>  2. Built from the ground up with immutability in mind. Immutability is
>     a language feature, not compromisable. Its not JVM based and so is
>     not under the same issues as Java is.

Immutability is a language and VM feature. You can have a mutable 
language on top of the BEAM VM, Elixir is an example of that.

>  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.

Well that's very much your opinion. Many would say Eclipse and the Java 
ecosystem is garbage. I use Makefiles, and when I pull my project from 
github the only thing I need to do is type 'make' and wait for it to 
fetch dependencies, compile everything and generate the release which I 
can then send to any server and it will just work with no extra 
configuration or package needed (not even Erlang!). All this in just 
under a minute. I would definitely not call that primitive.

>  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.

>  4. Records as the only structured data type is ... annoying.

Maps are coming. They're even in master now.

Besides them you also have proplists, dicts, sets, etc. etc. Erlang 
comes with tons of structured data types, they just don't have a special 
syntax. Maps have their own syntax, though.

> The problem I have is I can't find the perfect solution. Erlang is
> compelling but also is Scala.
>
> Opinions?

If you like Java so much, use it, but do note that because of the global 
GC your application will have to stop for a few seconds from time to 
time, which is problematic when you have 100k users doing stuff (and the 
more users you have, the bigger the problem). Erlang has per-process GC 
so this particular issue doesn't happen. Personally that's a deal breaker.

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