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

[Joe Armstrong]

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