Sean McArthur

I wrote a clippy lint (https://github.com/rust-lang/rust-clippy/pull/17129) to catch structs that are too big, but seems others think it's too strict. I still think it's a good idea.

Structs are free. They don't result in auto boxing. So, divide up your structs by how the fields relate to each other. Then it's much easier to borrow one field than to wish for some complex syntax to borrow many.

I've seen the hype about view types (https://goals.rust-lang.org/2026/view-types-experiment.html) being added to Rust. I worry it exceeds the strangeness budget (https://steveklabnik.com/writing/the-language-strangeness-budget/). And there's a solution already available. Make your structs smaller.

I value LLMs for their ability to understand hyper-specific search queries. But I want to consider how much of the generated text I read; it’s better to read the human source. Or other non-forced exposure (seanmonstar.com/micro/202608...).

The top advice given to anyone wanting to get better at writing, besides just writing, is to _read_ more. Especially good writing. Because we imitate that which we experience more of.

They're a lot like RFCs. With some tweaks from lessons learned. Making maintenance more repeatable, less in one mind. The writing is the thinking. It documents the why. A sustainable personnel of hyper.

When writing, I always start by dumping a detailed outline with points and subpoints. And then, ugh, I feel a wall. How do I turn this into prose? I ask an LLM to try, I look at the ablated text, and I hate it. No, definitely not that rock. More like this.

A trait could allow us to write `5.seconds()`, or `200.milliseconds()`, etc. I think this is much better. I would rather this exist instead. Maybe `std::time::TimeUnits`, or pick a better name, doesn't matter which, just that it's easy to import.

I dislike the pattern in some languages to create durations by multiplying constants. It feels like a concession when it cannot be expressed more nicely. There's a tracking issue (https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/issues/57391) to add such constants in libstd.

I'm torn when I receive LLMed reports. Initially, I really don't want to read all that. But at the same time, my mind nags me; something's broken and I should fix it for everyone. If it makes it easier for someone to report a bug, that's a pro, I guess.

If you choose to communicate with me, all I ask is that you use your own words. Bug reports and issues. Pull request descriptions and especially review comments. This isn't new, but I wanted a link of my own.

View types might help too, like `Ref<'_>`. Returning a reference requires the data already exist in that shape in `self`. You can't change its shape in the accessor and return a reference to _that_.

As a library maintainer, it's common to receive requests from users to add a "simple accessor". The data is _right there_. But that accessor can end up revealing internal representation details that you can no longer change.

Some interesting discussion a few years ago: https://www.reddit.com/r/rust/comments/n12uf9/is_there_a_good_reason_not_to_impl_eqpartialeq/

The common reason to want this is for testing purposes. People want to assert an error case matches what they expect. But that doesn't need equality. `matches!` , `kind()`, or `is_*()` patterns fit better.