Unfortunately by that metric other electrical heaters tend to 0% efficiency because they are not making use of the virtually unlimited energy outside the buildings.

The 400% metric let's you compare with other heaters, the 100% is kind of useless.

They're not using them as an input, so.. obviously they're not included in the input/output calculation?

In Spanish when a 5 or 6 yr old learns to read, they can read virtually any word correctly, no crazy phonetics, vowels are very distinct, the language has somewhat complex but strict rules. Compared to it, English looks like spaghetti thrown to the wall.

As I understood, it's constant only after some distance, meaning that the force to its very close quarks is still much stronger than the constant force from the rest of the universe.

After reading a bit more I think I got it all backwards. The force increases with distance, up to a constant, but it seems this is only applicable to already bound quarks, so there's no strong force from rest of the universe.

Dehumidify is a nice feature of splits but my understanding is that it's not as efficient as a dedicated dehumidifier.

Depends on what you are comparing to - if a dedicated whole house system, then possibly (depends on ducting and such). Any portable systems are likely to be less efficient when compared on throughput.

The major win for me is that it all just works. The units already have drains and they balance everything as they cool. No separate system to worry about or maintain.

The statements are true. Period. There's no need to imagine a place where all three overlap, they are already true. Specially since the last one is just a possibility.

Around 2012 my 6GB Ram laptop was struggling with Chrome, I switched to FF and got much better experience there. Then with FF Quantum release I adopted it definitely.

That used to happen to me with Slashdot too. I'm so happy that today I didn't even realize HN was down, I think I tried once, it didn't load and went do something else, I assumed it was some local DNS or internet issue.

Sharing code is great, I've moved processing between backend and front-end or even share the same code in both. Makes SSR+SPA possible using the same code. Typescript is a must for me, but I don't need Deno for that. I haven't used beyond scripting but for the time being I don't see a mayor benefit over node or ts-node other than easier/zero project setup.

I think it depends on the language. What you say is true for JS because it's single threaded but .Net has a thread pool, that means that you can have concurrent and even parallel tasks attending different events from your single thread UI.

You cannot use a single UI thread in a parallel way. Its a contradictory statement. Parallel is the opposite of single threaded.

C# does have a thread pool that you can use with async/await with multiple threads but that would be different from a UI thread or its synchronization context.

It's not contradictory, the UI is single threaded but on the dispatched events you can perfectly have long running tasks that can perform parallel work and affefct common memory.

It's also my understanding that if you stick to async/await and don't create your own tasks, the synchronization context will be the one of the UI thread thus never run in parallel. However, this doesn't prevent you from doing so.

Ah I see what you mean. Sure, you can do that if you desire. My point was simply that the system allows you to not do that. It's easy to get concurrency without parallelism. And it's also easy to get parallelism. But yes, In C# you're only guarded by self control and the slightly cumbersome calls it takes to jump threading context. It's not hard to stay in a single context but it's not enforced.

But you can do the same with threads: pin them to a single cpu/scheduler and use a non-preemptive scheduling strategy.

At some point you realize that explicit continuation passing, threads, coroutines and async/await are all the same thing, and the only thing that async/await gives you is a static bound on your suspended stack size (by enforcing suspension of a single activation frame).

async/await reveals to the consumer that at some point it will exit the code realm for some I/O task and that the result will be asynchronous, you like it or not, this is what really happens. Threads approach conceals that fact and wait for the return without you noticing. So, one disadvantage I see, is that you'll need to guess where the time consuming tasks will be done and create threads for them. The most perfomant code will be the one written by who knows better the underlying code.