Why is that? It's not perfect, but we have a number of vital systems programming facilities available.
For instance, we can (through mdb, the debugger, and the mdb_v8 module) inspect all of the Javascript (and native) state in a core file -- all of the Javascript objects, the current stack trace with arguments for each frame, etc. That core file can be taken at our discretion via gcore(1) without terminating the process, or in response to an abort(3C) or unhandled Javascript exception.
We also have excellent support for dynamic instrumentation, via DTrace and USDT. DTrace has essentially zero overhead for disabled probes and doesn't require rebuilding, reconfiguring, or even restarting the process in question to start collecting data. We've added DTrace probes to "bunyan", our logging framework, so that we can get TRACE level logs as probe firings without needing them to be enabled all the time. We've also added probes to "restify", the HTTP server upon which we build most of our REST services, so that we can track the invocation of particular routes and handlers.
Both of these facilities are vital for chasing down and fixing bugs in production systems, without which many issues would be much harder -- or even impossible! -- to solve. This is especially for the not insignificant class of bugs that _only_ show up in production and are _not_ reproducible. Or the class of bugs that we have hit at most once in a week, a month, a year, or (practically) ever.
I'm always on the look out for new languages and platforms that provide these features, but in the mean time we do some pretty solid systems programming work with Javascript.
I'm not disputing that good tools are possible in any language, nor am I disputing good tools don't exist which were written in JavaScript.
But so far I have not seen enough benefits to outweigh the risks.
And to me, JavaScript has too many risks. The language has way too many gotchas and it is extremely easy to write a system utility that isn't rock solid.
And I very much dislike using system utilities if they are not rock solid.
Personally, I don't like the JavaScript community. Call me old and grumpy, but what I see is mostly inexperienced people building framework after framework, tool after tool, building layers upon layers upon layers of cruft without a minute of consideration whether it's needed at all (or worth the electricity it uses up). It's like the polar opposite of systems programming.
For instance, we can (through mdb, the debugger, and the mdb_v8 module) inspect all of the Javascript (and native) state in a core file -- all of the Javascript objects, the current stack trace with arguments for each frame, etc. That core file can be taken at our discretion via gcore(1) without terminating the process, or in response to an abort(3C) or unhandled Javascript exception.
We also have excellent support for dynamic instrumentation, via DTrace and USDT. DTrace has essentially zero overhead for disabled probes and doesn't require rebuilding, reconfiguring, or even restarting the process in question to start collecting data. We've added DTrace probes to "bunyan", our logging framework, so that we can get TRACE level logs as probe firings without needing them to be enabled all the time. We've also added probes to "restify", the HTTP server upon which we build most of our REST services, so that we can track the invocation of particular routes and handlers.
Both of these facilities are vital for chasing down and fixing bugs in production systems, without which many issues would be much harder -- or even impossible! -- to solve. This is especially for the not insignificant class of bugs that _only_ show up in production and are _not_ reproducible. Or the class of bugs that we have hit at most once in a week, a month, a year, or (practically) ever.
I'm always on the look out for new languages and platforms that provide these features, but in the mean time we do some pretty solid systems programming work with Javascript.