You're seriously proposing writing string manipulation code in C and plugging that into Erlang? And then telling other people (after quite well reasoned answers obviously based on actual experience) that they don't know what they're doing?

Have a downvote.

There are plenty of good solutions for concurrency. Erlang is one of them. Other message passing actor model solutions are another. Clojure would be another. Using Java's excellent concurrency libraries would be another. Go is reputedly another, although I haven't used it. There is no magic bullet, but there are plenty of good tools of different types.

I'm not convinced the Actor model is a concurrency silver bullet. I'm using it in Scala, and you still have race conditions and potential deadlocks to worry about.

It helps to 'segregate' your application so it's easier to reason about what data could be a race sometimes, but for me it just made multithreaded applications a little less hard, not easy.

The way I like to put it is that it takes concurrency from an exponential problem that no human can actually solve, to a polynomial one. It isn't a magic bullet, because nothing can truly fully abstract away concurrency, but at least it's in the class of sane answers.

This is grounded in the arguments about how many paths through your program there are; with conventional threading, it's exponential since at any time any thread may reach out and twiddle with something another thread has. Things that isolate threads confine interactions to just their communication points, which is more polynomial than exponential. You can still get yourself in trouble, but at least you don't start out in trouble.

A secret of rock solid concurrency is communication, but there are many sane concurrency models. Consider people are already fast efficient safe sane code over hundreds of cores on GPU's which looks nothing like Erlang. Still, when you actually start to care that your concurrent code is accurate not just FAST you need to validate your calculations and Erlang does little to help you there. So sure it's better than C, but turn up the memory errors and it still falls down hard.

It makes perfect sense not to use Erlang because of its string manipulation caoabilities if you're used to working with strings.

The programming languages we use and the problems we solve with them will influence the way we think about building applications in major ways. In many day-to-day operations, you won't feel the need of powerful string handling. Then at some point you find yourself handling unicode and you find out that the support for unicode is only partial, weirdly documented and somewhat confusing. Then you wish, for that string-heavy problem, that you had a language that handled them better.

Of course you can get Erlang to communicate with other languages, but it's not the same; it's more tedious, comes with its own share of problem.

Erlang is only one of the many available concurrency models: Actors, CSP, Join calculus, models based off pi-calculus, etc. Erlang's model has grown from pragmaticism, but is far from the only good option out there.

Deploying Erlang isn't especially hard (hopefully less than before after re-documenting a few features like releases and relups), although live code upgrades of releases is way too complex for the common project without some solid OTP experience.

Every suffiently large Erlang applications include parts written in C. In our case we do JSON parsing in C, we use ZeroMQ, etc.

When you need save memory and/or CPU when processing strings, you can use binaries, IO-lists and in some cases even atoms. The default string representation as linked-lists is good for 50% of applications, but you shouldn't use it when memory consumption or performance is matter.