Debugging async multithreaded apps is so much fun that I have a pile of hair on my desk that's been pulled out in frustration.

Considering making a wig to wear after I'm done.

"Why wait when you can ASYNC ":D

Heard this somewhere long back. Coming back to me now while learning node.

Node: The most passive aggressive language I've had the displeasure of programming in.

Reference an undefined variable in a module? Prepare to waste your time hunting for it, because the runtime won't tell you about it until you reference a property or method on the quietly undefined module object.

Think you know how promises work? As a hiring manager, I've found that less than 5% of otherwise well-experienced devs are out of the Dunning Kruger danger zone.

Async causes edge cases and extra dev effort that add to the effort required to make a quality product.

Got a bug in one of your modules? Prepare yourself for some downtime because a single misplaced parentheses can take out the entire Node process, killing unrelated pages and even static file hosting.

All this makes for a programming experience that demands much higher cognitive load, creates more categories of bugs, and leads to code bloat/smell much more quickly than other commonly substituted languages.

From a business perspective, the money you save on scaling (assuming your app is more compute efficient under Node) is wasted on salaries and opportunity costs stemming from longer dev time, more QA, and more frequent outages.

IMO, Node is an awesome experiment, a fun language, a great tool for specific use cases, and a terrible fucking choice for an entire website.

New day. New legacy project that needs triage.

The project has existed since before 2000 so it all "works" and has no known business logic bugs. It does however have performance issues which sure I can have a look. It can actually be quite fun and rewarding to optimize performance.

This is a titanic dotnet framework leviathan consisting of over 12,000 cs files using razorpages, entity framework, and... nhibernate? I have my gripes with both EF and NH but they are both fine if used correctly, like any other tool. I've never seen them used together however.

As It Turns Out™, NH was implemented first and at a time when NH did not support async operations. It made sense if you look it up and it's meant to delegate commands via a separate layer, but different story.

Then for... reasons... EF came in and gradually took over.

Because of the way this is all set up, everything will faceplant if you try doing anything async, even if it has nothing to do with calling the db. Any attempt in making this work leads you down a slippery slope of having to rewrite the entire thing, which is out of the question in terms of their budget and expectations.

Sometimes it's a detriment when it works in spite of its issues.

Started learning python async with curio and trio just two days ago, and I must say I'm really having a blast.
I have a few pending ideas to combine it with websockets (also first time I'm learning how to use them).
Haven't had this much fun with python in a while!

Also, sidequestion: how can return a value from an async function with curio or trio? I can't find a proper answer or example about that, other than some hints about memory channels in trio

One other thing I hate about the popularity of async comm in corps.
After reading so much async comm. I have no energy to read for fun on the weekend o.o