[erlang-questions] Erlang newbie questions

CGS cgsmcmlxxv@REDACTED
Tue Oct 18 13:29:39 CEST 2011

Thanks, Joe and Ulf for those comments. Yes, I was missing that part in 
expressing my point. In my post, there were just two simple points I 
wanted to pass further:
1. one cannot compare a single thread application written in C with 
multithread application in Erlang (if you do want to compare, the 
comparison should go from multithread Erlang application to multithread 
C application);
2. as Joe simplified and I was also mentioning that, one doesn't need to 
reinvent Erlang/OTP when you have it already.

Joe, I met cases when those 5% meant a lot (especially in the long time 
consuming physics simulations). In those cases, I would still prefer C 
to Erlang. But, as I said, each language has its own beauty and you need 
to look at it from the correct angle to make the best use of it. I would 
still write a game AI in C and not in Erlang or JavaScript (where there 
is an attempt based on jQuery). Maybe it's about me, but I still 
consider C as being more suitable for that task. On the other hand, as I 
said it before, I wouldn't start writing a network application in C when 
Erlang provides such simple ways to do it. But these are just examples 
and there is much more in each of them. So, it's a matter of what you 
need and where each of the languages shows more beauty in approaching 
the problem. I wouldn't just discard C yet, but I wouldn't deny the 
productivity of Erlang. It's the same case with all the languages: they 
came as a need to cover different sectors (and I can give a lot of 
examples, but you already know them).


On 10/18/2011 12:26 PM, Ulf Wiger wrote:
> On 18 Oct 2011, at 12:20, Joe Armstrong wrote:
>> On Tue, Oct 18, 2011 at 11:53 AM, Ulf Wiger
>> <ulf.wiger@REDACTED 
>> <mailto:ulf.wiger@REDACTED>> wrote:
>>> On 18 Oct 2011, at 11:47, Joe Armstrong wrote:
>>> Mutithreaded C implies some kind of data exchange between
>>> different C threads - now there are many ways to do this - the
>>> cleanest alternative
>>> is by copying message passing. The dirtiest - is by shared memory and
>>> mutexes.
>>> I beg to differ. The dirtiest way is by shared memory *without* mutexes.
>> You mean ... I didn't know that was possible - I though emacs detected
>> this and you were instantly
>> fired and your house set on fire, and your bones melted down for glue
>> and so on …
> Like I said… dirty.
> I recall an admonition from a seminar on programming for multicore:
> "You cannot use priorities for mutual exclusion!"
> Presumably, this technique is commonly used, since it was deemed 
> necessary to point out especially that this is not safe on a multicore 
> machine.
> http://www.chibios.org/dokuwiki/doku.php?id=chibios:guides:mutual_exclusion_guide#priority_boost
> BR,
> Ulf
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111018/60c1811d/attachment.htm>

More information about the erlang-questions mailing list