[erlang-questions] Trying to change things
Sun Jul 4 16:55:51 CEST 2010
I second many of Bernard's observations - see
our personal war story.
See the slides and come back with additional questions - I have some hidden
slides and notes I can dig out for you.
2010/7/4 Bernard Duggan <>
> Hi João,
> On 4/07/2010 10:02 AM, João Henrique Freitas wrote:
> > Hello,
> > I am working on a place wich uses the CHILL language programming to
> > develop a huge telecom system. We use others languages too like C and
> > C++. But CHILL is the largest code base.
> We were in almost exactly the same situation as you a couple of years
> ago, minus the CHILL - we were just using C/C++.
> > I staring to learning Erlang about six months ago and in the last
> > three months I spent a lot of energies trying persuade developers to
> > change from CHILL/C/C++ to Erlang.
> We did that when we first discovered Erlang too - doing that without a
> lot of stuff to back you up (see below) is almost certainly doomed to
> > But is hard change things. Anybody have some experience with these
> Yes, indeed I do :) I'm not going to proffer what I'm saying as general
> advice, but it's what allowed us some progress in our particular
> situation. Here's what we did:
> * Start, in your "spare time", to write something in Erlang that's going
> to be useful but doesn't exist yet because "we'll get to it later,,,when
> we have time" :) (Make sure you treat this as a learning experience -
> you /will/ look back at this code in a couple of years and marvel at how
> terrible it is, I promise you :)). In our case, one of the biggest
> problems we had was that we had no good way to test how the system would
> behave when we plugged 3000 phones into it, because we had neither 3000
> phones nor the 3000 QA guys to run them :) Erlang's concurrent nature
> made it a perfect fit for this kind of role - acting exactly like a
> whole pile of phones. After a few months we suddenly had a tool that
> both allowed us to do something really useful and showed off Erlang.
> * Make sure everyone knows how awesome this is, and that they know that
> it's awesome, at least partly, because it's in Erlang (and also,
> naturally, because /you/ wrote it :)).
> * Hopefully, people will start asking "why doesn't it do X?" (though
> they'll rarely marvel at how something useful sprung up without them
> having to do anything or even ask for it - it's all about what it
> /doesn't/ do). Once again, you can show how nice and easy Erlang is to
> modify by adding X. But make sure you /show/ them how easy it is to
> add. Maybe they might want to add the next feature themselves (because
> you're really busy right now...)? Hey look - you have another person
> writing Erlang :)
> * Make sure you read up on all the great stuff Erlang can give you -
> especially the reliability and "safe crashing" aspects. Telco people,
> especially, /love/ reliability for obvious reasons. We have a process
> where one single bad pointer can take down 5000 phones for 20 seconds -
> imagine how aweomse it sounds if a bug in your code will, in all but the
> worst possible cases, take down only one or two!
> * This step is where, I think, we got a bit lucky - we started actively
> agitating to write new bits of the core code in Erlang. Depeding on
> your system, that's probably going to have a high startup cost in terms
> of writing a layer to interact with the legacy code. Somehow we
> convinced them it was, in fact, the "way forward", but we didn't have
> time to convert anything that we currently had (fair enough - it was all
> "working" okay). But then we got another lucky break when we were asked
> to write a whole new module for the existing core system, and the job
> was given to the two biggest Erlang users :)
> * This time, we didn't try to sneak it "under the radar" - we said we
> wanted to do it in Erlang, said there would be a certain cost to getting
> the initial interface layer written, but also made it clear that we were
> totally convinced it would pay off, even for this single module. Based
> in no small part on our earlier success with the testing system, we got
> the go-ahead.
> * The only other suggestion I can give is, if you get to that stage,
> take as much time as you can to make sure you get the first serious bit
> of Erlang stuff "right". If you still have nay-sayers, they will be
> looking for any little thing that goes wrong as a way of saying "see?
> Told you Erlang was rubbish - we should be sticking with good-ole
> reliable C++". Never mind that the C++ stuff crashed twice a day when
> they first coded it :)
> Like I said, that's just our story - it may or may not be any use to you.
> > My boss question me about 'Who is using Erlang?' and I am trying to
> > found some in my country (Brazil).
> Can't help you with that one, sorry (not for Brazil, anyway). What I
> /would/ say is that it's entirely typical of "management" to take the
> "well if it's so great, why isn't everyone else using it?" attitude.
> I'm sure it's self-evident to everyone on this list why that very
> question itself is wrong, but it's the job of management not to screw
> up. If they have something that is seen to be working (for some
> definition of "working"), the choice they see is between a "zero risk"
> option of changing nothing or a risky option that some guy is telling
> them will make things better. It's always the easier choice to stick
> with a known quantity. I'm not meaning this as some kind of
> "anti-management-they're-all-morons" rant - they have a different
> perspective on things and I can totally understand their reluctance to
> move away from a known quantity.
> > Now I can't waiting more and start a internal project to interfacing
> > with CHILL/C/C++ old base and Erlang.
> Good luck! Let us know how you get on.
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
More information about the erlang-questions