
What can I only do in Erlang? - davidw
http://erlang.org/pipermail/erlang-questions/2014-November/081570.html#
======
rvirding
Some people have already been mentioning this but I wish to clarify some
things.

When Erlang was designed/invented the goal was never to make a new language,
the goal was to design a way of building _systems_ with a set of specific
characteristics, massive concurrency, fault tolerance, scalability, etc. One
part of this was the language, Erlang. But at the same time we were developing
the language we were also looking at how you would use the language and its
features to build such systems. The language and the system architecture went
hand-in-hand with support in erlang for the type of patterns you would need in
the system architecture.

These ideas and patterns existed before OTP. So there were Ericsson products
built on top of Erlang which used these ideas and patterns before OTP. OTP
"just" took these ideas and design patterns and formalised them in a generic,
cohesive way. Plus of course a lot of useful libraries.

So we were never really out to design a functional language based on the actor
model, we were trying to solve the problem.

(We had actually never heard of the actor model but were told later that
Erlang implements it)

~~~
barbudorojo
I wonder how is going the Lisp Favored Erlang project,
[http://lfe.io](http://lfe.io). As someone that enjoys lisp and prolog I find
erlang a very nice language. Two feature I find handy: One is the ability to
modify code while running, the other is OTP. Joe's thesis, available online,
was for me an excellent resource to learn Erlang. I think that a good use case
for Erlang is when a lot of actors are needed each one doing a little work
with little resources (no big library, regular expression, atlas, or the like
used).

Funny, I recall some surprise in the community because Joe was asking some
easy question about C for some glue code. It's been 5 years since I touched
Erlang, only for learning, but is message passing style and the way you create
functions like in prolog (or in Shen or picolisp) is unique and a great
virtue. I know that tcl has secure interpreters, I wonder if there is such a
think in erlang.

~~~
rvirding
That about Joe is not strange actually as he has never been a C-programmer.
Before coming to the lab he was a fortran programmer.

~~~
nevergetenglish
People in racket are using typep racket, clojure has annotation, in lisp you
can declare types and sbcl infers them. Haskell also is fond of types. Perhaps
in erlang types are not so important because you try to decompose the problem
in small parts and hence is not so important to declare types?

~~~
mononcqc
Erlang has Dialyzer, which is an optional type checker and discrepancy
analyzer.

------
radmuzom
In 2005, I worked in software development for 6 months before abandoning it
for another field.

In my new job, I was given the task of writing a server for a messaging
application - which would allow users to send a "hand-drawn" message from our
own proprietary handheld device to Windows phones. I was told to learn Erlang
and get it done - the company was barely 30 people and had no formal training
programs. While I have a degree in theoretical computer science, I didn't do
much functional programming before - learnt some Haskell in 2001 in college
(just the basics, equivalent of first 6 chapters of LYAH, no monads). I
remember learning Erlang over the weekend and delivering it in the first week
of my job. Obviously, the code was neither great nor scalable - but I write
this not to boast but to tell people that Erlang was so beautiful and easy
that even an average intelligence person like me could use to produce
functional software in a week. Today, my only regret is that I am not a
programmer.

~~~
zerr
Agree, and to look at it from a different angle - to me writing Erlang felt
like I was writing config txt files to some underlying system. The system
performs good following your "config" but all the hardcore feel is lost for
you.

~~~
Ixiaus
Huh?

"Hardcore feel" is definitely there and the language is anything but "writing
config txt files to some underlying system".

I've built applications in the > 10k SLOC range that use a consensus algorithm
for distributed computing and it was _hard_ but made _tremendously easier_
because of Erlang's built in primitives.

No hardcore feel was lost at all and neither was it writing a config txt
file...

[EDIT] I would love to know why the downvoter disagrees with me, unless you're
being a downvote kiddie.

~~~
baldfat
Down vote = I don't agree with your statement normally here. Not that it might
be a starting point on a conversation?

~~~
Ixiaus
Down voting is not for disagreeing, read the guidelines for HN. If you
disagree, provide a comment as to why.

Down voting is for completely irrelevant comments, inappropriate comments,
etc...

[EDIT] To be clear, I did not downvote you and I disagree with the down votes
on your comment here, even though it's off-topic it's important to acculturate
people that are accustomed to "downvoting for disagreeing". Which is why I'm
commenting.

~~~
Fuzzwah
Downvoting is for however the user wants to use it.

[https://news.ycombinator.com/item?id=117171](https://news.ycombinator.com/item?id=117171)

> pg 2455 days ago | link | parent | flag > I think it's ok to use the up and
> down arrows to express agreement. Obviously the uparrows aren't only for
> applauding politeness, so it seems reasonable that the downarrows aren't
> only for booing rudeness.

> It only becomes abuse when people resort to karma bombing: downvoting a lot
> of comments by one user without reading them in order to subtract maximum
> karma. Fortunately we now have several levels of software to protect against
> that.

~~~
saganus
What I have never understood about HN's use of the down vote as "I don't agree
with you" is that it also changes the color of the post to one designed to be
hard to read, so it's like imposing a kind of progressive silence.

Why not just a change in color to something different, not harder to read? If
down vote is to be used however the down voter wants then why attach the
"punishing" color to it?

It's an interesting system in that I have not seen it anywhere else and indeed
does seem to work. But still I can't understand it.

------
davidw
This is a pretty good summary of what makes Erlang unique. There's definitely
a learning curve, as he says, but once you start to 'get it', you can make
some really solid stuff with it.

I've been having a lot of success with remotely debugging things with observer
(
[http://www.erlang.org/doc/apps/observer/observer_ug.html](http://www.erlang.org/doc/apps/observer/observer_ug.html)
) and Recon ( [http://ferd.github.io/recon/](http://ferd.github.io/recon/) ).
I've been using the latter to compile code locally and quickly deploy it to a
remote machine (while it's running, of course) to debug problems without going
through a whole commit/pull/build cycle.

Some of the other responses in the thread are pretty good too:

[http://erlang.org/pipermail/erlang-
questions/2014-November/t...](http://erlang.org/pipermail/erlang-
questions/2014-November/thread.html#81564)

------
bosky101
here is a daemon that runs forever

    
    
        foo()-> 
           foo().
    

1\. processes as tail-recursive functions

it's callstack will never grow. you can have multiple of these running and the
scheduler will still split work between them. a process is a tail-recursive
function where the argument becomes its state. a process ceases to exist when
it stops being tail-recursive. erlang's distributed computing strengths can in
ways be attributed to tail-recursive approach to network programming &
beginning with concurrency in mind. everything else came as a side-effect.

for anyone interested for more examples of expressiveness/composition, this is
from my talk at functionalconf [http://www.slideshare.net/bosky101/recursion-
and-erlang/43](http://www.slideshare.net/bosky101/recursion-and-erlang/43)

2\. Node's or machine's are first-class citizens.

you can decide to replicate data over to them, make the data on one node
location-transparent, or decide to just abstract it all in a distributed
system.

3\. binary patten matching

you can pattern match not just [A,B] = [1,2] but also contents of A,B. or do
gaurds against contents . eg if the contents of this binary variable begin
with "foo".

4\. you never have to import any header or module. the vm uses all modules
available in its (ebin) path. big cyclic dependency headaches good bye.

5\. as many schedulers as there are cores in your machine. (configurable)

6\. hot code swapping.

albeit little contrived for the beginner on production systems.

7\. otp

comes bundled with the fsm,client-server,etc skeletons called "otp", the same
that runs 40% of the worlds telecom traffic.

~B

PS: the root link describes more such features you may find useful

------
willvarfar
Curious how much people think Go will eat into Erlang? Many of the points made
were about Erlang as CSP and that's Go-territory.

Loïc Hogun (author of Cowboy, other projects) said:

    
    
      For me Erlang is first fault tolerant, then concurrent,
      then functional
    

As Go gains libraries like groupcache will it become more and more go-to for
networked and shared systems?

Is Go moving up from concurrent to fault-tolerant in a real way?

~~~
davidw
If you dig around in HN's search there are a lot of good comments from people
like jerf on the differences:

[https://news.ycombinator.com/item?id=5451916](https://news.ycombinator.com/item?id=5451916)

[https://news.ycombinator.com/item?id=7943248](https://news.ycombinator.com/item?id=7943248)

But there are more here and there if you hunt for them.

I think for things where they are sort of similar, Go will definitely be the
more successful language because it looks so much more familiar and because
it's moving faster with more momentum, at this point.

I'm using Erlang for a semi-embedded thing at the moment, though, where
stability is more important.

~~~
polskibus
Whenever I think about Erlang's stability I recall the problems mentioned by
CouchDB authors and RabbitMQ users. Apparently CouchDB hit some problems with
low level disk access that they couldn't trace and that pushed them to migrate
away from Erlang. RabbitMQ is allegedly dropping lots of messages for unknown
reasons under heavy use. I do not have the links at hand for reference but
such stories make me wonder how battle-tested Erlang really is when you need
to persist your data (and not just transmit it over the network).

~~~
Ixiaus
The Riak guys have better experience here and I would argue that it's pretty
well battle-tested when Apple is deploying hundred node Riak clusters for
production :) (Riak is built on-top of Erlang)

------
amelius
Erlang looks interesting. However, the only problem I have with starting in
Erlang is that on the great computer language shootout, it shows that Erlang
is about 10x slower than C++ on most examples. And about 3x slower than Go [1]
I know that the problems on this website are not specifically "concurrent"
problems, but still, even a distributed web-server must do some non-concurrent
stuff at times :) Are my concerns correct/justified?

[1]
[http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=hipe&lang2=gpp&data=u32q)

Edit: even Haskell seems to be about 7x faster than Erlang (according to [1]).
Suddenly, Haskell looks like a good candidate for writing a distributed server
:) Can somebody comment on this?

~~~
tegeek
When you say Erlang is slower than C++, You are right. It is also slower than
Go.

Ruby is also slower than C++ & Go, But Ruby on Rails is not only popular but a
very productive web framework which can help you build your app with a
productivity that C++ or Go can't match.

When you write a high quality, fault tolerate system, the raw speed comes at
the end. Erlang shines when you write a concurrent system plus its design is
very unique. Erlang I would say isn't only a language but a whole philosophy
of Software development. Once learned you can apply to many other platforms.

All in its a joy to work with functional languages and Erlang is perhaps the
most commercially successful functional language.

~~~
louthy
> and Erlang is perhaps the most commercially successful functional language.

Out of interest, what makes you say that?

Looking at the TIOBE rankings (not that this is definitive), Erlang doesn't
even make the top 20 languages, when F# and R do:

[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

Is there a reason you think it's more successful in the commercial world?

(btw, I'm a fan of Erlang - unfortunately I don't get to use it on a regular
basis; other than products built on it: RabbitMQ mainly)

~~~
rdtsc
Erlang is used in infrastructure projects. A few I know of:

Rabbitmq -- probably the most popular messaging system

Riak -- distributed, fault tolerant database

WhatsApp -- managed to route billions of messages a day with only a handful of
engineers and servers.

Ericsson -- pretty much got the market for cell base nodes cornered. Chances
are about 50% if you use internet on your smartphone, that Erlang will be
involved.

Some firms on Wall Street use Erlang -- remember Serge Aleynikov case, he is
an Erlang programmer.

Ejabberd -- a very popular XMPP server

CouchDB/Cloudant(IBM) -- another database and database-as-a-service company
use Erlang.

So I would still say the original statement holds. By success might mean the
amount of work being done not amount of people writing code. Think about
WhatsApp. It was only 10-20 engineers that worked on the back-end yet think
about the massive amounts of data they were able to handle.

~~~
davidw
> Some firms on Wall Street use Erlang -- remember Serge Aleynikov case, he is
> an Erlang programmer.

His erlexec thing is quite useful:
[https://github.com/saleyn/erlexec](https://github.com/saleyn/erlexec) \- I
started contributing to it myself before I realized who he was.

------
john2x
I love Erlang (and it's younger sibling Elixir). I love reading about it. I
enjoy following tutorials about it. I love its simplicity.

But when I try to come up with scenarios/ideas where Erlang might be a good
fit, I realize I'm not smart/motivated enough (yet?) to tackle such problems.

Erlang isn't difficult. It's the problems it was designed to solve that are
difficult.

~~~
lostcolony
You're probably thinking about it the wrong way then. It turns out that even
in cases where you don't have some massively distributed, scalable needs,
there are a lot of cases to use Erlang. While it makes insanely difficult
problems tractable, it can also make moderately challenging problems simple
(and it sometimes can make simple tasks irritating; see usual list of Erlang
complaints).

Just about any sort of web backend (that isn't having to do a whole lot of
number crunching), any sort of interaction with hardware, handling/transport
of binary data (as mentioned above), and of course any time you need
reliability, it's worth considering.

But even in areas where there's not an obvious win, a lot of problems that are
traditionally done in a single threaded manner can be made simpler in a
concurrent language like Erlang.

An example I like to give is time based task scheduling. In a traditional
language, you'd implement something like that with a priority queue. Which is
fine, but you have a lot of work. First, what happens if timings change? You
have to rejigger -everything-. What happens if you have multiple tasks at the
same time? You need a threadpool or similar to dispatch these things onto.
What happens if one task itself creates a new task for a later time? You'll
have multiple people adding things onto the priority queue, so now you need to
start locking. And of course, since you've got your dispatching process
sleeping until the next task is to start, you have to make sure any time you
modify the queue, you remember to notify that sleeping task, so it can update
as necessary. There is a lot to get wrong.

In Erlang? You spin up a separate process for each task, with a timer. Done
(with caveats; you likely will need to persist the task information and load
it periodically into a task+timer process, but that's pretty trivial).

A similar case can be made for functional compared to a more procedural
approach. That's a little too long winded for here, but even examples that
seem -ideal- for OO, can oftentimes be described more simply in a functional,
data-centric manner, and future refactorings are made simpler as well in doing
so.

~~~
macintux
You're both right.

Absolutely, Erlang can serve well as a general-purpose language.

But there's no denying that it was designed to solve very costly, very
difficult problems, and that remains its strength.

------
dpeck
I'm just starting to do some work on a system that is going to be very
distributed with many endpoints, often on unreliable networks connecting back
to a server.

Erlang (elixir, really) looked promising for this so I've been investigating
off and on while we do some prototyping and flesh out some of the details. So
far it seems to be that you get nearly all the advantages of Erlang with
running something like RabbitMQ and then being able to write message consumers
in whatever language you desire.

Everywhere I think Erlang would be a good fit, seems that relying on RabbitMQ
instead and having less code to maintain in-house makes more sense. I'm still
very early in my Erlang journey but so far haven't been able to convince
myself to use it directly. I must be missing something.

~~~
lobster_johnson
RabbitMQ is a good piece of software, but it has issues. You mention
unreliable connections; RMQ does _not_ handle that well.

Even just a few seconds of network hiccup will throw it into a partitioned
state, out of which you cannot reliably escape without manual intervention.
There are also quite a few bugs that you tend to hit only when RMQ is exposed
to network issues.

To use RMQ with bad networks, you need to use either the Shovel plugin or the
Federation plugin. Both are somewhat awkward to use, and require manually
setting up the different routes that copy messages across.

My advice is, if you like Erlang's architecture and need failure-tolerant IPC,
just use Erlang directly. Don't use RabbitMQ for IPC if you need reliability.

I wish I could say better things about RabbitMQ, but it is easily the flakiest
component of our stack. When you're used to rock solid server software like
Postgres, HAProxy and Nginx, RabbitMQ is a big disappointment.

~~~
dpeck
Man, I hated to read that. Thankfully I haven't done anything more than just
an hour or so of playing with it, but nothing I've read indicated there were
issues with connectivity :(

Could you point me to or elaborate on some specifics on the partitioned states
and manual interventions required? I'm only really calling the shots on the
server side and endpoints will be written in various languages, part of my
reason for looking at RabbitMQ since it has so many libs.

~~~
lobster_johnson
You may want to read Aphyr's analysis [1], which is rigorous and well written.

If you read the RabbitMQ documentation, they readily admit to the fact that
the clustering support is not designed for unreliable network connections.
It's mentioned only once, and it's easy to overlook.

Here's a very quick, rough overview (it's complicated):

RabbitMQ works by assigning queues to specific nodes. A queue is a physical
thing belonging to only one node at a time; consumers, publishers and so on
are distributed, but queues aren't. If you lose that node, you lose the queue.
If you get a network partition, the nodes in the other partition(s) will not
see the queue anymore. Connected publishers and consumers will start barfing
when their bindings no longer seem to exist.

RabbitMQ can mitigate these loss scenarios by mirroring queues. They call this
"high availability", or HA [2]. Each queue will have a master node and a
number of slave nodes that maintain replicas. In the event of a cluster issue,
a slave will be elected master.

Ironically, HA, despite its name and apparent purpose, still requires a stable
network. It does not deal well with network partitions. It's not really high
availability. It is, I suspect, designed for situations when you wanted to
take down a node manually, in a controlled manned, without disturbing a live
cluster.

The reason, and this is the important part, is that when a network issue is
resolved and the partitions can talk to each other again, RabbitMQ has no way
of reconciling queues. If the partition divided nodes into sets A and B, then
A will likely have promoted a mirror slave to a master, while B will have kept
its master, or vice versa. When the partition is resolved, you now have two
masters, whose queues have very likely gotten out of sync in the mean time.

When this happens, RabbitMQ normally needs to be manually restored; it will
simply cease to work properly. Note that I'm talking about the case when the
network issue _has been resolved_. The network is back, RabbitMQ isn't. You
need to decide which nodes should survive and which should be wiped, and this
recovery process is manual. Of course, if this happens in the middle of the
night, you have a potentional emergency.

Fortunately, RabbitMQ has a band aid on top of HA called "automatic partition
handling" [3]. It offers three different modes of behaviour, of which autoheal
is probably the most important one. In autoheal mode, RabbitMQ will
automatically pick a winner to solve conflicts, and promote it to a master.
This will result in data loss; the losing nodes will be wiped. Autoheal is
actually pretty crazy, because it is lossy by design; the only way to find out
if you lost any data today is by grepping the logs for autoheal messages.

Worse, due to the "poor man's database" nature of RabbitMQ, doing any kind of
manual recovery -- like dumping the conflicts, reconciling them, and dumping
them back in -- is probably not realistic when it happens.

Note that even on a flawless LAN, RabbitMQ can get network partitions if your
server has high enough CPU or I/O load. Another thing that can induce network
partitions is soft kernel lockups, which is common enough in virtualized
environments; for example, VMware's vMotion can move a node from one physical
machine to another, a process which can take several seconds, during which
time RabbitMQ gets a fit. In such cases you'll want to increase the
"net_tick_timeout" [4] setting.

[1] [http://aphyr.com/posts/315-call-me-maybe-
rabbitmq](http://aphyr.com/posts/315-call-me-maybe-rabbitmq)

[2] [https://www.rabbitmq.com/ha.html](https://www.rabbitmq.com/ha.html)

[3] [https://www.rabbitmq.com/partitions.html#automatic-
handling](https://www.rabbitmq.com/partitions.html#automatic-handling)

[4]
[https://www.rabbitmq.com/nettick.html](https://www.rabbitmq.com/nettick.html)

------
StavrosK
Only semi on-topic: Anyone hiring experienced remote Erlang developers? 30
years of experience or so.

~~~
ccozan
My next start-up will be based almost 100% in Erlang ecosystem. So, once this
happens, I will definitively look for experienced people, working remote. I
would add you to my candidates, if you send me a CV to costin at cozan dot
com.

~~~
StavrosK
It's not me, but I'll pass your email on, thanks!

------
querulous
erlang's whole design is what OO promised but failed to deliver. it's
completely trivial and natural to represent programs as a collection of
loosely coupled state machines that communicate asynchronously. it turns out
this is a fantastic model for anything network related but also for
programming in general

~~~
IndianAstronaut
This is quite interesting. I am currently working on a Java based state
machine and it solves problems in a very unique way. It is quite a change from
procedural code.

------
mahmud
Op's work environment is _exceptional_ in many ways. It's a quintessential
hacker work place. Unbelievable flexibility. I am sure a place like that
attracts people who can make any technical edge, however miniscule, into a
real felt advantage. I want to learn about their management, hiring and
culture-building practices more than their actual hacking triumphs.

~~~
MrBuddyCasino
"As for encouraging adoption, I recommend you solve a problem in your spare
time that your company has, in Erlang, and demonstrate how easy it is to
maintain compared to whatever the accepted solution being worked on is. That's
a lot safer thing to your management than "throwing money at a new toy, hoping
for a payoff"."

For me, this translates to: invest unpaid time for your employer to improve
things, on the off chance that it will be accepted. I understand where he's
coming from, but that borders on self-exploitation.

~~~
scribu
I agree that in an ideal situation you would get paid for coding up a
prototype for the company.

On the other hand, if it gets accepted, there might be several benefits that
could make the unpaid time worth it:

    
    
      * getting a raise or a promotion for the initiative
      * better work environment due to using the best tool for the job

------
cowabunga
Not sure I agree with the conclusions:

1\. Binaries: this isn't really an issue. We ship the JVM _with_ anything that
we do in Java. Unzip, run, done. Go is probably ideal there but it doesn't
support embedded resources without some hideous hacks so you're still going to
be deploying more than just a single binary in a lot of cases. CLR is pretty
good at this as well.

2\. Sockets: 0MQ/WCF/JMS/any stream abstraction wired up correctly.

3\. ASN.1: Everything has ASN.1 libraries these days. I've never had to use
one in the real world in any of the sectors I've worked in.

3\. Let it crash: we do this. In fact we force _threads_ to crash if they do
anything bad by throwing an exception that isn't caught. All threads are
designed to be idempotent, restartable and transaction aware. This is true in
JVM/CLR at least.

4\. Supervision: New thread, new state, no shared state. Not hard. PHP does
this...

5\. Inspection: I've seen the Erlang toolchain and it's pretty good but I'm
not joking but inspecting and debugging the state of a system is better when
there is lots of pooled knowledge (google) and lots of diverse tools. JVM wins
there every time.

7\. Messaging is not RPC: It's not in JMS either or WCF. It abstracts the
transport away. In fact we have inproc transports in some cases that use
concurrent collections to throw messages around.

8\. Dialyzer: compiler, static typing (Java is less strong here to be honest
than say C#).

I really like the idea of Erlang but the worse is better mantra applies here.
It's easier to get staff, the knowledge when something goes pop is available,
we benefit from the reuse of billions of lines of code written and tested by
others if we pick a JVM. If we have to think a bit or throw some more kit at
it, so be it.

Edit: just to add, I'm not knocking Erlang and quite like it in principle (I
spent 2 months disassembling CouchDB to see if we could maintain it so it's
not a foreign language to me), but the justifications in the reply aren't
particularly unique ones nor are they major advantages.

~~~
davidw
He's talking about dealing with binary data when he says 'binaries':

[http://www.erlang.org/doc/efficiency_guide/binaryhandling.ht...](http://www.erlang.org/doc/efficiency_guide/binaryhandling.html)

[http://www.erlang.org/doc/programming_examples/bit_syntax.ht...](http://www.erlang.org/doc/programming_examples/bit_syntax.html)

Erlang is really strong for that.

As to Java, sure, you can do anything with it, and do a decent job of it. But
sometimes, as a startup, you are resource constrained, so if you can do more
with less because you have a good grasp of a tool like Rails, or Erlang or Lua
or whatever, that might make the difference. For a large company, Java is
definitely a safe pick - no one ever got fired for choosing it: you'll be able
to get whatever you need done, and "If we have to think a bit or throw some
more kit at it, so be it." For a group like WhatsApp, Erlang seems to have
been a good pick.

~~~
rwmj
I copied my OCaml bitmatch library from Erlang. It's a really great feature of
Erlang.

[https://code.google.com/p/bitstring/](https://code.google.com/p/bitstring/)

------
alecco
Repost

[https://news.ycombinator.com/item?id=8560579](https://news.ycombinator.com/item?id=8560579)

~~~
philangist
I'm not sure what you're getting at here. Does it matter if it's a repost if
the other link has 6 upvotes and 0 comments?

------
TheMagicHorsey
Someone correct me if I'm wrong, but it seems to me the main advantage of
Erlang over something like Go, is that the logic for your entire cluster is
contained in Erlang itself, as opposed to in some external scripts or
configuration. What I mean specifically is that it seems like you don't need
anything like Mesos or Kubernetes to monitor and relaunch processes across the
cluster. OTP within Erlang does that for you.

Now whether this is worth the tradeoff of switching to a new language and
framework (OTP is a framework even if it is lightweight to use) depends on the
team I suppose.

This is just based on my reading of the docs. I hope someone more experienced
will correct me if my take is wrong here.

------
ColinWright
_Added in edit: Seeing that this is getting down-votes suggests either that I
've not been sufficiently clear in the point I'm trying to make, or that you
think I've phrased it in an unacceptable way. Either way, sorry you don't
think this fits here, but I'll leave it for others to down-vote, correct,
reply to, or support, as they see fit._

 _Another edit: Getting more down-votes, but not learning anything. Do you
think this is the wrong place to say this? Or do you think I 'm just wrong to
worry about this level of precision in "normal" speech? Reply! Engage! Tell me
why I'm wrong._

========

I'm going to be "that guy" ... warning: Rant ahead.

The wording of this question is like sandpaper on my brain - for me, the
"only" is misplaced. Assuming he is asking:

    
    
        What is there that I can do in Erlang,
        but cannot do (or is significantly more
        difficult to do) in other languages?
    

With that reading, I feel the question should be:

    
    
        What can I do only in Erlang?
    

The question as phrased, to me, admits the alternate interpretation of:

    
    
        What does Erlang force me to do?
    

English, and natural languages in general, are weird things. To quote the
great Terry Pratchett:

    
    
        It's very hard to talk quantum using a language
        originally designed to tell other monkeys where
        the ripe fruit is. -- (Night Watch, 2002)
    

I'm sure I've seen it before, but Google searches are just turning up places
where I've re-quoted it, but:

    
    
        When using plain language is it difficult
        to construct a sentence that a determined
        adversary cannot misconstrue.
    

You may argue that in this case it doesn't matter, but I would suggest that
practising precision in language is important, and helps to avoid sloppy
thinking.

This comment is intended to be constructive, although I admit freely that it
is off-topic for the submission. Even so, I think it's useful to think about
these things. I wonder if Erlang makes it easier to be truly precise about
something.

~~~
triangleman
"Only" is an adverb in this case, and can be placed anywhere in the sentence
for stylistic reasons.

In all spoken language (as well as computer language), context is king, so we
all knew what the title meant, your sandpaper notwithstanding.

If the author was trying to ask "What does Erlang force me to do?" then he
would have written that.

~~~
ColinWright
Thank you for your reply - it's very useful to me to see the viewpoints of
others. It's becoming clearer all the time that my use of and views on
language are very much in the minority.

However, to respond ...

    
    
      > "Only" is an adverb in this case,
      > and can be placed anywhere in the
      > sentence for stylistic reasons.
    

That doesn't seem right to me.

    
    
        Only what can I do in Erlang? 
        What can only I do in Erlang? 
        What can I only do in Erlang? 
        What can I do only in Erlang? 
        What can I do in only Erlang? 
    

These, to me, mean different things.

    
    
      > we all knew what the title meant,
      > your sandpaper notwithstanding.
    

This is a case of "plausible interpretation" and I agree completely that of
the different interpretations, probably only one of them really made sense
given the context. It is still the case that I had to re-read to make sure
something else wasn't meant, and I find it hard to believe that I'm unique.

But what I take away from your comment is that, in your opinion, we should
just go with the most plausible interpretation we can think of, and not worry
too much about being too precise. You are clearly in the (possibly
overwhelming) majority.

~~~
triangleman
OK, maybe "anywhere in the sentence" goes too far.

But the need for style in writing is super-important.

If I was telling you about how to beat the 2nd level of Legend of Zelda, I
might say

    
    
      You can only get to the final boss by taking the door on the right.
    

Or I might say

    
    
      You can get to the final boss only by taking the door on the right.
    

Which phrase has more impact in your opinion?

Also note that in neither of these cases am I implying

    
    
      You can only take the door on the right.

~~~
ColinWright
I agree entirely that style is important, and moving words around can create
different effects. No doubt about that.

Consider your example. You offer:

    
    
        You can only get to the final boss
            by taking the door on the right.
    

I don't know if that means that (a) if I take the door on the right then the
only thing I can get to is the final boss, or if it means that (b) to get to
the final boss the only thing that will be successful is to take the door on
the right.

On the other hand:

    
    
        You can get to the final boss only
            by taking the door on the right.
    

That doesn't seem to suffer the same ambiguity.

The question is whether, for any given case, stylistic effects trump less
ambiguity. People seem to think it does more often than I do.

------
halayli
For those interested in scalable and fast socket handling in C/C++ using a
threaded-like approach, take a look at lthread & lthread_cpp bindings.

[http://lthread.readthedocs.org/en/latest/](http://lthread.readthedocs.org/en/latest/)

[http://lthread-cpp.readthedocs.org/en/latest/](http://lthread-
cpp.readthedocs.org/en/latest/)

------
davexunit
Erlang aside, I was pleasantly surprised to see that this person uses Guile
Scheme for internal tools at their workplace. That's awesome!

------
mtdewcmu
I got the sense that Erlang overlaps somewhat with node.js in terms of what
one might use it for. Could anyone familiar with both compare them?

~~~
rubiquity
I have experience with both Erlang and Node.js so I feel it's acceptable if I
answer this question.

I would use Erlang for anything I would have used Node.js for and I haven't
touched Node.js since I've learned Erlang (and Elixir).

\- Erlang allows both CPU and IO concurrency.

\- Like Node.js, all I/O in Erlang is non-blocking. The difference is that in
Erlang your code looks synchronous. There is no callback/promise/whatever
sewage all over your codebase, the Erlang VM and its schedulers take care of
that for you.

\- Messaging is built directly into Erlang, so communicating across OS
processes, and within processes, is trivial. In Node.js you have to implement
this yourself and will screw it up.

\- Node.js doesn't give you any tools for fault-tolerance or distribution,
Erlang is best in class for this.

\- Erlang has pattern matching and tail recursion. This helps you create much
more concise programs than JavaScript does.

\- Because Erlang is CPU concurrent and Node.js only offers I/O concurrency,
Erlang programs are incredibly consistent in their response times. In Node.js,
as your programs grow and take up more CPU time (thus blocking the event loop)
you will notice your 99th percentile response times are way above the average.

~~~
rozap
Your second point is extremely important. My elixir code is way cleaner than
my node.js code. You aren't constantly thinking about async stuff because each
connection is in its own process. Just write your code and let the process
scheduler do the hard work. I don't think I could ever go back to node for a
medium or large web app. Elixir has been so much simpler, even though I've
been learning the language as I go.

It also has benchmarked extremely well...

------
philip1209
Technically in turing-complete languages, there is nothing that one language
can do that another is incapable of, correct?

~~~
orbifold
Not really, the runtime system plays a huge role into what a language can
conceivably do. Think Ruby and Python and their global interpreter lock or all
languages with mandatory garbage collection and no pointer types.

------
hiring_sucks
How does Akka (Scala/Java framework) compare to Erlang? It seems to deliver on
the same promises that Erlang does.

------
koloron
How does Haskell compare to Erlang regarding these features?

~~~
Ixiaus
This is where many people get confused.

If I have to build a distributed system, I will pick Erlang/OTP over Haskell
any day.

Everything in Haskell is wonderful, including concurrency. It does not have a
built in DNS system (for node discovery and connection), inter-node RPC in
Cloud Haskell is a joke compared to Erlang, and many other issues.

I've built systems where I used Erlang as the distributed "coordinator" and
Haskell for _on the machine_ computing.

------
bachback
ZeroMQ gives you the same but better: messaging in any language. That means
you can interface to any component you want written in any language you want.
Also hiding native sockets, which means networking is not 1:1 but based on
scalability patterns. At some point people will realize what a big deal that
is.

~~~
Spearchucker
Nobody needs reliable messaging: [http://www.infoq.com/articles/no-reliable-
messaging](http://www.infoq.com/articles/no-reliable-messaging)

~~~
bachback
Tell that people who are trying to build scalable network applications.
Saltstack uses ZeroMQ under the hood and the biggest cloud computing
operations in the world use it. That article reads like from a past age, where
you didn't have startups scaling to millions of users based on cloud
computing. HTTP was invented for retrieving hypertext documents. Not for
connecting millions of nodes.

~~~
Spearchucker
Scale covers lots of things, including statefull v. stateless and (appropriate
to this discussion) asynchronous comms and the ability to queue requests.
Scale in that sense is facilitated by retrying a remote call that failed -
possibly because the server is at capacity. That implies store/forward, which
is what the "queue" part of message queuing does. You can definitely use tools
like ZeroMQ, MQ Series, MSMQ or WCF to achieve that. You can also use a
database table with a flag indicating whether a message was delivered or not
(ref. my link above).

Not quite sure what HTTP has to do with message queuing, other than being a
protocol one might use. If scale is so important, perf is a concern, in which
case UDP would be a consideration. Would I go down that road? Doubt it,
because I suspect the acceptable answer lies somewhere between HTTP and UDP,
and I also suspect that better gains can be made by optimising end-to-end
throughout and solution design rather than worrying about the semantics of a
protocol. What's the benefit, for example, of streaming data over a TCP
connection when that data is XML? TLV or some other binary format will serve
you a lot better.

Final words on scale - asynchronous delivery (such as message queuing) is one
technique. Another is to scale servers out and/or up. Also, as already
mentioned, server state and of course pipeline/routing efficiency. Whilst I
stand by what I said, I've not had the opportunity to work at the scale you
have, so I'd love to know what problems you've encountered when scaling to
millions of nodes.

~~~
bachback
Examples can be found here
[http://zeromq.org/docs:labs](http://zeromq.org/docs:labs) AFAIK Twitter storm
uses ZMQ under the hood.

~~~
Spearchucker
Not seeing anything that invalidates what I said.

