[ttfkam]

> The fact JS has very limited interaction between threads makes a JIT much easier to write.

And easier for developers to write and reason about. This is not small thing. Re-entrant code by default (and basically by mandate) eliminated deadlocks in even a beginner's code. Do you understand how amazing a language is than encourages concurrency and allows parallelism with any fear of deadlocks or explicit atomism?

[aardvark179]

You can absolutely have concurrency bugs in async JavaScript code, don’t kid yourself that you can’t, or even that it’s hard to do.

The reason I mentioned the concurrency model making the JIT easier is that the concurrency model makes it easier to manage the replacement of methods on the stack when an assumption has been invalidated, and this helps with the speed of the compiled code. The same also applied to various languages with green threads or global locks, but outside the JS world being able to use multiple cores has proved more useful than the difference in single threaded code.

[ttfkam]

Never said you couldn't have concurrency bugs.

I specifically mentioned thread deadlocks and atomism. You cannot claim locks, so you cannot claim them out of order. JavaScript has no notion of "atomic integer increment" since all variable access is atomic/single threaded.

That is not the same as the straw man claim you asserted for me.

And I reiterate: no deadlocks or atomism concerns greatly aids developers in writing secure and robust code. It does not eliminate all bugs, concurrent or otherwise, nor did I ever claim it did.

If you can find a code example in browser-based JS that triggers a deadlock, I'd be fascinated to learn about it.