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.

Sharing a first look at a prototype Web Components library I am working on for "fun"

TL;DR left side is pivot (grouped) table, right side is declarative code for it (Everything except the custom formatting is done declaratively, but has the option to be imperative as well).

====

TL;DR (Too long, did read):

I'm challenging myself to be creative with the cool new things that browsers offer us. Lani so far has a focus on extreme extensibility, abstraction from dependencies, and optional declarative style.

It's also going to be a micro CSS framework, but that's taking the back-seat.

I wanted to highlight my design here with this table, and the code that is written to produce this result.

First, you can see that the <lani-table> element is reading template, data, and layout information from its child elements. Besides the custom highlighting code (Yellow background in the "Tags" column, and green gradient in the "Score" column), everything can be done without opening even a single script tag.

The <lani-data-source> element is rather special. It's an abstraction of any data source, and you, as a developer can add custom data sources and hook up the handlers to your whim (the element itself uses the "type" attribute to choose a handler. In this case, the handler is "download" which simply sends a fetch request to the server once and downloads the result to memory).

Templates are stored in an html file, not string literals (Which I think really fucks the code) and loaded async, then cached into an object (so that the network tab doesn't get crowded, even if we can count on the HTTP cache). This also has the benefit of allowing me to parse the HTML templates once and then caching the parsed result in memory, so templates are never re-parsed from string no matter how many custom elements are created.

Everything is "compiled" into a single, minified .js file that you include on your page.

I know it's nothing extraordinary, but for something that doesn't need to be compiled, transpiled, packaged, shipped, and kissed goodnight, I think it's a really nice design and I hope to continue work on it and improve it over time

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