explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

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

explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

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

explaininjs

2 anni fadiscuss

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()”

explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

If you’re fine with manually checking a standard interface to see if you should abort, JS’s answer is the AbortController. This is supported by features like the “fetch” function for making cancellable http requests.

https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

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.

explaininjs

2 anni fadiscuss

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

explaininjs

2 anni fadiscuss

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

explaininjs

2 anni fadiscuss

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

explaininjs

2 anni fadiscuss

Yes. That blog has probably done more to negatively impact the industry than any other written work I know.

explaininjs

2 anni fadiscuss

F# first actually. Then C#. Then Haskell. Then Python. Then TypeScript. Parent just has an axe to grind.

explaininjs

2 anni fadiscuss

Coming from a heavy TS background into a go-forward company, I’d say the main thing you get with async is it makes it incredibly obvious when computation can be performed non-sequentially (async…). For example, It’s very common to see the below in go code:

   a := &blah{}
   rA, err := engine.doSomethingWithA()
   b := &bloop{}
   rB, err := engine.doSomethingWithB()

This might have started out with both the doSomethings being very quick painless procedures. But over time they’ve grown into behemoth network requests and very thing is slow and crappy. No, it’s not exactly hard to spin up a go routine to handle the work concurrently, but it’s not trivial either - and importantly, it’s not immediately obvious that this would be a good idea.

Contrast to TS:

   let a = {blah}
   let [rA, err] = engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] engine.doSomethingWithB()

Now, time passes, you perform that behemoth slowing down of the doSomethings. You are forced by the type system to change this:

   let a = {blah}
   let [rA, err] = await engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] await engine.doSomethingWithB()

It’s now immediately obvious that you might want to run these two procedures concurrently. Obviously you will need to check the engine code, but any programmer worth their salt should at least seek to investigate concurrency when making that change.

I wouldn’t be bringing this up if I hadn’t made 10x+ performance improvements to critical services within a month of starting at a new company in a new language on a service where the handful of experienced go programmers on the team had no idea why their code was taking so long.

explaininjs

2 anni fadiscuss

> You basically have to give up on the idea of ever having any real evidence for one thing over another

Exactly. We agree.

> best explanations we could find

We have no tested explanation of abiogenesis, chiefly. Among many other questions. Lots of theories that say “and throw your hands up and wave them around and wait 8 million years and tada, probably, idk”

God intervening in the universe is a potential source of sudden changes in the laws of physics. For instance changes that allow a man to walk on water or split a sea. Those changes are stepwise, they do not impact space time gradually. Thus non-differentiable. If the change was gradual, evolutionists would come up with a formula for it and say it magically is that way, for “reasons”. They might look at how their laws of gravity work and see that they aren’t right for galaxies, and say the reasons are “dark matter”, for example. I might say they’re God working exerting a differentiable influence, but those two are interchangeable, at least on the surface. It’s only the stepwise that is Godly.

explaininjs

2 anni fadiscuss

That is the belief that leads to evolutionism, not the exact definition of evolutionism. A necessary precondition.

I don’t have time to explain basic mathematics. Suffice to say, the concepts of changing over time and differentiating are very related. If you didn’t know that… that explains a lot I suppose.

I still don’t know what your point is, by the way. Maybe we should settle that.

explaininjs

Submissions

Palmer Luckey: Millennial slayer of U.S. defense giants

Mattel launches new, less 'intimidating' version of Scrabble

comments