A note on devRant community etiquette. I've seen some behavior lately that I want to just mention since it goes against the rules of our community. We've specifically built moderation tools into upvoting and downvoting, and that is how all content should be moderated.

Commenting on rants that you don't think should be posted only gives them more exposure and unfortunately at times people trying to moderate content via comments and rants have gotten abusive towards other members. On the contrary, I've yet to see any of the people these select few members accuse of "ruining the community" act hostile towards anyone.

So with that said, I wanted to make sure this policy is visible, because commenting on other people's rants, especially in a hostile way to stop them from posting, is bannable and we really don't want to see it. Like mentioned before, that's what downvoting is for and it's much more effective since it doesn't boost the content like adding a comment does.

We take content quality seriously and while we haven't been able to eliminate reposts completely, we've made a lot of progress. For directly reposted content, we added the repost detector (https://devrant.io/rants/425054/...) and are still working to improve that and appreciate any feedback/ideas for it.

Like any community on the internet, devRant will always have some reposts and it will always have some content you really don't like. That's what comes along with being an open platform with very little moderation. We get requests to moderate more heavily, but we don't like censoring recent rants and don't plan to do that.

Most of the times people who repost content or an image didn't realize it was already posted. Not everyone uses recent sort and almost always they have no ill intent.

Anyway, feel free to let me know if you have any questions and feedback is always welcome.

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

Ok peeps, this is it!

I have completed my contribution to community projects! Wanted to share with you guys...

I was so impressed/inspired with @ChappIO 's www.jsRant.com project that I wanted to create something similar.

So I created an XML stylized stream of rants, in dark theme.

It also reflects how I feel as software developer with my current knowledge - kinda derelict old school!

The underlying tech is Asp.net core 1.1, using my own .net core API wrapper.

So, here it is:
Http://xmlRant.com

Any Stardew Valley fans?
I've made a little something.

https://nitwhiz.xyz/projects/...

I know there are some bugs (such as the Chef's bundle missing completely), going to fix 'em soon.

Guys, if you have an extra computer lying around, support for the cause by contributing your device as a resource to SETI:

https://setiathome.berkeley.edu

If you discover something, the credit goes to you! If you are not happy, you can contribute to various other projects which are in need of your computation. Kindly consider.

Cannot pinpoint one advice as the best but the comments of this rant are the most helpful one's
https://devrant.com/rants/1339948/...

@Floydian @AlexDeLarge @wokeRoach @Devnergy @sharktits @norman70688 Thank you guys for it. I often come back and re-read it.

my first ever public repo on github for @devRant community

devRant bot for Telegram

after being waiting to make some changes in the bot. I finally made it public.

https://github.com/puneetsngh/...

The bot will be fun for devRant community on Telegram plus it will also server as an example for bot creators on telegram app

It’s my “duck” in a box!

https://g.co/kgs/dbFrcE

Would have paid extra for the DevRant devs to sign my duck 😂 @dfox and @trogus.

Thanks for keeping new and exciting things compiling in the community, I think I speak for everyone when I say that we’re lucky and proud to be apart of it!