Okay, story time.

Back during 2016, I decided to do a little experiment to test the viability of multithreading in a JavaScript server stack, and I'm not talking about the Node.js way of queuing I/O on background threads, or about WebWorkers that box and convert your arguments to JSON and back during a simple call across two JS contexts.

I'm talking about JavaScript code running concurrently on all cores. I'm talking about replacing the god-awful single-threaded event loop of ECMAScript – the biggest bottleneck in software history – with an honest-to-god, lock-free thread-pool scheduler that executes JS code in parallel, on all cores.

I'm talking about concurrent access to shared mutable state – a big, rightfully-hated mess when done badly – in JavaScript.

This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.

Every time I showed my work to a JavaScript developer, I'd get negative feedback. Like, unjustified hatred and immediate denial, or outright rejection of the entire concept. Some were even adamantly trying to discourage me from this project.

So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.

You can see the responses for yourself here: https://goo.gl/poHKpK

Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "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."

While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:

http://nexusjs.com/architecture/

But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.

Because the bottom-line of that entire response is an argument: an argument against change.

The average JavaScript developer doesn't want a multithreaded server platform for JavaScript because it means a change of the status quo.

And this is exactly why I started this project. I wanted a highly performant JavaScript platform for servers that's more suitable for real-time applications like transcoding, video streaming, and machine learning.

Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.

No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.

Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.

Like, how about we talk performance?

How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?

How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?

How about utilising logical CPUs to the fullest extent, and allowing them to execute JavaScript? Something that isn't even possible with the current model implemented by Node?

Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.

That's the point of cooperative multithreading. It is a way to smartly work around these issues.

If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.

If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.

If you only read and never modify globals, no contention will ever occur.

Are you seeing the same trend I'm seeing?

Good JavaScript programming practices miraculously coincide with the best practices of thread-safety.

When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?

"To multithread, you need a pair."

I have a 30 minute drive each way to work. This is an opportunity to relax and listen to my wife. Sometimes she isn't available and I just drive quiet. No radio. This helps me be more aware I think.

These drives have allowed me to notice how drivers seems to be getting worse. My biggest peeve being the tailgaters. It just makes zero sense to do this. My theory is there is a lack of knowledge about physical consequences to mechanical interactions. They don't have the frame of reference to understand the danger they put themselves or others into. Or they don't care. I dunno which. Probably some kind of combination.

Why am I thinking about this today? Because I have identified a new class of dumb driver today. Motorcyclists that tailgate. I had this guy get behind me and was getting a little too close. Then the guy decides to get closer. Plenty of room to pass me for miles. I think he is taking the next exit. I am going about 2 or 3 over speed limit on cruise. So he gets between 1 to 3 motorcycle lengths behind my car.

Normally I would be peeved and lower my cruise speed with the decel button. But one of my biggest fears is hitting a bike. So I have no desire to change my speed at all. The guy already seems a bit daft. I also am a bit comforted that it is a bike tailgating me and not a car or truck. Why? Because at worst this bike would leave a "conversation dent" on the back of my car. Some story to tell people. Not a big threat to my safety.

We go past the exit and he is still behind me. Backs off a bit and isn't tailing so close. But he keeps getting close off and on. I get to my exit and he goes past continuing on his way. Thank you for not going the same way I was going today, stupid dumb fuck.

Motorcyclists like to complain we don't see them. We do, and a lot of them drive like shit. Doing unexpected things like this. We see you bro.

Then I see this video today:
https://reddit.com/r/WTF/...

You can judge the driver all you want. I can see both sides of this altercation claiming to be in the right. However, the motorcyclist did one thing that is stupid. He chose to pick a fight he couldn't win. This is survival 101. If you are outclassed don't be an aggressor. What is interesting about this is the driver of the van may have thought the cyclist was reaching for a weapon and acted accordingly. It was already a bad situation. Even if the cyclist was completely in the right he chose to make the situation worse, much worse.

The driver of the van was arrested. It will be interesting to see what happens in this case. The comments in the thread are really interesting. The bikers in the group saying the cyclist was being stupid. Bringing a bike to a van fight. My initial reaction was against the van. Having watched the video a few times I see how the van driver could see the biker as a threat.

The bottom line: neither of these drivers were in their right mind while driving. They should have chosen to deescalate the situation and not make it worse.

This kind of stuff reminds me I need to not get all pissed off when driving. I don't want random people thrust into my life. People are nuts and they just gotta be right. They will go to their grave insisting they had the right of way.