That and the existing reply are incorrect. Almost everyone has repeated the same superficial requests and design work and not dug into the problems to come up with a proposal that respectfully threads seemingly contradictory requirements (the answer isn't to be dismissive but to step through costs/benefits and explain why a path is justified).
Something to keep in mind is https://blog.m-ou.se/rust-is-not-a-company/. Rust is mostly driven by volunteers working on what they find interesting. Boring/uninteresting tasks depend on funding, a warm body to accept the funding, and a reviewer.
As a prolific PR author, I've found how I communicate has a major factor on how well and quickly people respond to PRs. I've recorded my lessons at https://epage.github.io/dev/pr-style/.
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.
I appreciate you recognize there is still a reason for grouping commits into mergeable units (PRs). Some go too far and only want every commit to be independent.
I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed.
I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis.
There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.
Yeah, having `cargo test` require another binary like `uv` is not idiomatic. 99% of the time, I should be able to walk up to a Rust project and run `cargo test` and it should just work.
Really interested in this for cargo/rustc. We run into issues where we need one or two more colors but all that is left after going for the basic semantic colors is magenta (odd choice), and black and white (not safe without inspecting the theme).
For me the issue isn't performance but bad hook updating logic. They expect hooks to be managed in isolated repos with exclusive use of tags. I have my gh action and hook in the repo of my program and it has been a source of pain to users but I'd rather drop pre-commit support than have to deal with update across repos. prek fixed this.
- splitting up a package into smaller compilation units to speed up builds as llvm doesn't like large compilation units, e.g. I'm assuming this is why uv is split up
- splitting semver concerns (easiest if different parts of the api are versioned independently), e.g. one hope for splitting out `serde_core` is to allow breaking changes of `serde_derive`
- splitting out optional parts to improve build time (`features` can also be used but usability isn't as great), e.g. `clap` (cli parser) and `clap_complete` (completion support)
- less commonly run tests or benches that have expensive dependencies, e.g. `toml` splits out a benchmark package for comparing performance of `toml`, `toml_edit`, an old version of `toml`, and `serde_json`
- proc-macros generally have a regular library they generate code against
- lower development overhead to develop them together, e.g. anstyle has a lot of related packages and I wouldn't be wanting to maintain a repo per package
Something this doesn't mention is that Cargo workspaces allow for sharing parts of the manifest through "workspace inheritance", including package metadata like the repo, dependency version requirements, lint configuration, or compilation profiles.
> In fact, a code fence need not consist of exactly three backticks or tildes. Any number of backticks or tildes is allowed, as long as that number is at least three
Unfortunately, some markdown implementations don't handle this well. We were looking at using code-fence like syntax in Rust and we were worried about people knowing how to embed it in markdown code fences but bad implementations was the ultimate deal breaker. We switched to `---` instead, making basic cases look like yaml stream separators which are used for frontmatter.
> Use hand-written parser
>
> The old parser was written with winnow which is a parser combinator library.
While it’s easy to create a parser with parser combinators, it’s generally slower than a hand-written parser,
so the first step is to write the parser by hands. Hand-written parser is not only faster but also allows to do more optimizations in the future.
Maintainer of Winnow here. I wish there were more details on this. I switched `toml` / `toml_edit` to being hand written and got some performance boost but I feel like the other things listed would have dwarfed the gains that I got. I wonder if there were sub optimal patterns they employeed that we could find ways to help better guide people.
For anyone going on about "hand written is always better", I disagree. Parser combinators offer a great way to map things back to grammar definitions which makes them much easier to maintainer. Only in extreme circumstances of features and/or performance does it seem worth going hand-written to me.
- completions being aware of previous options, flags, and values
A lot of completions have the first. Some have the second. The last is rare. The completer needs knowledge of when flags, options, and value can be repeated and change which future options and values are suggested.
As I'm not familiar with the npm ecosystem so maybe I'm misunderstanding this but it sounds like they removed support for local publishes (via a token) in favor of CI publishing using Trusted Publishing.
If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing.
It reads naturally but I can see people getting tripped up writing this. Worse for changing existing code. Refactor in a way that removes a body? Likely forget to add a breake
> > Struct variant fields are public, limiting how you evolve the fields and types
> But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it?
Likely you should use private fields with public accessors so you can evolve it.
- Struct variant fields are public, limiting how you evolve the fields and types
- Struct variants need non_exhaustive
- It shows using `from` on an error. What happens if you want to include more context? Or change your impl which can change the source error type
None of this is syntactically unique to errors. This becomes people's first thought of what to do and libraries like thiserror make it easy and showcase it in their docs.
I think we should provide the building blocks (display, etc like derive_more) rather than a specialized version one for errors (thiserror).
I also feel thiserror encourages a public error enum which to me is an anti-pattern as they are usually tied to your implementation and hard to add context, especially if you have a variants for other error types.
https://internals.rust-lang.org/t/survey-of-organizational-o... is a start in just collecting existing knowledge in one place.