explaininjs

Verizon after 60GB is 600kbps on 5G/4G but up to 3Mbps on UWB. Pretty reasonable IMO. It’s AT&T that’s the holdout, 128k regardless of plan, after 60GB.

I did in fact follow the link. I actually went further than you, all the way to the GitHub, where I saw that it was actually just a web app. All TS.

And you can 100% load PWAs offline, which might be slightly more progressive than your idea of a web app, but I hope not overly so.

That’s a web app, it’s on them if they don’t want to offer their services without requiring me to let them out of the web sandbox.

As someone who does a ton of networking/routing at the link layer for a day job, I can definitely see why they’re taking measures to reduce bandwidth hogs - to the extent I might actually prefer to be on a network that has taken measures to reduce hogging vs one that has not.

When it really truly matters, like when I have a business need to download huge items in remote areas, the $10/GB+ justifies itself.

Curious what you want from a jailbreak at this point? It seems all of the old things that were actually helpful have found them into first party software, or at least in the sanctioned third party. (internet tethering, emulators, side loaded apps, etc.)

I should not need to explain to you that the problem is when b itself is internally an (m b’). Or when it is a sum of many types, of varying m-nests.

I can assure you that JS libraries work with Promises just fine.

This is all besides the root topic though, which is that CPS and Monads are isomorphic. Which is true. Promises are a different thing.

We might consider promises “applied monads” or “engineered monads”. Monodic in inspiration and they solve the same core problem, but they aren’t straightjacketed into the ivory tower “laws” in absolutely every edge case (they do satisfy them in the vast majority of cases). Which is good, because it means we never need to write things like “await await await await await foo()”

There is one particular edge case in which they do not satisfy the laws. That happens to make them much more practical in day to day coding than a strict interpretation would be.

Show me a JS library that allows you to swap a non-async call for an async one in a non-async context^ and I’ll eat my hat.

^Without any non-local changes, obviously.

No… I fear you’ve missed the entire point of the matter, which is that async/await requires that you must go all the way up the call stack explicitly “await”ing things when you have introduced an “async” call (or similar wide spread changes to that effect). There’s no special magic utility function you can call you hide it away. That’s the whole point – and a very good thing, this thread argues.

No… that’s the whole point. If you change them to be async, the language forces you to go and rethink what implications that has for the callers. This is a good thing, dumbly sequenced operations are terrible UX. And UX is far more important than whatever it is they call “DX”.

That sounds a lot like async/await. Any errors thrown in an async context bubble to the callsite awaiting it.

Indeed. And breakpoints and stepping across concurrent context actually works in JS, which is nice.