The progressive C++ification of JS is scary and exciting in equal measure.

It's been a long time since I was there, but I thought there were plenty of 15,000 call site refactorings done in a single final CL. Not that the Linux kernel should do the same!

When I was there (several years ago) it was rare to do that across many projects. You don't want to have to roll back everyone due to a problem that affects one project. Also, there's a risk that changes that are happening in the meantime might mean the patch doesn't apply.

For a global change? These days that 'risk' is more of a certainty.

It may take a lot of time to get all the approvals from all the code owners. One of the big advantages of a tool like Rosie is precisely that it splits up the update into smaller CLs and has automation that nags all necessary reviewers and reruns the transformation once head moves.

I don't know why you're getting downvoted. This seems like exactly the right move.

Yeah, that little bit made my jaw drop. Package manifests in a format the language doesn't have stdlib support for is insane.

Hmm. How does cargo handle this? TOML is not in the rust stdlib either.

I’m guessing the cargo binary has a TOML parser in it. As long as cargo itself doesn’t need TOML support to build that should be fine.

cargo itself does need TOML support to build because cargo itself is a Rust crate [0].

But it's not a problem because you build a new version of cargo with an older version of cargo that of course can parse TOML.

[0] https://github.com/rust-lang/cargo/blob/master/Cargo.toml

No shenanigans for any library-ish code with few dependencies that targets relatively modern Python.

I've had one or two fundamental version conflicts with a 5+ year old application with 100+ dependencies and a decent amount of legacy stuff. They were a pain in the ass, and the sdispater's stance on not allowing overrides is a pain in the ass. We ended up forking the upstream libraries to resolve the version conflict.

With all of that, poetry is amazing and a huge step forward. I'd advocate it wholeheartedly.

For those who are into this kind of thing, here's a 25 minute mini-documentary of the US electrical system's history and problems. It's more focused on wiring, but has a lot to say on plugs: https://youtu.be/K_q-xnYRugQ

There is a more recent video from the same person (Technology Connections) that concentrates on plugs - specifically, why US plugs have holes in them: https://www.youtube.com/watch?v=udNXMAflbU8

I think the GitHub GraphQL API docs are particularly badly organized and basically show the API as a bucket of stuff, rather than as CRUD entities (which is how it's actually organized). I don't think this a GraphQL issue.

FTA, though the misspellings are frustrating:

In a GraphQL API, tools such as Dataloader allow you to batch and cache database calls. But in some cases, even this [isn't] enough and the only solution is to block queries by calculating a maximum execution cost or query [depth]. And any of these solutions will depend on the library you’re using.

> Hoffman, Ward, Feltovich, et al. 2013

For those who wondered: Accelerated Expertise: Training for High Proficiency in a Complex World

https://www.goodreads.com/book/show/17399473-accelerated-exp...