[datavirtue]

We have been down this road before. When you have a lot of options "for those times when" you get a lot of abuse. All good frameworks remove choice to prevent a spiraling string of fuckups by people who don't understand what is going on behind their code. For the few of us who do know what is going on it is not a problem but you have to consider all of the code monkeys who are going to be using a given framework without supervision. What would happen if we made everyone program enterprise CRUD applications in C++ from scratch....unmitigated chaos that would lead the business to disavow technology and go back to paper filing cabinets.

[RussianCow]

You call it "abuse", I call it resourcefulness. I get where you're coming from, but as someone who is not very comfortable with lower-level languages like C++ and Rust, it's great to have the option of whipping together a parallel program in a language/platform I know, rather than having to invest in learning a new one. For longer-term projects, that investment is generally worth it, but I don't think it's useful to be dogmatic about "the right tool for the job".

> What would happen if we made everyone program enterprise CRUD applications in C++ from scratch

I don't think that's a good analogy. A better analogy would be if we started writing everything in JS/Ruby/Python instead of using lower-level languages where performance matters. Except, this is regularly done with great success by many, many companies, so I don't think that helps your point. Sure, you may have to eventually port it to a more performant platform when you hit massive scale, but that point may also never come.

[cjalmeida]

Dealing with threads and shared memory properly is way harder than getting acquainted with modern C++ or Java.

Most cases, when you need to parallelize and multiprocess doesn't cut it, you'll likely need to go to the C++ module route anyway.