[erlang-questions] [ANN] Positive version 13.3.7
Fri Mar 25 23:41:10 CET 2016
I used to run a Java PaaS. A client had major growth every Jan 1 - the New
Year would literally trigger a 2x factor in subscriptions.
So every Jan 1, while the rest of the western world enjoyed time off with
family, I fought fires in trying to keep this client's services afloat
during the onslaught.
When we wanted to understand a performance problem in the code, we'd inject
some debug statements, or instrumentation - cut a release, redeploy. With
some data we'd try to understand the problem, fix, redeploy, rinse, repeat.
If you've ever deployed a debug version of your application in the middle
of an outage, you have some appreciation for the pain I felt. On a holiday.
With people demanding when I'd come down for dinner.
As a human, you remember these moments. You remember the details - every
little technical detail. They draw the line between your happiness and your
The moral of the story is, if you don't have these problems, don't worry
The Erlang VM lets you poke inside a running app to see what's broken - and
fix it without stopping. The Erlang language has features that exploit
this. OTP adds further features. These have been exercised in production
for more than a decade. That's enough time to get things working.
If finding the right language for your corporate culture is the actual
problem, then move Erlang off the board. It's just too fringe. Too hard to
find developers. Too controversial.
If you have other actual problems, Erlang might prove useful.
For my part, I'll never put a back-end system into production that's not
written in Erlang, unless there's a good technical reason. And there
certainly may be. But Erlang is my starting point, on its merits. And I'm
not saying every part of a back end system is running in an Erlang VM.
That's crazy and no one does that. But if you're writing software that runs
on a server - and you care about it running and working - what are your
Seriously. PHP? Node? Go? Ruby? JBoss? Forth? K?
Culture and history matter in technology. And Erlang has a long history of
operational engineering discipline. If that doesn't matter, it might not be
Okay, you run stuff in production, so how to get started? Find a subsystem
that's trivial to implement, but important to get right. Build that in
Erlang. It should take a few weeks. If your experience is awful, what have
you lost? If it's good, you've opened a path to a way of building and
But the problems have to be real.
Oh, and apologies if this comes across as elite. I'm actually just an
average guy who wants to have a New Year's meal with his family. True story.
On Fri, Mar 25, 2016 at 4:42 PM Matthew Shapiro <> wrote:
> Unfortunately, that's way too true :(.
> My real project I"m learning Erlang for is for an video ingestion server,
> because I believe I can create something that works better than what we are
> currently using at our company, and Erlang and the Beam VM hits every
> checkbox so much better than every other language and runtime out there.
> Unfortunately, I am also keenly aware I will never bring this into
> production at my company since we are a small startup (5 people total, 2
> engineers) in Orlando, FL which has zero Erlang developers positions around
> (and probably thus a small pool of potential developers). It's so
> fundamentally different (both on a framework and language level) from most
> other languages in this area that onboarding a new developer onto Erlang in
> sufficient amount of time is not going to be trivial or cheap, and anything
> I put into production needs to be able to be maintained by others that are
> not me. So while Erlang checks all the boxes I still can't say it's the
> right tool due to that :-/.
> space ask why I wasn't doing it in Node.js, sigh).
> On Fri, Mar 25, 2016 at 3:10 PM, Loïc Hoguin <> wrote:
>> There is no such thing as the right tool for the job.
>> There's the tools that work *for you*, and those that don't.
>> JS is working for a lot of people. Erlang for a lot less.
>> In the real world, all that matters is that the tool is *good enough* and
>> that you are *familiar* with it.
>> Any combination where one of these is false leads to disaster. People who
>> never used Erlang before will not magically come up with a good
>> implementation (they can, but it takes a lot more time). Similarly, people
>> who are trying to use Erlang for what it's not good at will also fail, or
>> struggle to make it work.
>> When choosing a tool for a project, the question should really be "Which
>> tool do I know or can quickly get comfortable with, and can help me produce
>> a working solution?"
>> The answer to that question is different for everyone.
>> On 03/25/2016 07:47 PM, Lee Sylvester wrote:
>>> JS is a major player due to laziness. I'm sorry, but a JS runtime on
>>> the server is never a good idea. I don't use Elixir / Erlang for every
>>> project, I use the right tool for the job, whether I've used it before
>>> or not. It just so happens that Elixir / Erlang is often the right tool.
>>> I'm sure it's the same for you guys? The fact that Erlangs language is
>>> poetry and Elixir's eco-system is bliss means nothing :-P
>>> On Mar 26, 2016 7:21 AM, "Michael Truog" <
>>> <mailto:>> wrote:
>>> On 03/25/2016 10:55 AM, Loïc Hoguin wrote:
>>> On 03/25/2016 02:20 AM, zxq9 wrote:
>>> EVERYONE! STOP EVERYTHING! SATIRE IS NOW "TOXIC"!
>>> Shame is temporary. A good story is for life.
>>> What happened is a story for the ages. And a pretty good one.
>>> I agree. This is a positive contribution and no one can deny that.
>>> erlang-questions mailing list
>> Loïc Hoguin
>> Author of The Erlanger Playbook,
>> A book about software development using Erlang
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions