epage

That guideline is in response to an API design. I'm speaking to how the default stance (import types) feeds back into API design.

> Type names should be imported and used unqualified

This just pushes people to have redundant information in types (`IoError` instead of `io::Error`).

Unless a type is widely recognized (like `HashMap`), I prefer to have them fully qualified so I have the contextual meaning for it. If I am working with a generic name like `Source`, what does that mean? I shouldn't have to look up in the imports to understand the code (or only understand it through an LSP).

Reducing imports also reduces unnecessary merge conflicts.

I think which to use in general Rust code depends on the purpose of your type.

A builder type like `Command` will have unqualified setters and `get_` qualified getters.

For record-like-structs, I think unqualified getters becomes preferred and `set_` qualified setters.

This will be the default for the `dev` profile in an upcoming release now that the `debug` profile has been split out.

Been looking at sandboxing, both low level and higher level like this.

The API for their Rust mxc-sdk looks nice but

- their "sdk" has binaries and the build script has logic for them

- their build scripts do windows-exclusive work on all platforms

- not putting some of the backends behind features causes more build script work (and that work will break on future Cargo versions)

- at least some of the remaíning build script work doesn't need to be a build script

- it seems pretty dependency heavy

Why not just pass `-jobs 1` to cargo?

Still won't be quite apples to apples because a multi-crate project will serialize more to disk.

Most of these global env vars started somewhere.

That said, at least for cargo, there will also be a `term` config field for it.

We are trading away disk space for faster builds. We could make them faster in some cases by using even more...

On the other hand, it would be good to garbage collect those caches. We are wrapping up work on a new layout for intermediate build artifacts that will make it easier to GC them.

As a reviewer, I love type first because it sets expectations for what I'm going to look at. Similar if I'm bisecting or doing other history operations.

I don't do automated changelogs or versioning but it also makes it faster for me to do so.

I really dislike focusing on issue ids. I only want to jump to another tool if I need more information, so put it in the footer for after I've read what is there, like a front page news article giving you the option to go to the back to read more. Worst case that I've seen is people that think the Issue ID is all you need.

Not having used uv but being on the Cargo team for Rust, I wish `cargo update` was `cargo lock update` because it is making our life more difficult to add a version requirement update command/mode inside of Cargo. The effort has been stalled for years.

- Our compatibility guarantees mean we can't fundamentally change `cargo update`

- Using the third-party package name of `cargo upgrade` would be confusing in the distinction between the two

- We have to be very careful adding the mode to the existing command

An important part to me that gets overlooked is shared logins. Rust runs the tests of all known Rust projects in a tool called `crater`. I was analyzing a run identifying projects relying on internals of Cargo and opening issues. When making 200 issues by hand, it is a big help when the process is low friction: I had credentials for the site and allowing blank templates. Any time I came across a self-hosted instance, I usually ended up giving up.