Well, nobody sane then if I'm allowed the Scotsman! People also defend all kinds of dangerous constructs or practices blaming other programmers for not being good enough to use them even though statistically even the best programmers suffer from problems derived from them (e.g. buffer overflows, or in the case of threads race conditions, starvation, etc.).

And since we're particularly talking about adding threads to Javascript, here's the opinion of the creator of Javascript itself on threads:

  You must be this tall to hack on threaded systems, and that 
  means most programmers should run away crying. But they 
  don’t. Instead, as with most other sharp tools, the 
  temptation is to show how big one is by picking up the 
  nearest ST code and jamming it into a MT embedding, or 
  tempting race-condition fate otherwise. Occasionally the 
  results are infamous, but too often, with only virtual 
  fingers and limbs lost, no one learns.

  Threads violate abstractions six ways to Sunday. Mainly by 
  creating race conditions, deadlock hazards, and pessimistic 
  locking overhead. And still they don’t scale up to handle 
  the megacore teraflop future.

  https://brendaneich.com/2007/02/threads-suck/

Also, are you the author of TFA? That sure speaks to your skills, but that doesn't mean standard definitions (e.g. on concurrency) or traditional consensus (e.g. on threads being messy) don't apply.

Appealing to authority isn't a valid argument.

Brendan and I have had many discussions about the nature of threading in JS.

The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers.

If you read the article you'll see that there isn't any way to mismatch lock/unlock.

The other massive footgun is the for whatever reason people insist on creating standard libraries that are not thread safe (collections, apparently bigint in java?). JS is never going to have completely undefined behavior, but non-determinism already exists.

Is concurrent code easier to screw up than single thread? yes. Is that cost enough to discount the possibility of ever having threads? I don't know. The article goes one way, you clearly go the other.

>Appealing to authority isn't a valid argument.

Calling out "argument from authority" when someone posted actual arguments an authority made is even less valid.

>The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers.

Perhaps, but this is an orthogonal concern as to the issues with threads themselves (not to mention with an environment that has since forever assumed a single thread of execution).

I think that someone taught you the wrong definition of concurrency. I’m just trying to help you learn the right one.