This isn't an "app." It's one service that's a small but important piece of a rather large backend. It's essentially a content-aware WebSockets proxy. I want it to be extremely light weight with minimal latency addition (less than 1 msec, ideally).

So why C/C++? When it comes to language choice I have a very simple rule: use whatever I think I can be most successful with.

Go prescribes a particular concurrency model. C and C++ do not. I have many years of experience wielding C to write very small, very fast programs that do very big things. I have zero years of experience with Go. Go would be interesting if I was writing something more general purpose or something that needed lots of extensibility, or something on which I plan to collaborate with people who don't have a lot of concurrent programming experience. None of those cases apply.

app, application, I wasn't thinking about mobile apps or the like.

I agree completely with using whatever I can be most successful with line of thinking. This is why I try to learn as many languages as I can, so I have a good notion of what is the best tool for the job.

Whenever I think "loads of concurrency" I immidietly think about Erlang, Clojure or Go, as they have great concurrency models. Then again, you'll always be more productive in the language in which you have most experience, so to each his own I guess :)

C++ doesn't rely on locks. You can use whatever you want.

Hmm. Most of what I've seen uses mutexes and semaphores for synchronization. Do you have actors and/or channels libraries for C++? I recon you do, but how good are they?

I don't know much about the public actors or channels libraries for C++, since I work on a project that rolled its own green threads system and doesn't have much of a use for channels -- we end up having types that perform fifo enforcement in other ways, and our way of "sending a message" is often popping a green thread that switches itself to the appropriate POSIX thread before doing something, using some sort of fifo enforcement object to rearrange things in the right order at the right time (and then holding a short term userland single-threaded lock -- with no cross-posix-thread synchronization -- to do some atomic business once you get your turn).

You could create a channel library that is "as good as" other libraries you'd see, except that they'd use C++ constructors/destructors and you might want a family of channel types depending on ownership semantics -- such as a single-producer single-consumer channel, versus a (less performant) channel with more shared ownership.

The state of existing actors or channels libraries is probably dismal. A channels library would need to be rolled together with a specific green threads system, and that's one of the advantages Go or other languages with a canonical green threads implementation has.