The only interesting challenge is non-trivially parallelizable multicore applications that need to share memory across threads. And the only choice you need to

The only interesting challenge is non-trivially parallelizable multicore applications that need to share memory across threads. And the only choice you need to make is arrays of 64 byte structures C OR Java. In other words do you need to be able to sleep after a day of launching new feaures? The way I tend to do these things is to prototype with Java and once the concept/protocol is finalized and fossilized; rewrite it in C atleast on the client. Java is the best language for server platforms, with classloader hot-deployment for sub second global turnaround and no crashes VM+GC. About services being infinitely accessible: companies that have non-trivial solutions are now moving away from this with queues. Limit the number of concurrent users and when saturated customers have to wait. Open-source/source-available is the best way to scale though. If people are prepared to pay, others will run you service. You need to allow others to make money though. I recommend revenue scaled monthly licence fees recurring on something like gumroad. Finally I'm pretty sure the new 4nm chips will proove to be more fragile than the 14nm stack, only alot of 100% CPU time will tell.