nonsense1234

Haskell is only close to C in extremely rare cases or when using unsafe features and the FFI.

> Closure and function return function can be used as substitute

So for every list you have an additional allocation for the add function. It obviously continuously to get much worse as more "methods" are inevitably added. That's extremely inefficient for something that's used often and it's not something JavaScript engines can optimize away. The benefit is also extremely negligible since the closed over values are still implicit in the call to add.

JavaScript is also an extremely bad functional language unless you don't mind ridiculous memory bloat and inefficiency. To be even reasonably efficient you're basically forced to use classes because the primary ergonomic alternative is objects that contain functions that close over lexical scope. This is ridiculously inefficient because functions that would normally have a single instance on the prototype chain are now duplicated for every single object. Modern JavaScript engines can't optimize this without breaking the spec which they obviously won't do. You can resort to just using plain functions and objects that contain nothing but data but this quickly becomes quite ugly without a pipeline operator.

The standard library is also filled with mutating methods and doesn't include proper functional data structures and pure JavaScript implementations of functional data structures, such as immutable.js, are so slow that you might as well just use arrays and objects and repeatedly do shallow copies.

Programs that stress functional purity in JavaScript are becoming hard to meaningfully benchmark because instead of having a few hotspots absolutely everything is incredibly inefficient and slow. Death by a thousand cuts.

For a long time D wasn't open source, didn't work very well on Windows, had a very limited standard library, and had poor IDE support. There's also a large divide in the community around garbage collection vs manual memory management.

> We still see a pretty high rate of security vulnerabilities in it.

Prove it. As someone else pointed out, there were 5 CVEs for systemd in 2017 and 7 so far this year most of which are low severity. If you think the mess of shell scripts and programs that systemd replaces had less than that you're simply delusional.