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

[Torben Hoffmann]

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.

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