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

Continuation from :
https://devrant.io/rants/835693/...

Hi everybody! I am sorry that as a first time poster I am building 2 long stories, but I really like the idea of connecting with other people here!

Well, as I was mentioning before, I got a job in Android development and had a blast with it. Me and the developer clicked and would spend our time discussing PHP, the move to other stacks (I was making him love the idea of Django or Spring Java) games, bands and cool stuff like that. This dude was my hero, his own stack was developed in a similar MVC fashion that he had implemented from scratch before for many projects. It was through him that I learned how to use my own code (rather than frameworks and other libraries) to build what I wanted. I seriously thought that I had it made with a position that respected me and placed me in the lead mobile development position of the company. Then it happened. He had taken 2 weeks of unauthorized leave, which was ok since he was best friends with the owner of the company, those 2 along another asshole started it so they could do whatever they wanted. And I could not make much progress without him being there since there were things that he needed to do, that I was not allowed, for me to continue. When he came back I was quickly rushed to the owner of the company's office to discuss my lack of progress. The lead developer was livid, as if he knew that he had fucked up. He blamed the whole thing on me (literally told the owner that it was my fault before I was summoned) and that we lost 2 weeks of business time because I did not had the initiative to make progress on my own. I felt absolutely horrible, someone that I had trusted and befriended doing something like that, I really felt like shit. I had mad respect and love for this guy. It got heated, I showed the owner the text messages in which I showed him my pleas to led me finish the parts that were needed while he was away. Funny enough, he acted betrayed. After that it was 3 months of barely talking to one another except for work related stuff. He got cold and would barely let me touch the internal code that he was developing. It was painful. The owner kept complaining about progress and demanded that I do a document scanner for the company, which was to be attached to their mobile application. Not only that but it had to be done with OpenCV. Now, CV is great, but it is its own area, it takes a while to be able to develop something nice with it that is efficient and not a shitstorm.
I had two weeks.
Finished in one. After burning my brain and ensuring that the c++ code was not giving issues and the project was steady I turned it in...to their dismay. And I say so because I felt that they gave me such a huge project with the intention of firing me if it was not done. After that it was constant shit from the owner and the lead developer. I was asked then to port the code to the IOS version. I had some knowledge of it already so I started working on it. Progress was fast since the initial idea was already there and I really love working on Apple devices. And when I was 70% done the owner decided to cut me loose. At first he cited things such as lack of funding and him being unable to pay my salary. I was fine with that even though I knew it was not true. So at the time I just nodded and thanked the company for my time there. Before I left, he decided to blame it on me, stating that if they were not producing money that it was perhaps my fault. I lost my shit, and started using my military voice to explain to him how a software company is normally ran. Then I stormed out.
It was known to me, that the lead developer had actually argued against me being laid off. And that he was upset about it, we made amends, but the fact remains that I was laid off because the owner did not think of me as an asset, regardless of how many times I worked alongside the lead developer or how valuable I was actually to the company, their infrastructure did get better while we worked together, so I just assumed that he never actually did any mention of my value.

I lasted 2 months without a job, feeling horribly shitty because my wife had to work harder to ensure our stability whilst I was without any sort of salary. At this time I had already my degree, so all I had to do was look better. In the meantime I decided to study more about other technologies. I learn React, and got way better at JS and Node that I thought I could and was finally able to get another job as a full stack developer for another company.
I have been here since 2 months. It has been weird, we do classic ASP, which is completely pointless at this time, but meh. At this time though, I just don't really have the same motivation. Its really hard for me to trust the people that I work with and would like to connect with more developers.

With the billions of dollars Google has, they can't even build a proper file manager for their Android operating system.

The pre-installed file manager on Android OS, codenamed "DocumentsUI", is functionally crippled and lacks the most basic functionality.

First of all, there is no range selection or A-to-B selection of items. If many items need to be selected, each item has to be tapped individually. Meanwhile, ES File Manager had A-to-B selection since at least 2012, back when Android OS was an operating system of freedom, before Android OS got cucked.

As any low-tier mobile app, the file manager by Google also lacks a draggable scroll bar, so long lists have to be scrolled through manually. Even the file manager of Windows Mobile 6.5 Professional has a draggable scroll bar! And Windows Mobile 6.5 Professional was released in 2009! Samsung "My Files" had a draggable scroll bar in 2013 but it was later unexplainably removed.

Its search feature can only search the entire storage, not an individual folder, and lacks filters such as date and file type.

Obviously, as in any terrible Android file manager, after items are selected for copying and moving, tapping "Copy to..." or "Move to..." navigates back to the initial directory rather than staying in the current directory. The user is forced to navigate all the way to the folder with the selected files if the intention was moving files to a sub folder. Any Android file manager that does this automatically qualifies as a low-tier file manager.

The file manager by Google even lacks a "details" feature which shows information such as the exact file size and name and the total size and file count of a folder. Some file managers such as the one by MediaTek are unable to show the details for multiple selected items, which is somewhat forgivable, but the Google file manager does not have a "details" feature to begin with.

Files are always sorted alphabetically after each start. The Google file manager does not memorize if the user selects sorting "by size" or "by last modified". As one might expect, it indeed lacks reverse sorting.

Of course, there is no "open with" feature where the application can be selected manually, and there is no ability to create new blank files, and it lacks tabbed browsing, and does not show the number of files inside folders in list view. ES File Manager (before it became adware in ~2016) has all of these features.

Last but not least, there has been a bug where cancelling a file move operation deletes the source folder without it having been transferred. Presumably it has been patched by now, however, a bug where tapping "cancel" leads to data loss is inexcuseable. It shows the app has not even been properly tested, let alone properly created.

http://archive.today/2020.10.27-160...

Google could have hired a college student who could have built something better than the scrapyard-worthy "file manager" they have built.

But granted, at least Google's ever-so-terrible file manager does not limit file names to fifty (50) characters like Samsung's TouchWiz file manager, also known as "My Files", did until at least 2016. There is no way to know what went through the head of the programmer who implemented this pointless limitation. Google's file manager also correctly handles file name conflicts by renaming the new files.

Microsoft built a better file manager for their operating system decades earlier than what Google threw together. Microsoft spent more of their money building a proper file manager.