[erlang-questions] Attracting Functional Programmers
Sun Oct 7 17:14:43 CEST 2007
Interesting points. While I agree with most of your points, I think
there is a fairly well understood model which seeks to address and
organise a broad picture for technology adoption. A key approach is
to focus on things that the adopter will recognise. I don't feel
these are economic (in it's simple sense), or even very technical.
First, let me say that I believe Erlang/OTP has 3 key 'sweet spots'
1. Highly available, robust, systems. We can economically build
Erlang systems which can provide extreme availability, deal with
failure and 'heal' in a much wider range of circumstances than any
economically viable alternative. Why would anyone *ever* build a
system with inferior availability? I don't think it's simple economic
grounds, because Erlang/OTP technology is cost competitive , and
there is some evidence (unlike many other 'productivity
technologies') that its productivity can offset "ramp-up costs" and/
or higher salaries.
2. Scaleability, Erlng/OTP can scale to support every size of
enterprise, utility, national and international system. I think you
could run the next Olymics on Erlang/OTP. Or the UK National Health
service. Property 1 makes Erlang/OTP compelling. Again, I don't think
it's the economics of the technology which is preventing this.
3*. Taking advantage of many-core processors. I believe there are
many different types of problems/ Erlang/OTP is well suited to, from
small grained problems upwards. Once more, though, I don't feel it is
the economics of the technology which needs to be overcome.
Summary, in these three areas, Erlang is the most mature and
commercially viable technology available.
IMHO, it's that simple.
I can assert that because if there was a better technology, we would
all know about it (and I wouldn't be here !-)
To some extent, these are independent, and so could be pursued
differently. I think 3 becomes 'killer' as numbers of cores
increases, but today, 1 and 2 are, IMHO 'killer' if we can overcome
the actual obstacles. I do not believe the obstacles are economic
I am a fan of "Crossing the Chasm:
Marketing and selling technology products to mainstream customers:
Marketing and Selling Technology Products to Mainstream Customers"
by Geoffrey A. Moore
(and his other book, Riding the Tornado)
This provides a rich model of technology adoption from creation,
through visionaries, early adopters, early majority, main stream and
eventually luddites (yes the day may eventually come when people
think Erlang/OTP is very old, and the world has moved on. I vaguely
recall, when designing Ada, the DoD thought 40 years was the
*minimum* useful life for their purposes). I you are interested in
this area, and haven't read it, I strongly recommend you do. I think
he covers all of David's points, in the more general case, along with
A key message of Geoffrey Moore is identify a target market, and
focus on the early adopters (I think Erlang is well past the
visionary stage). This largely means adjusting the product to fit the
key needs of a specific market (preferably specific customers). If
I've understood your points David, this is what you believe too. I
believe Erlang/OTP has already done this for telecoms, but questions
remains as to whether there is more to be done for other markets. For
example, I believe that a few more pieces would make Erlang much more
attractive to manufacturing industries. Similarly, a little work to
enable 'rich client' (AKA AJAX-style) web applications, etc. I accept
that, to experienced Erlang-ers these things may be no more than
hours, or a few weeks, but, you aren't the adopter. For *potential
adopters* it may seem a very far away goal.
Moore goes onto explain, once you've got the early adopters, go after
the "more aware" members of the target market sector, the early
majority. To capture the "early majority"; resolve their issues by
make the product attractive to them. This is usually not technology
or functionality issues. I think the target users in this group are
companies; developers are often visionaries and early adopters. For
companies, it is about forms of risk, credibility and publicity.
Ericsson and a few others are the early adopters, and the detail of
their use and experience is critical collateral for taking Erlang
further to the early majority. The purpose of this collateral is to
reassure potential adopters that the technology is low-risk; that it
works well enough that they "won't get fired for buying in to it",
and it has a lifetime. I believe Open Sourcing helps, but, there are
many, many more dead Open Source projects than live ones; the vibrant
community around Erlang is very important too.
But key, is the evidence from actual users, who deploy it at similar
or better levels of scale, availability and value to their business,
because two key benefit are deploying Erlang/OTP at scale in highly-
available applications. This evidence doesn't come from inspection of
the functionality, or by designing and running benchmarks, or
anything else that a a small group of people could complete
internally in a couple of months feasibility study.
When a prospective adopter looks at Erlang they need evidence. As an
example, imagine I was some company reading about Erlang with a view
to potentially using it. I could read that Ericsson uses Erlang in a
product, and that would help demonstrate that it has got beyond the
lab. Unfortunately I can't directly find out if the product is
successful, has been widely purchased, is it still in production, or
whether it is in a niche used by one customer who has subsequently
given up using it. IMHO succesfully marketing technologies does not
require 'rocket science', just making sure the right information is
Other valuable evidence for prospective adopter are things like
support cost, etc, etc. Some of these are commercialy sensitive, and
we may need to find ways to keep everyone happy.
For any adopter, a key issue is "how do I get support?" For example,
what would happen to his notional adopter if they adopted Erlang/OTP
for one project, but went no further? A bad answer is "that would be
a career or economic disaster"! As an adopter, I would not want the
burden of retaining an in-house team of Erlang/OTP experts who are so
familiar with Erlang/OTP's internals that they could fix any problem.
I would want to know how I get support from a 3rd party, at a
reasonable price, and likely to be there whan I need them for the
forceable future. I believe Ericsson handle this through their
commercial license, but that may mean I couldn't experiment with a
smaller, lower cost, potentially lower risk, project on Open Source
Erlang/OTP first. Being forced to *START* with commercial Erlang/OTP
makes adoption more complex, expensive and less likely.
The Erlang community could deal with this. Maybe it could offer a
service, maybe through Erlang.org, whereby a customer could buy a
'bug fix'. [Microsoft sell 'an incident' where you can buy a fix to a
problem for approximately $100, but lets not get side tracked onto
None of this is to say that *I* am unconvinced. After meeting the
folks who build Erlang, I am much, much happier. The point I am
trying to make is, I shouldn't need to stake my reputation and
judgement when proposing Erlang in a project. The evidence should be
available so that the decision process to choose Erlang is rationale
and transparent, and the cost and risks are easily and clearly
identifiable upfront, with no surprises.
So, I think Erlang/OTP adoption would be significantly improved by
gathering and organising up evidence of its successful and continued
use, and more simply and clearly defining the markets in which it is
a 'good fit'. It is useful to define the markets, and not just the
properties of the applications, so that potential adopters can
recognise that it is already ready for them.
PS * - I would like to qualify point 3, about Erlang and many-core.
There are applications, where alternatives are very relevant too. For
example image processing using photoshop or the gimp, where even
finer grained data-parallel technology is extremly effective. So,
though it is completely practical to write a gimp plugin for image
processing with Erlang/OTP (I have written one using NVIDIA CUDA, so
I can speak from experience), technologies which implement even finer
grained parallelism are also relevant. But this isn't to detract from
the point, just remind us that it isn't necessarily one size fits all.
> On 10/6/07, G Bulmer <> wrote:
>> During the CUFP workshop, people talked about attracting developers
>> to FP.
>> The Haskell web site was compared to the Python (I think) web site.
>> I believe the pitch for Haskell was much weaker than the Python
>> I took a stab at a few 'marketing' statements for Haskell. My
>> intention is to stimulate debate because I do feel there are
>> unnecessary barriers to recruitment. I do not expect my suggestion to
>> survive :-)
>> You may want to take a look at http://groups.google.com/group/cufp/
>> I am G B-)
> I think it's a fascinating subject. If you don't mind my trying to
> foist off some of my own work on you, I've written about it a little
> My take is that if you introduce a new language, and you don't have
> millions of dollars to push it (Java, C#), you're going to have to
> find some niche, and do it an order of magnitude better than the
> competition. Something that's not just an incremental improvement,
> but a clearly superior way of doing things, where "things" means
> something that matters to your average industry programmer.
> To my way of thinking, this would explain why Erlang is getting a lot
> of attention from people these days - it does concurrency really well.
> That one thing, which is seen as increasingly important in a
> multi-core future, is enough for people to pick up Erlang and look at
> it. In the past, Tk was enough to get people interested in Tcl, the
> promise of very easy dynamic web pages got people interested in PHP,
> Ruby on Rails got people interested in Ruby, and so on. Of course,
> that's not the only way languages grow in popularity - Python
> gradually built up a following by being simple, clean and practical
> for a wide variety of tasks. It does seem to help a lot though - if
> you get that "killer app", people will, at least for a while, ignore
> other shortcomings in a language, which is crucial, because it's very
> likely that a newcomer won't have huge libraries, books, user groups
> and some of the other positive externalities that come with
> David N. Welton
More information about the erlang-questions