[erlang-questions] Erlang is the best choice for building commercial application servers

[Michael Turner]

Joe writes:
> "All" you have to do is:
>
>   a) - choose a new and "likely to be trendy" standard
>   b) - implement it *all* in Erlang
>   c) - do significant work with the standardization committee
>   d) - make a product
>   e) - give the product away or sell it
>   f) - sell support
>
> Examples of this are (xmpp - process one) (netconf - tail-f) (AMQP - rabbit MQ)
> (this is a list of (protocol, company) pairs)
>
> The tricky bit is choosing a) (many choices) b) (more tricky than you
> think) and in the c) .. f) parts much can go wrong.

(a) A long time ago, in a galaxy far, far away, a company called
Autodesk was just a gang of friends who all chose to hack on different
product ideas, while also pledging fealty to whichever idea really
took off. What took off was Autocad. I think all those Autodesk
startup people got rich. So if a bunch of good Erlang programmers got
together under a similar agreement, and each chose a different "likely
to be trendy" standard, the chances of catching a wave might be
greatly improved. Erlang's features make each programmer significantly
more productive than others attempting the same with less-suitable
languages/platforms, so the intuitively obvious "dilution of focus"
counter-argument isn't quite as strong here.

(b) Let's say they all worked in a collegial "open door" manner where
they could pick each others' brains. This would be more likely if they
all keep each other briefed on their progress at regularly scheduled
demos and presentations, and always at least went to lunch together
several times a week even if they mostly worked at home. Then the
risks in "implement it *all* in Erlang" might also be reduced:
*somebody* in the group is likely to know how to do what you don't
know how to do.

(c) Let's say this group appoints one of their number to be nothing
but a liaison to standards committees. (There are people who actually
thrive on this kind of work, believe it or not.) This reduces the
effort per programmer on the legwork and wrangling related to staying
abreast of standards and contributing to them.

(d,e,f) Many a startup has come to grief on issues of execution. If
your pick for the multi-tasking liaison is also someone with
significant product management experience in protocol software
products, you've got a key member who gives your startup a fighting
chance at defying the harrowing infant-mortality statistics for young
companies. What happens when the clear winner emerges among the
varying efforts? Your standards-committee liaison is almost completely
up to speed on a whole spectrum of issues in marketing, product
management, technical publications, etc. for the *specific* idea that
has become the company's main focus. Maybe not a CEO type. But he/she
might do until the real thing comes along. And venture capitalists are
often only too happy to give you "the real thing," as a condition of
first-round financing. (But watch out for that, because sometimes they
regard certain fledgling endeavors as little more than training wheels
or reality tests for startup-CEO-wannabe types -- i.e., the real
"product" for them might be the CEO pick, with your company's failure
supposedly at least providing some instructive and/or
character-building education.)

... is how I'd strategize it, anyway.

-michael turner

