"The programmer doesn't need to check JMX occasionally. The behavior is immediately detected in testing and reported as a warning."
Those two sentences are directly contradictory. Either the behavior doesn't happen, or it needs to be checked (via a test suite, or programmatically, or manually). Test suites will go a certain way, but behaviors in production change with new or different data, and the last thing I want to deal with as a developer is trying to remember all the corner cases in my framework when the system is not responsive. Even erlang is difficult; I can't imagine trying to deal with an erlang-like framework with even fewer friendly invariants.
Anyway, it sounds like we inhabit completely different universes, so really there's no point in continuing. Good luck with Quasar. Again, I'm sure it has some great use cases; just not, apparently, common erlang-like ones.
Erlang, AFAIK, doesn't even report runaway processes (that are stuck in native code). Doing all you want is a matter of putting back -- and I'm not exaggerating -- 10 lines of code. Alright, maybe 20. I'm just telling you that it doesn't help. Everything you do in Erlang you can do in Quasar. I can even make you a promise -- if you find that explicitly marking the CPU-bound threads is a burden (and you only have to do that for fibers that are constantly CPU bound -- not bursty ones), I will turn on that feature again, with a big thank-you and a personal mention on our blog. I can assure you that we've spent a long time testing it, and what you imagine to be an issue is not one in practice; not even a slight one (if it were we wouldn't have disabled that code).
Trust me, there are real issues with Quasar, but the one that you fear will bother you isn't one of them.
Comments
"The programmer doesn't need to check JMX occasionally. The behavior is immediately detected in testing and reported as a warning."
Those two sentences are directly contradictory. Either the behavior doesn't happen, or it needs to be checked (via a test suite, or programmatically, or manually). Test suites will go a certain way, but behaviors in production change with new or different data, and the last thing I want to deal with as a developer is trying to remember all the corner cases in my framework when the system is not responsive. Even erlang is difficult; I can't imagine trying to deal with an erlang-like framework with even fewer friendly invariants.
Anyway, it sounds like we inhabit completely different universes, so really there's no point in continuing. Good luck with Quasar. Again, I'm sure it has some great use cases; just not, apparently, common erlang-like ones.
Erlang, AFAIK, doesn't even report runaway processes (that are stuck in native code). Doing all you want is a matter of putting back -- and I'm not exaggerating -- 10 lines of code. Alright, maybe 20. I'm just telling you that it doesn't help. Everything you do in Erlang you can do in Quasar. I can even make you a promise -- if you find that explicitly marking the CPU-bound threads is a burden (and you only have to do that for fibers that are constantly CPU bound -- not bursty ones), I will turn on that feature again, with a big thank-you and a personal mention on our blog. I can assure you that we've spent a long time testing it, and what you imagine to be an issue is not one in practice; not even a slight one (if it were we wouldn't have disabled that code).
Trust me, there are real issues with Quasar, but the one that you fear will bother you isn't one of them.