The only correct answer is to be consistent with the code base you're working in or the language's conventions. If neither of these conventions exist, then someone has already failed you.

Let's not lower the standard anywhere near Trump.

Of all the stuff I've seen in the comments, this is actually feasible today.

This does seem like a potential issue if the PR is itself implementing more than one vertical slice of a feature. Then it could have been smaller and there might be wasted effort.

If the patches are small and well-organized then this isn't necessarily a bad thing. It will take more than one day to review it, but it clearly took much more time to write it.

It's an investment for the next time you install on a new dev machine. After install, I will literally run a single command to return to the exact state of my dev environment.

Is Janel a ghost?

I could see large companies paying to train the LLM on their own IP even just to maintain some level of consistency, but it obviously wouldn't be as valuable as hiring the talent that sets the bar and generates patent-worthy inventions.

"how to write sloppy rust code and squander most of the advantages of the language"

Only half serious. But I think really the only point that I agree with is taking the easy way out with the borrow checker. I mean, at least try to borrow when it's idiomatic, but if you get frustrated, clone (or move) instead.

Error handling when done well is not much harder than unwrapping everything, and you get many advantages. Learn to use thiserror for your library crates and anyhow for executables.

I also agree that you should avoid unsafe 99% of the time. If you think you need it, you probably don't.

Nah these are the actual integer representations. Otherwise you would have Some(None) == Some(Some(None)) which is way too Javascripty for Rust folks.

Do challenging projects. Read code from better engineers. Work with better engineers. Try new languages that actually solve technical problems instead of just having nice syntax. Contribute to open source projects that you use. Actually read the manuals that come with your tools. Notice when it's taking you a long time to do something and reflect on it to find a faster way. Constantly tweak your workflow to be more productive.

And the most important of all:

Get a split ergomech keyboard.

Javascript can be frustrating because it also has some rare features among popular languages, and uses the same keywords for different concepts.

I don't think those are the reasons JS is frustrating.

Don't forget about lsd