1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is.

At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular:

if two tasks try to access a variable concurrently it gets marked atomic and they contend for access.

...

I agree that atomic variables won't solve everything, but working on a solution for the synchronisation problem is my next goal.

Adding threads to Javascript without a "solution for the synchronisation problem" would be like adding integers to Javascript without a "solution for the addition problem". It's so fundamental to the nature of the problem that there's basically no point even discussing whether multithreading is worth adding without a specific solution in mind, no matter how badly we might want it.

Plus, making all variables atomic is the sort of thing that's likely to make a multithreaded program perform worse than its singlethreaded counterpart, which makes it even more important to actually test performance on more realistic programs and see if you're gaining anything or not.

It's also not clear to me whether you're trying to keep threads hidden from the node.js programmer or if you plan on exposing them at some point, effectively making a new dialect of Javascript for multithreaded programming. Both options are potentially interesting, but it sounds like you haven't even decided which one you're aiming for yet.

So at the moment, you're asking programmers to consider switching from a singlethreaded environment to a brand new multithreaded environment that has no solution for the synchronisation problem and no evidence it improves real-world performance, and seemingly no plan for resolving those issues.

That's probably why people aren't taken you seriously.

2) The simplicity and robustness of the single event loop is a huge advantage.

Javascript programmers know that the Javascript language is "safe" from race conditions and other extremely insidious bugs that plague all genuinely multithreaded programming. The fact that they need strong arguments to convince them to give up that safety does not make them closed-minded, it makes them responsible.

Unless you can somehow retain that safety, anyone who might want to switch to a multithreaded node.js would probably be better off switching to a language like Go that's designed from the ground up for multithreaded applications.

3) Javascript already supports "background threads" (WebWorkers) and asynchronous programming without directly exposing thread management to the programmer.

Those features already solve a lot of the common use cases that affect Javascript programmers in the real world, without giving up the safety of the single event loop.

Do you have any specific use cases in mind that these features don't solve, and that Javascript programmers want a solution for? If so, it'd be a good idea to present your multithreaded node.js in the context of that specific use case.

P.S. What would convince me to try switching to a multithreaded node.js implementation?

Write a non-trivial program in Javascript/node.js that you think would benefit from genuine multithreading. Do performance tests on this sample program in normal node and your multithreaded node. Show me that your version improves runtime performance, responsiveness and usage of multiple cores to a significant degree, without introducing any bugs or instability.

Once you've done that, I think you'll see people much more interested in this idea.