[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]
Sun Feb 16 14:56:54 CET 2014
Pieter Hintjens wrote:
> On Sat, Feb 15, 2014 at 6:08 PM, Fred Hebert <> wrote:
>> That makes for quite a steep curve, doesn't it?
> This is a core problem. It is an uncanny valley; before you can get
> those theoretical productivity gains you have to make large
That seems like a red herring to me. Is the learning curve really that
Yes, there can be a big hurdle involved in learning to think
functionally - but that's language independent. Same again for
thinking in terms of actors and massive concurrency rather than
procedures, or objects and classes - again, that's language independent.
Beyond that, most of the real learning time and investment for a new
language involves learning libraries, the build system, and run-time
- going from "hello, world" in c, to building complete, deployable,
maintainable systems involves quite a bit (what's the investment in
learning the gnu build system?)
- Java isn't appreciably better in that regard
- and so forth
And then there's all the brou ha ha about DevOps these days - building
tool chains for rapid deployment of code that keep changing.
Interpretive languages change the mix a bit - given that some steps are
dropped out. Platforms also change things a bit. (E.g., start with a
running copy of Apache, add a PHP script. Simplifies things a bit once
you've learned the ins and outs of Apache.)
It strikes me that Erlang might actually require less learning than many
environments - in that OTP provides a platform for wiring together
complex systems, and deploying them into a run-time environment that
also solves a lot of problems for you. Yes you have to learn how they
work, and how to use them - but then again, you don't have to re-invent
> I'd love to learn Erlang, mainly because of the people who use it.
> However I'm lazy and modest in my investments and can't spend six
> months to see profit in a project. I won't use tools I can't improve
> myself. I won't join communities where I depend on others for decision
Or maybe you don't work on problems where the cost/benefit equation
makes it worth using Erlang? If your baseline is 'profit in six
months,' you're working pretty small projects. For me, it's been at
least a decade since I've worked anything where coding has started in
less than 6 months after contract award - there's always a huge amount
of system level design that goes first, including things like picking
which platform to work with.
The cost-benefit equation is VERY different when comparing, say:
- a small e-commerce site
- a large e-commerce site coupled to multi-vendor supply chain management
- a transaction processing system
- a telecom switch
- avionics for a new passenger jet
And with all but the first, long-term operation and maintenance
considerations dwarf the time and dollars required to develop the system
(or should - there are some great examples of spectacular failures that
have eaten up billions of dollars before being cancelled - like the FBI
case file system). For products (again, telecom switches come to mind),
a lot of time and capital go in before a dollar of profit is seen.
Somehow, I simply don't see Erlang being relevant if your decision
criteria is "can't spend six months to see profit in a project."
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
More information about the erlang-questions