You don't need anything but assembler. Yet you just named three languages and not a one was assembler. Once we've admitted that the niceties offered by more specialized languages are worthwhile, that "you don't need a new language" argument becomes a whole lot less compelling. For all you know, maybe programming this stuff in C++ is like programming sequential code in assembler — dismissing it just because the tool you have can be made to do the same thing isn't bad (I'd never disparage people who accomplish things), but it doesn't make a very compelling case for anything besides your own comfort zone.
What you've just laid out is what I guess people call a "straw man". No one is arguing assembler over C here, just like no one is arguing the virtues of vacuum tubes over the transistor.
I'll say it again: the benefits of the concurrency model described in the original article can probably be achieved in peoples' existing/preferred dev env. It's easier and faster to look into that then to throw what you have under the bus for erlang.
If you want to get into logical parlance, it isn't a straw man, it's reductio ad absurdum. That is, you take somebody's reasoning and apply it to a different situation that illustrates the problems in the reasoning more clearly.
In this case, your thinking appears to be, "I can accomplish the same thing in C++, so why use Erlang?" My point is that an assembly programmer might just as well say, "I can accomplish the same thing in assembly, so why use C++?" The answer is that it's a lot easier and more natural to write OO code in C++ than it is to use, say, assembler macros. The fact that something is possible is less interesting than how simple and well-supported it is.
Again, I'm not saying your choice is necessarily wrong. For your use case, it might have been right. The benefits of using a language with pervasive and highly developed support for the paradigm might not outweigh the benefits of using C++ for you. But that reflects more on your personal circumstances than on the benefits of Erlang in general.
>In this case, your thinking appears to be, "I can accomplish the same thing in C++, so why use Erlang?" My point is that an assembly programmer might just as well say, "I can accomplish the same thing in assembly, so why use C++?" The answer is that it's a lot easier and more natural to write OO code in C++ than it is to use, say, assembler macros. The fact that something is possible is less interesting than how simple and well-supported it is.
What you seem to miss is that C++ also has some inherent value that cannot be replicated in Erlang. Namely: C++ is not assembly. You are already working on a higher level language. So the question is not "assembly or some higher level" but "how high a level should I go"?
Your response is essentially: "you should go to the highest level you can for concurrency, which (in your opinion) is Erlang".
The problem with that: you essentially reduce the whole problem domain to handling concurrency. Not what I call a good engineering analysis.
How about reusing HUGE EXISTING C++ libraries for his problem domain, instead of replicating them in Erlang?
How about reusing a ready team of C++ experts in his company, instead of retraining them in Erlang?
How about reusing existing tooling and infrastructure his company has for C++, instead of throwing it and using Erlang?
How about interfacing with external systems for which he has C++ drivers, but no Erlang ones?
You say: "The fact that something is possible is less interesting than how simple and well-supported it is". Maybe. But well supported is also not just a language attribute. How well supported it is within the industry, within his company, with his toolset, with the code he has etc?
You basically just restated the last paragraph of my comment as though it were something I haven't thought of.
I'm not trying to tell everyone to use Erlang. Getting things done is more important than the tool you use to do it, so whatever does that for you is good. But I'd be really amazed if somebody had used both Erlang and a C++ actor library and come out thinking that C++ was about as good as Erlang at its own game.
>You basically just restated the last paragraph of my comment as though it were something I haven't thought of.
Guilty as charged.
I tried to answer both you and the other guy in the same thread that advocated Erlang-over-C++ without making the considerations you made in your last paragraph, and I guess I should have added something to distinguish your two cases.
> the benefits of the concurrency model described in the original article can probably be achieved in peoples' existing/preferred dev env.
No, they can't. This has been well explained elsewhere. You'd have to rework the language/dev environment down to at least the C level if not assembly.
>It's easier and faster to look into that then to throw what you have under the bus for erlang.
No, it is slower and harder.
People think Erlang is difficult simply because the syntax is weird. Spend a couple weeks learning it and you'll be up to speed.
I think people are scared off by the syntax and so are trying to rationalize that they don't really need erlang.
It is possible to replicate erlang elsewhere, but you'd have to replicate erlang. You can't just add a library to ruby and get it.
The problem with the syntax isn't that it's weird. It's just ugly. Even Perl and C++ look nicer. It's the 1998-geocities-site-full-of-animated-gifs of programming languages.
I thought this way about Erlang code at first too, but after a short time I came around and now I think it can be extremely elegant and even beautiful.
Totally disagree. Erlang is odd, but you have to understand what you're getting with that. Variable unification, etc., if very powerful (kind of like Haskell's pattern matching but a bit more powerful).
Not sure why this is so tough for people to understand. You usually don't need a whole new language to use a paradigm.