New devRant cartoon now live on YouYube! Experience the perils of pair programming! https://youtu.be/vjr_9xKUlYA If you enjoy, please share!

Part 1: https://devrant.com/rants/4210605

So let's talk about these tasks we were assigned. Ms Reliable and Mr DDTW's friend who I just realized I haven't named yet were in charge of programming communications. Ms Enabler and Mr DDTW were in charge of creating the vehicle subclasses for the new variants we were instructed to build. Each one had to handle one variant, and we estimated that both of these would be about the same difficulty (Ms Enabler's one turned out to be a little harder).

I like Ms Enabler, and she's a good friend, although she isn't the best at problem solving and her strengths as a dev lie in her work ethic and the sheer amount of theory she knows and can apply. These just so happened to be the exact opposites of my strengths and weaknesses. Within a few days of having assigned the tasks, she came up to me asking for help, and I agreed. Over the following couple of weeks I'd put in quite a lot of hours reviewing the design with her, and we'd often end up pair programming. It was more work for me, but it was enjoyable and overall we were very efficient.

The other two girls in the group were also absolutely fine this sprint. They simply did the work they had to and let us know on time. Outside of some feedback, requests, bugfixes, and mediating disagreements, I didn't have to do anything with their tasks.

A week and half into the sprint and everybody else has their part almost in an MVP state. As Mr DDTW hadn't said or shown anything yet, I asked if he could push his stuff to the repo (he got stuck with this and needed help btw), and what does he have?

A piece of shit "go to this location" algorithm that did not work and was, once again, 150 lines of if statements. This would not have been such a massive deal if THE ENTIRE PREVIOUS SPRINT HAD BEEN DEDICATED TO MAKING THE CODE DO THIS IN A SENSIBLE WAY. Every single thing that this guy had written was already done. EVERY SINGLE THING. A single function call with the coordinates would let the vehicle do what he wrote but in a way THAT ACTUALLY WORKED AND MADE THE TINIEST BIT OF FUCKING SENSE. He had literally given so few shits about this entire goddamn project that he had absolutely zero clue about what we'd even done last sprint.

After letting this man civilly know through our group chat about his failures, giving him pointers on what's wrong and what he can use and telling him that he should fix it by the end of the week, his response?

"I'll try"

That was it. Fuckass was starting to block us now, and this was the first sign of activity he's given since the sprint started. Ms Enabler had finished her work a fucking week ago, and she actually ASKED when she ran into trouble or thought that something could be improved. Mr DDTW? He never asked for shit, any clarification, any help, and I had let everybody know that I'm open. At least the other two who didn't ask for shit ACTUALLY DID SOMETHING. He'd been an useless sack of shit for half a semester in three separate projects and the one time he's been assigned something half important that would impact our grades he does this. I would not stand for it.

I let him know all this, still civil (so no insults) but much less kind, capped with "Stop fooling around. Finish this by the of the week." which probably came off as a threat but his shithead kinda had it coming.

He was actually mad. Dropped a huge faux-apologetic spiel in the chat. Why couldn't I just trust him (his code was garbage and he was constantly late without explanation), his work was almost done (it wasn't and if he'd started he'd understand the scope of what he was assigned), that the problem was that I'm a condescending piece of shit (bruh), and was suddenly very interested in doing work. Literally everybody ignored him. What was funny was seeing the first questions and requests for help after that spiel. I obliged and actually answered what he asked.

The end of the week came and went he'd just uploaded more garbage that didn't work. I had foreseen this and, on top of everything else, had been preparing his section of the work done by myself and properly. Thus came a single commit from me with a working version of the entire module, unblocking the entire team. I cannot imagine the sheer hatred for this man at that moment for the commit message to simply be:

"judgement"

And with that, all I got was a threat to report me to the professor for sabotaging his work. The following day our group got an email from the professor, with no explanation, asking for an almost-immediate video conference. Group chat was a shitshow of panic, as nobody knew what was going on. Least of all Mr DDTW.

Once again, I'm approaching the word limit so to be continued in part 3 (hopefully of 3)

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."

!rant
Visual Studio Live Share is finally available for the general public! I beta tested this, it's great. Check it out:
https://visualstudio.com/services/...

Much better than pushing and pulling with git for pair programming.

It is ok to fail and commit mistakes, that's part of the game, specially for beginner devs. Just avoid failing alone, the most you can!

I mean:

- Ask people to review your code before pushing to the source repository.
- If you are not sure how to do, ask.
- Never work in production environments without supervision. Pair with someone.
- Have a desk mate for rubberducking (https://en.wikipedia.org/wiki/...) and blame it in case you need

!Rant

What are your opinions about Kite?
It's an AI that acts as your very own pair programmer.
Links:
https://youtube.com/watch/...
Or
https://kite.com