rtpg

I've always found Rust object buildup to be pretty annoying.

JS solves this problem in two ways in the ecosystem:

- basically saying "all functions must be async" in practice

- allowing you to await a non-awaitable ("await 3" is valid)

so library authors can "force" async/await, but users don't actually have to interact with it when they don't need to. But "everything" being async/await means it's all 'basically fine' anyways

There's also the fact that JS libraries tend to be "pass in a bunch of callbacks" vs, say, Python's "override this class". It makes it much easier for libraries to have everything be async and have it really not get in the way.

Python libs tend to have much larger API surfaces due to how OOP works. So async-y internals works are harder to isolate cleanly without breaking the public API. But if you make your API "async-first" then the debugging experience in Python is miserable (try pdb'ing your way through awaitables....)

Even here though there are problems. For example, I've tried in the past to replace some lib with a more performant WASM-y thing. But it couldn't be a drop in replacement because the original library was a sync-only API, and the replacement was async!

Something very silly: you write "function add(x, y) { return x+y }". A bunch of people do things like "add(add(x, y), z)" everywhere. You find out you could make "add" "better" with async/await. You now have to get all callers to rewrite.

So what everyone does is just throw _everything_ in to the async/await pile. Which... I guess is fine but I personally dislike writing "await add(await add(x,y)), z)".

(aside: Rust's postfix await at least makes this kinda refactor less annoying)

do you have an example in mind when you say this? I think there's some unique messes with async/await (especially when combined with OOP and extension points... either your extension points _all_ have to be async or you have to have awkward restrictions), in a way that, say, permission checks don't have IMO.

a syntax-less "await function" that climbs up the stack trace to whoever is waiting and holds onto the suspension _is_ a way out of the problem the article describes. Requires runtime support but it effectively means you can always suspend.

This stuff works so much better when you just tell it what to do

Ultimately I think React makes it too hard for the performant solution to be used. And then tries to handwave it all away with “the react compiler solves/will solve it”. Don’t even get me started on “useMemo is not semantics” rationalization. First time runs actually matter when working on a performant UI!

DOM ops are expensive but your little bespoke function component code is also expensive when some hook leads to recalcs all over.

are you not in Tokyo? Because “no decent Thai restaurant in Tokyo” is a wild claim

You can get spicy food in Tokyo! It’s just not going to be all the restaurants. You gotta to to the right place. But you don’t need 100 good thai restaurants to eat dinner, you just need the one.

But Tokyo has a loooooooot of good food from various places, and a lot of people with money willing to spend 5 bucks a slice (for example). Or at least enough to sustain one restaurant.

The contrapositive: what magical thing exists in Jersey that would not be exportable to Tokyo?

I would bet that NYC has the best cheap slice tho.

For libraries, having loose bounds might mean that users upgrade and hit issues due to a lack of an upper bound. But given how lightly maintained most projects are, the risk of upper bounds simply getting in the way are higher IMO.

(Put an upper bound if you know of an issue, of course!)

It's a bit tricky though. Django deps in particular tend to want to explicitly check support for newer versions, but the more I think about it the more I ask myself if this is the right strategy

In here it sounds like this is a client to a third party service. Mail.app and Thunderbird don't have buttons to delete my Gmail account

I do agree all of this seems basically like "sure, fine". Just seems rough to get pinged with all of these in a slow stream, and having wall clock time go waaaaaay up for it.