can one make concurrent scalable reliable programs in C as in erlang?

Question

Hi,

a theoretical question. After reading Armstrongs 'programming erlang' book I was wondering the following: It will take some time to learn Erlang. Let alone master it. It really is fundamentally different in a lot of respects.

So my question: Is it possible to write 'like erlang' or with some 'erlang like framework', which given that you take care not to create functions with sideffects, you can create scaleable reliable apps as well as in Erlang? Maybe with the same msgs sending, loads of 'mini processes' paradigm.

The advantage would be to not throw all your accumulated C/C++ knowledge over the fence.

Any thoughts about this would be welcome

Answer 1

I would break this into 2 questions

Can you write concurrent, scalable C++ applications

Yes. It's certainly possible to create the low level constructs needed in order to achieve this.

Would you want to write concurrent, scalable, C++ applications

Perhaps. But if I was going for a highly concurrent application, I would choose a language that was either designed to fill that void or easily lent itself to doing so (Erlang, F# and possibly C#).

C++ was not designed to build highly concurrent applications. But it can certainly be tweaked into doing so. The cost might be higher than you expect though once you factor in memory management.

Answer 2

Yes, but you will be doing some extra work.

Regarding side effects, consider how the .net/plinq team is approaching. Plinq won't be able to enforce you hand it stuff with no side effects, but it will assume you do so and play by its rules so we get to use a simpler api. Even if the language doesn't have built-in support for it, it will still simplify things as you can break the operations more easily.

Answer 3

the main 'problem' with C (or C++) for writing reliable and easy to extend programs is that in C you can do anything. so, the first step would be to write a simple framework that restricts just a bit. most good programmers do that anyway.

in this case, the restrictions would be mostly to make it easy to define a 'process' within whatever level of isolation you want. fork() has a reputation of being slow, and threads also need significant time to spawn, so you might want to use a cooperative multitasking, which can be far more efficient, and you could even make it preemptive (i think that's what Erlang does). to get multi-core efficiency, set a pool of threads and make all of them complete to run the tasks.

another important part would be to create an appropriate library of immutable data structures, so that using them (instead of the standard lib) your functions would be (mostly) side-effect-free.

then it's just a matter of setting a good API for message passing and futures... not easy, but at least it doesn't seem like changing the language itself.

Answer 4

What I can do in one Turing complete language I can do in any other Turing complete language.

So I interpret your question to read, is it as easy to write a reliable and scalable application in C++ as it is in Erlang?

The answer to that is highly subjective. For me it is easier to write it in C++ for the following reasons:

• I have already done it in C++ (at least three times).
• I don't know Erlang.
• I have read a great deal about Stackless Python, which feels to me like a highly concurrent message based cooperative multitasking system in python, but of course python is written on top of C.

Having said that. If you already know both languages, and you have the problem well defined, you can then make the best choice based on all the information you have at hand.

Answer 5

Yes, it is possible, but...

Probably the best answer for this question is given by Robert Virding’s First Rule:

“Any sufficiently complicated concurrent program in another language contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang.”

Very good rule is use the right tool for the task. Erlang excels in concurrency and reliability. C/C++ was not designed with these properties in mind.

If you don't want to throw away your C/C++ knowledge and experience and your project allows this kind of division, good approach is to create a mixed solution. Write concurrent, communication and error handling code in Erlang, then add C/C++ parts, which will do CPU and IO bound stuff.

Answer 6

You clearly can - the Erlang/OTP system is largely written in C (and Erlang). The question is 'why would you want to?'

In 'ye olde days' people used to write their own operating system - but why would you want to?

If you elect to use an operating system your unwritten software has certain properties - it can persist to hard disk, it can speak to a network, it can draw on screens, it can run from the command line, it can be invoked in batch mode, etc, etc...

The Erlang/OTP system is 1.5M lines of code which has been demonstrated to give 99.9999999% uptime in large systems (the UK phone system) - that's 31ms downtime a year.

With Erlang/OTP your unwritten software has high reliability, it can hot-swap itself, your unwritten application can failover when a physical computer dies.

Why would you want to rewrite that functionality?