On Thu, Mar 15, 2012 at 6:52 PM, Joe Armstrong <erlang@REDACTED> wrote:
> On Thu, Mar 15, 2012 at 9:52 AM, Torben Hoffmann
> <torben.lehoff@REDACTED> wrote:
>>
>>
>> On 15/3/12 2:31 , Miles Fidelman wrote:
>>>
>>> Richard O'Keefe wrote:
>>>>
>>>>
>>>> There is often surprisingly little connection between the speed of a
>>>> _language_ (implementation) and the speed of _systems_ built using it.
>>>>
>>>>
>>> Which is almost the point - there's a rather direct correlation between
>>> the speed of a system, and how well the system architecture aligns with the
>>> constructs and run-time environment of the language it's implemented in.
>>>
>>> If you're building a system that is highly concurrent in nature,
>>> implementing it in Erlang is a big win, while implementing it in Java is a
>>> big loss.  Yes, you can take something that's inherently concurrent, and
>>> design an efficient Java design, but you end up with something that's a
>>> conceptual mess.
>>
>> That is a very good point and rhymes well with the maxim of choosing the
>> right tool for the job at hand... something that can be extremely difficult
>> for all of us since we all have our favourite tool. Hint: learn more than
>> one tool!
>>
>> It triggers me to take a step back and take another stab at the original
>> topic of this thread.
>>
>> When I did my grass root (read guerilla warfare) work to be allowed to use
>> Erlang for a project in Motorola the question of performance never became a
>> serious issue.
>>
>> Why not? Because it was easy to see that if Ericsson could write telephone
>> switches in Erlang it would have sufficient horsepower to do the things
>> needed in another telecom system.
>>
>> The big worry was: "Who is using Erlang?" which comes back to the "Nobody
>> has been fired for choosing Microsoft | IBM | Oracle"-maxim. Eventually I
>> managed to gather enough evidence through the Erlang community (I am
>> eternally grateful for the not-to-be-made-public inputs that I received from
>> other Erlang warriors) to convince management that it would not be a
>> dead-end to try out Erlang.
>>
>> And now I will allow myself to digress from the original topic for a very
>> personal experience... working with Erlang has been the best experience of
>> my professional life.
>> Why? Because it was simply the right tool for the job at hand! It allowed us
>> to get a lot done since the semantic gap between the domain and the
>> programming language was so small. Not only did we get a lot done - we also
>> had very few errors and when we had errors it was very easy to debug, fix
>> and an re-deploy them. (During Interoperability testing with our competitors
>> we had turn-around times on bugs of 15 minutes versus their 1 day... I rest
>> my case!).
>>
>> So I am all for Joe's approach to project funding: get a prototype going and
>> then evolve it into a product in small increments. You will get a prototype
>> very fast - this mailing list is great for advice on how to wire things
>> together and it is not that difficult to get a quick'n'dirty solution done
>> in Erlang even without being an expert.
>
> Actually this is how to make money :-)
>
> "All" you have to do is:
>
>   a) - choose a new and "likely to be trendy" standard
>   b) - implement it *all* in Erlang
>   c) - do significant work with the standardization committee
>   d) - make a product
>   e) - give the product away or sell it
>   f) - sell support
>
> Examples of this are (xmpp - process one) (netconf - tail-f) (AMQP - rabbit MQ)
> (this is a list of (protocol, company) pairs)
>
> The tricky bit is choosing a) (many choices) b) (more tricky than you
> think) and in the c) .. f) parts much can go wrong.
>
> Note - the above three standards all involved communication and
> protocol implementation
> which Erlang is pretty good at.
>
> /Joe
>
>> If you want to do something cool with Erlang you have burn for it - at least
>> if you are not deciding what you should work on direcly - and then go and
>> execute it!
>>
>> Enjoy the ride!!
>> Torben
>>
>>
>>>
>>> The example that comes to mind is simulation.  In a previous life, I
>>> worked for a company that made military simulation software (massively
>>> multiplayer games for folks who shoot real bullets).
>>>
>>> Having a networking background, where the natural inclination is to spawn
>>> a process for every incoming task, I assumed that our simulators operated in
>>> a similar way - simulate 1000s tanks, spawn 1000 processes and do everything
>>> asynchronously.  But no... as our coders informed me (I'm a systems guy),
>>> you can't do that in Java (or C++, which was the bulk of our code) - the
>>> context switching would bring everything to its knees.
>>>
>>> Instead, each tank was implemented as an object - with 4 main threads
>>> winding their way through every object, 40 times per second.  The code was
>>> fast, but not surprisingly, it was amazingly brittle - change one object
>>> (say add a new weapon to a particular tank) and all kinds of things would
>>> have to be rewritten.
>>>
>>> My instinct that yes, indeed, one could implement each entity as an actor
>>> is what led me to discover Erlang - as pretty much the ONLY run-time
>>> environment optimized for massive concurrency.
>>>
>>> On the other hand, inherently serial applications probably run faster in
>>> languages and run-time environments optimized for small numbers of threads.
>>>
>>> Miles Fidelman
>>>
>>>
>>>
>>
>> --
>> http://www.linkedin.com/in/torbenhoffmann
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions