Don't panic, impl Things

The Middle Ground

2026-03-08T00:00:00+00:00

Like many, I too have been spending much time thinking about (generative) AI and its values. In my field of work (Software Engineering), on online forums such as Hacker News and in blog posts, generative AI has become an almost polarized topic between the believers and the unbelievers. Of course there's a middle ground, yet as it often is, the outer ends are the most vocal, and usually are most certain of their position. I suspect this divide maps onto something deeper: how people perceive the value of their work. To some, code and software are just tools; means to an end. They're the makers, the pragmatists of our field. On the other end you have the people who do not just care what they're building, but also how it is built. They're craftspeople^{1^{2, perfectionists who care as much about how something is built as what it does.}}

In companies and larger projects, I'm convinced you need both. Craftspeople tend to spend (too) much time on details. Some details matter, but not all. Usually, proceeding forward is necessary both for economical reasons, but also to learn more about the real requirements of the product. That's where makers come in. They are better at making difficult decisions, even with incomplete details. However, they also tend to "just make it work", even if that means using suboptimal solutions and architecture. In turn, future additions can be chaotic and more difficult, and in the longer term, time consuming; it can also mean it'll require more maintenance^{3. Where the balance rests depends on many factors. What do you produce? Are you responsible for maintenance? Do your customers care about what maintenance will cost them, or how much time it will take before a product must be replaced?^4}

When searching for a balance, it's unusual to find easy answers. However, I'm convinced that the answer is almost never at the edges of the spectrum. When in doubt, choose some kind of middle ground. This is why the polarised AI debate frustrates me. On one side, people want to use AI to build as much and as fast as possible; the initial outcomes are all that matter. On the other, people refuse to engage with AI at all and dismiss it outright. Neither extreme leaves room for the conversation that actually matters (if we assume it is here to stay): when does it help, when doesn't it, and how do we work well regardless? The answer is unlikely to be found at either extreme.

^{1 Like almost anything, almost nobody is completely on one side or the other; everything is a spectrum. Yet, no argument can be made if you need to deal with infinite exceptions. Every model is flawed in some way.}

^{2 I also wonder if, and how, any of the color personality models relate to the stance of people with respect to their opinion of generative AI. I would hypothesize that makers (pragmatists) skew red or yellow (i.e. action oriented, results focused, impatient with details), and that craftspeople (perfectionists) skew blue or green (i.e. methodical, quality focused, slower to act).}

^{3 Software projects are rarely ever done. After new features are added, maintenance is required for security updates, to keep internal and external services compatible, and to remove overhead. In that respect, software is not different from hardware, whether it's an aircraft, boat, bike, or a server rack, a graphics card or even shoes. Everything wears down. The type of maintenance changes, but not the need.}

^{4 If you (or a competitor) can write a new version or competing product at a fraction of the cost, it affects the sustainability of software businesses. Generative AI might be exactly this kind of shift and if so, it will affect where the balance rests.}

Notes on AI and empowerment

2026-03-01T00:00:00+00:00

Today, I came across the following post Rust Project Perspectives on use of AI</a>. I realize there are more opinions in this post, but I will only focus on Niko's opinion as it made me think about the different sides of empowerment. ^{NB: I do not intend to pick on Niko's opinion here; there's no ill intent behind this reply. Consider it a post-dinner thought if you will.}
In particular, Niko mentions:

"If I had to pick one word for how I feel about using AI, it is empowered". </blockquote>
And goes on to state:

"Suddenly it feels like I can take on just about any problem -- it's not that the AI will do the work for me. It's that the AI will help me work through it and also tackle some of the drudgery. And certainly there are some areas (github actions, HTML/CSS) that would just stop me cold before, but which now are no issue -- I can build out those things and brings things to life." </blockquote>
And to highlight one more part (you can read the full opinion in the link above):

"This is not to say AI doesn't have problems. It has huge ones, power usage chief among them, but also the way irresponsible usage is creating slop PRs (not to mention the way it's being inserted in places it doesn't belong, and the ways it will be abused by governments)." </blockquote>
The first thing I thought was; arguably especially with all the agentic programming going on, "it's not that the AI will do the work for me" sounds very much like the AI doing the work, or at least, some of the work. Is that good or bad? Hard to judge.
But this is a point which made me think, namely about senders and receivers^{1. That is, senders are the people writing the code and making PR's. The receivers are the people reviewing the code. So far, I feel that AI could be empowering primarily for senders, but is relatively more likely to be disempowering for the receivers (not for all of course).}
Over the last few months I've been less active in open source because emotionally, programming no longer seemed to have much value. Being on the receiving end of AI slop made reviewing code a slog. For much code written by LLM's, it's time consuming to decide whether it is slop or genuine, because LLM's make it hard to see the difference without thorough reviews. It feels, I the reviewer am often the first to go thoroughly through the commits, while I would pose, you should always review your own code before asking for the opinion of a maintainer.
Emotionally, PR's made (largely) by AI feel different. Open source is not just about the product, but also about people. As a maintainer, I always try to make people feel welcome; them spending the time to contribute to a foreign code base, and helping them find their way, brought me a kind of joy. With the advent of LLM's this joy has been diminishing. I no longer know if I'm helping a human, or a computer. Being the receiver feels tiresome; disempowering.
For the past few years, we've also rightfully seen many discussions about the mental health of Rust (and community) maintainers. It makes me wonder what the impact of LLM's have been on the mental health of Rust maintainers, the last few years.
As it often feels like there are two vocal camps in the online circles, one pro and one con, with little room for sincere discussion, I welcome the discussion</a>, and will be reading the other opinions too, for new insights.
^{1 No, not}these</a> senders and receivers.

The Value of Things

2026-03-01T00:00:00+00:00

I've been playing with LLM's over the past few years; probably in part was just a fear of missing out.
I've both used AI via chats, and let LLM's program agentically. My feelings are mixed. One day I will write a more detailed opinion, but hey, with all this hype, there are enough opinions^1.
One thought keeps repeating though;
I reminisce about this lesson from one of my favorite books as a child^2:

"When you can have anything you want by uttering a few words, the goal matters not, only the journey to it." - Christopher Paolini (Eldest, 2005) </blockquote>
^{1Tons of new opinions on AI every day, find them here:}news.ycombinator.com</a>
^{2I reread the book as an adult, when the follow-up novel Murtagh came out. As a child I loved all the side-quests. Now I felt the books could have been a much, much shorter. And ugh, I still hated the amount of fan-service in the last book of the original series.}🧚</a>

How I use Spotify

2026-01-18T00:00:00+00:00

I've been a Spotify subscriber for over 11 years. Over the years I've tried several of the other music apps, but Spotify stuck. It is however not an app without its pain points. On occasion I've been using the venerable Spicetify</a> to fix issues, like when Spotify tried to go above and beyond in promoting podcasts.Spicetify did have its disadvantages however and one is that it broke on almost every Spotify release (the Spicetify author was very fast in fixing Spicetify, but I kept needing to update my extensions too and had no desire to keep that up in the end).
How I use Spotify</h2>
One thing I've been doing since 2014 is to create a "monthly playlist" every month. During the month I add songs I've come to like (or come back to) to this playlist. I listen to this playlist a lot during the current month. When a new month arrives, I create a new playlist, and the cycle continues. This way I can re-listen to songs while they do not become to repetitive. I tend to start disliking songs I've heard too much after that (like the ones I use for my alarm clock haha). These playlists also tend to stay manageable; a playlist has between 100 and 200 songs at the end of the month.
Each monthly playlist is sorted in a yearly folder, e.g. "2026 • Monthly". I've recently added another level and placed the 2014 to 2019 folders in a "201X • Monthly" folder, mostly because having many top level playlists becomes a hassle on mobile.
For some special occasions, or moods I also create playlists, which I put in a folder called "Trove". These playlists are more situational, and I tend to listen to these less.
I have some assorted folders like "Subscribed" for playlists I didn't create myself, Spotify mixes I like, and the yearly "your top songs" list.
Finally, I have three folders for favorites; from "kind of favorite" to "favorite" to "favorite of favorites". All very subjective, and mood dependent, I suppose.
I always, always, use custom sort order where I can. I'm used to the consistent ordering and want nothing else.

The good parts</h2>
Global music library</h3>
Spotify is pretty great in this regard. It has an almost perfect library. Songs are rarely removed, unlike for example film centric platforms. Songs are also usually available worldwide, and not as much fenced by region (afaik), unlike say e-book or audiobook platforms.
Audio quality</h3>
Disclaimer: I'm not an audiophile. I've been streaming Spotify on "Very high" and more recently sometimes on "Lossless" too; I've can't complain about the quality. It's good.
Built-in lyrics</h3>
This is a keeper. When actively listening to music (as opposed to in the background), I like to understand what is being sung. It was gone for some long years. I hope it will stay this time around. I never quite understood why a third party service is necessary for it either. The line synchronization is nice I suppose, but hardly necessary.
When consistency works</h3>
Despite some UI refreshes and a migration of the user interface to React, the Spotify user interface has been recognizably the same in years. Commonality and consistency is a great perk in the toolbox of the power user. Spotify may not have brought anything new to the table, with respect to the interface, but I would pose that that's a good thing. I couldn't stand the Play Music interface for example, when I tried it a few years ago.
The base layout has everything you need. A list of playlists on the left. A list of (sometimes grouped) songs on the right. It's tried and true.
Pain points</h2>
Podcasts</h3>
This one is fairly common. It was the main reason to turn to Spicetify originally.
I listen to podcasts almost exclusively on my phone, and for better or worse have been using the Pocket casts app for that. I'm used to it, and do not intend to use Spotify anytime soon. Spicetify allowed me to filter podcasts out of the desktop app. But as I wrote earlier I stopped using it. It wasn't a perfect solution anyhow, as it only covered my desktop use.
I feel Spotify has been pushing podcasts less than they used to a few years back, and I'm glad. I considered unsubscribing several times because of how much podcasts were promoted, and interfered with my flow.
In "My Library", there still is this mandatory "Your Episodes" playlist (can't be much of "my" library if I don't have the power to remove it). I wish I could remove it natively.



On my desktop home page, I luckily only get music recommendations. I don't even need to select the "Music" filter for that. It feels like a bug, but to me it's a feature. On mobile however I explicitly need to filter music. As a result, I don't tend to use "home" on mobile much. As a result, I mostly discover music either via the "Discover weekly" playlist or the "Go to song radio" feature.
"Add song to playlist" on mobile</h3>
This feature of "adding a song to a playlist" is something that I keep disliking (on mobile anyways). It's a place where I feel the app authors keep telling me they know better than I do, to which playlist I would want to add a song.
The thing is, they do not permit me to browse in my custom sort order. Instead, they offer "Recently updated", "Recently added", "Alphabetical" and "Recently played". The only consistent ordering is "Alphabetic", which is approximately the reverse of my custom structure (older years for monthly playlists come first - while I want to add it to a more recent one). Arguably "Recently updated" works well for my workflow, but I value consistent ordering even more.

In my library I can thankfully use a custom order:

In addition to the sorting order, the "add to playlist" dialogs also have this odd feature where each folder with playlist in it, is virtualized (like a symlink) in the top level. As a result, you can navigate to playlists in deeper folders via their parents, or directly. But for someone who has a ton of playlists, and someone who added all these folders to create order, this feature just adds chaos.
For example, this is what I see from my library:

But "add to library" shows these deeper level folders at the top-level too:

This</a> video shows both (watch the folder titles).
When keyboard shortcuts don't match the highlighted action</h3>
With my playlist heavy workflow, I use the "add song to playlist" flow a lot. Spotify warns you when you add a duplicate (but doesn't block you). This is a great feature.


However, what do you expect to happen if you press "Enter", when "Don't add" is highlighted?

Exactly.
When desktop and mobile don't match</h3>
Spotify on desktop, and Spotify on mobile look share much of the visual design elements. I think the designers did a good job there. But as always, the devil is in the details.
It is the features, or lack thereof where pain points arise. Spotify on desktop is usually a more powerful platform. This is understandable since the mouse and the large screen allow for more precise interactions than touch and a portrait mode phone screen.
Still, after all these years, I still can't create new folders on mobile. It sucks that I need to open my desktop app for that.
Final words</h2>
I get it. I'm unlikely to be the average Spotify user. I've more than 300 playlists, rarely listen directly to albums or artists, and use this odd playlist centric workflow. Still, I have this hope, the hope of a long time subscriber, that one day the Spotify UI designers will recognize the power of user agency in app workflows and appreciate consist ordering more, like I do.

Github's malicious notification problem

2025-11-04T00:00:00+00:00

In the past four days or so, I've had notifications popping up for repositories which I didn't subscribe to myself.
At first I thought the notification bubble just wouldn't disappear because of a little bug in Refined GitHub</a>, but on closer inspection (and disabling the extension to be sure), it turned out it wasn't so.
This is what it looks like in my notifications list:

And because these notification aren't marked as read, the notification bubble at the top consistently suggests there's something new:

I wrote "aren't marked as read", but in reality the right word would be "can't". That is, the first image also shows that once you filter on the repository, while the bubble suggests there is one notification, according to the UI, there is none.
How</h2>
In GitHub you can tag someone by using @username</code> syntax, which is useful in good faith situations. I presume spammers created some issues in their repository and started tagging lots of users.
Presumably the repositories and accounts were removed by GitHub staff as manually navigating to the repository on GitHub, shows 404 pages.

I'm sad that the notifications weren't removed too, and we now have to resort to alternative methods to remove the notifications.
... Further searching suggests that this issue was initially reported</a> on 28th of October, 2021, so it isn't a new problem.
Workarounds</h2> As</a> it</a> turns out, I wasn't quite the only one who was affected by these spammers. In my searching, I found many community threads reporting the same issue, and asking for solutions to remove the "ghost" notifications. For example, in this</a> community thread, someone suggested to mark the notification as read using the GitHub API, which can be done using GitHub's own gh</code> CLI tool (replace the last_read_at</code> date as required): gh api notifications -X PUT -F last_read_at=2025-11-04T00:00:00Z </code></pre> However, you should know that it doesn't quite remove the malicious notifications from your notifications dashboard: Apparently, that can be done with the API too. I've adapted the invocation from this</a> thread, to match on the repository owner (instead of the notification subject title), and added a flag to paginate the notifications in case you have more than one page like me: gh api notifications\?all=true | jq -r '.[] | select(.repository.owner.login | test("(kamino-network|gitcoincom|ycombiinator|paradigm-notification)"; "i")) | .id' \ | xargs -L1 -I{} gh api --method DELETE \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /notifications/threads/{} </code></pre> Step by step explained in case you too want to adapt the query (I did use the gh</code> CLI, but you can send HTTP requests directly too). First we get all notifications by walking through all pages: gh api notifications\?all=true --paginate` </code></pre> Then we use jq</code> to query the JSON response from the GitHub API and filter specifically on the spam GitHub account names kamino-network</code>, ycombiinator</code>, gitcoincom</code>, and paradigm-notification</code>. Return the .id</code> of the notification if it's a match. jq -r '.[] | select(.repository.owner.login | test("(kamino-network|ycombiinator|gitcoincom|paradigm-notification)")) | .id' </code></pre> Combined so far with output: gh api notifications\?all=true --paginate | jq -r '.[] | select(.repository.owner.login | test("(kamino-network|ycombiinator|gitcoincom|paradigm-notification)")) | .id' 19167019306 19143656043 19133393664 19073885018 </code></pre> Now we want to remove each of these notifications. To just remove one we can just substitute one of these id's: gh api --method DELETE \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /notifications/threads/19167019306 </code></pre> We can use xargs</code> to do this for all id's, resulting in the suggested query: gh api notifications\?all=true | jq -r '.[] | select(.repository.owner.login | test("(kamino-network|gitcoincom|ycombiinator|paradigm-notification)"; "i")) | .id' \ | xargs -L1 -I{} gh api --method DELETE \ -H "Accept: application/vnd.github+json" \ -H "X-GitHub-Api-Version: 2022-11-28" \ /notifications/threads/{} </code></pre> Tada!
Where are the security advisories of the recently compromised NPM packages? 2025-09-13T00:00:00+00:00 Four days ago, news</a> came in that several packages on NPM were compromised; later it turned out to that it wasn't just one NPM account that was compromised by the (it seems) the same phishing attack, but multiple. The compromised accounts published new package versions containing malware which intercepted network traffic and replaced crypto wallet addresses with alternative malicious addresses. Various popular packages were affected, such as chalk</code> and debug-js</code> via Qix</a>'s NPM account, and duckdb</code> via the duckdb_admin</a> NPM account. The malware and compromised accounts (at least the one's we know of) was fairly quickly detected and actions were taken over the next few days to prevent the malicious NPM packages from being installed by downstream users. Props to all involved in the effort, and the open communication! Finding the security advisories</h2> Now yesterday, I wanted to find the security advisories for the affected packages for a report at my day job. This turned out to be not as easy as I expected. Simply searching for, e.g. chalk</a> on the GitHub Advisory Database page gave me four results, three</a> of</a> which</a> were sort of related, but none of them was the security issue in Chalk itself. I thought for a moment they maybe would have issued only a "top level" kind of advisory linked to e.g. the debug</code> package, since that repo was used as a central location to file most of the responses</a>, but no luck</a> (this sometimes happens when there is a CVE which links multiple packages, like in the case of the compromised DuckDB</a> packages. Changing the type to unreviewed</a> in case they would be filtered out by default gave even less results (0). Then I tried searching via the repo's themselves, for example chalk</a> and debug</a>. These seem to be exclusive to information posed by the maintainers, which in this case opted to use different channels as there is nothing there. However, good news! They do exist! I have no idea how I should have found them without going through GitHub's own advisory-database</a> repo though, which is not exactly setup to be searched by humans directly. This repo also hosts these</a> two</a> related issues, which both contain partial lists with links to the specific advisories. As examples, here are the advisories for: chalk</a>, and</li> debug</a></li> </ol> If I have to guess, then I would guess the advisories only show up after package maintainers have approved it from a security dashboard; but I am not sure. Now, another reason why the search may be so difficult, is that there doesn't seem to be a CVE for most packages (I couldn't find one, for example chalk</a> again). DuckDB however does have one</a>, and prebid-js has</a> two</a>. I'm unfamiliar with the process and can see that there are pratical limitations, not only because there are many parties involved and distributed over the world, but also because there are many different places where relevant info is posted, and a reasonable way to link from a root page may not be that obvious. Still, I feel that the way the information is published, presented and made searchable can be improved, for example by giving maintainers a more central way to publish status updates (i.e. written text) for multiple packages at once. Next time I would go directly to the github/advisory-database</code> repository, as it is unclear to me why some bits of information are not shown from the Advisories page</del>. While writing the post I found that GitHub's security advisories documentation</a> are probably hidden under explicit use of the type:malware</code> tag by default, because "most of the vulnerabilities cannot be resolved by downstream users". This is, I assume, also why DuckDB's advisory does show up; it is not tagged under malware (but posted to DuckDB's duckdb-node</a> repo, and also has a CVE, i.e. CVE-2025-59037). I don't know yet whether hiding malware typed advisories by default is a practice I like. I definitely don't like that I this is non-obvious from the advisories page itself. Still, most of my critique stands: finding the right information fast is difficult, and the way advisories are posted is different per package. When NPM deletes packages</h2> The second thing I felt can be improved is the way [npmjs.org] removes affected packages. I consider it a good practice to remove the packages to reduce amount of affected downstream users. However, from the website, it is not clear why the package was removed (or whether it existed ever). Take for example chalk</a>. The NPM website currently lists the following version history (I'll only list the last few packages): Version Downloads (Last 7 Days) Published 5.6.2 5,188,950 4 days ago 5.6.0 8,711,608 a month ago 5.5.0 1,769,950 a month ago 5.4.1 12,873,396 9 months ago 5.4.0 64,837 9 months ago </code></pre> NB: It doesn't matter whether you tick the "show deprecated versions" box. From this page, you have no idea that 5.6.1 was ever published and subsequently removed. I think it would be an improvement to show the version, and mark it explicitly as "removed", so users are not left guessing. That would help you in your search to find context about why it was removed. More information like related advisories would be a bonus. Luckily, you will find the reason for the removal reported through the CLI, which is a good thing. However, if you use e.g. renovate bot (the open source version), you could have merged a PR to update the package without ever having installed the package yourself (and subsequently not have seen the notice), perhaps even because the PR was created before the infected package was noticed by anyone. It is that easy to end up with a deployed release affected with malware. My critiques for both these issues are quite the same: the way information is presented when it is critical is not yet where it could be. Of course there are many vendors which offer scanners for packages and package ecosystems, which maybe offer some central way to access information about the compromise. Still, sometimes you also need more specific or end-use information, if possible from the source. I hope that the future will bring better tooling or presentations to quickly assess vulnerability situations, even before a post-mortem took place. Grammar checking from the CLI with Harper 2025-08-17T00:00:00+00:00 A few months ago I learned of the existence of Harper</a>, which describes itself as a lightweight, offline, grammar checker. Both the website and GitHub repository</a> are a bit sparse on how to use it, but they do link to all sorts of integrations</a>, which I think all use the Harper language server. There is also harper.js</a>, mostly for web applications and browser extensions. While the language server (or harper.js</code>) is great for extensive editor use, I sometimes just want to quickly check a file for spelling and grammatical issues. As it turns out, this is already possible by using the harper-cli</code> tool. This CLI is not documented on the documentation website, probably, as I found out later, because it is still listed as an experimental</a> frontend. I'm glad it exists though; it saved me from even considering how to use the LSP from the command line directly, and from installing and using one of the integrations. Installing it</h2> Installing it is easy! If you have Rust</a> and Cargo</a> installed, you can install it from source by running cargo install --locked --git https://github.com/Automattic/harper.git harper-cli</code>. On Windows I also found out you can install it using scoop</a>. I was delighted to see that scoop install harper</code> didn't just install the language server binary, but also harper-cli</code>. Using it</h2> The current version (0.1.0</code>), shows the following help page when running harper-cli --help</code>: A debugging tool for the Harper grammar checker Usage: harper-cli.exe <COMMAND> Commands: lint Lint a provided document parse Parse a provided document and print the detected symbols spans Parse a provided document and show the spans of the detected tokens annotate-tokens Parse a provided document and annotate its tokens metadata Get the metadata associated with a particular word forms Get all the forms of a word using the affixes words Emit a decompressed, line-separated list of the words in Harper's dictionary summarize-lint-record Summarize a lint record config Print the default config with descriptions mine-words Print a list of all the words in a document, sorted by frequency core-version Print harper-core version rename-flag Rename a flag in the dictionary and affixes compounds Emit a decompressed, line-separated list of the compounds in Harper's dictionary. As long as there's either an open or hyphenated spelling case-variants Emit a decompressed, line-separated list of the words in Harper's dictionary which occur in more than one lettercase variant nominal-phrases Provided a sentence or phrase, emit a list of each noun phrase contained within help Print this message or the help of the given subcommand(s) Options: -h, --help Print help -V, --version Print version </code></pre> For my use case, the most simple command sufficed: $ harper-cli lint .\content\posts\2025-05-15_thank_you_all_for_ten_years_of_stable_rust.md </code></pre> That gave me the following result: What a delightful way to check for flagrant spelling errors in markdown files. Thanks Harper authors! Thank you all for 10 years of (stable) Rust 2025-05-15T00:00:00+00:00 Today marks the 10th anniversary of Rust 1.0</a>. Rust 1.87</a> will be released live on stage at the 10 years of Rust celebration</a> this afternoon (hosted by RustWeek, there are still tickets I heard). Over these past 10 years, Rust had a major positive impact on my life in various ways, and I'm extremely grateful for that. Thanks to all Rust contributors and to our community, it has been a blast 🎉. An anniversary is usually a good moment to look forward, but it also marks a good moment to take a step back, and reflect a bit on the past. Yesterday I scrolled back through the release notes</a> for a bit, and reflected on some improvements which I've been taking more and more for granted. The one which pops out of that list the most (for me) is probably the ?</code> operator. It was stabilized in Rust 1.13.0</a>, but prototyped via the try!</code> macro some time before that. I can truthfully say that every time I write in another language, I miss that ?</code> and the associated Try</code></a> trait (I kind of wish the trait was marked stable 😅). The time where a large portion of the community was on nightly by default is now far in the past. With the vision doc for Rust taking shape, and likely hundreds of other improvements</a>, I can't wait for the next 10 years of stable Rust. Accessibility and Rust podcast at RustWeek 2025-05-13T00:00:00+00:00 Just hours ago, the first full conference day of RustWeek 2025</a> ended. Everything went smoothly, so big props to the organisers, volunteers*, the audio and video crew, and staff at the venue. Also shoutout to the people who designed and organized the stickers, they're really really great, and also to the excellent barista coffee ☕. The day ended for me by attending the live recording of the Rust in Production</a> podcast in which Matthias Endler interviewed Niko Matsakis about his experiences of building Rust over the past 10 years, and by attending the live recording of another podcast titled 'Accessibility and Rust' (which if I recall correctly will be published on the Rustacean Station</a>). In this podcast Luuk van der Duim</a> was joined by Matt Campbell</a> and Arnold Loubriat</a> to talk about their experience of working on libraries and tooling to make graphical user interfaces (GUI's) more accessible. Both sessions were excellent. I wanted to take a moment to say a few words about the second one, which really spoke to me. During the podcast Matt and Arnold give some insight into how they "see" graphical computer programs, and also how they often can't because of shortcomings or lack of accessibility in programs. From a software engineering point of view, I have a feeling, we often shove accessibility features under the rug because of a perceived lack of business need, cost or complexity, so I'm happy there are people working on lowering the barrier. This talk also addressed another possible reason (amplified by the audience after the recording session), that for many developers who don't use assistive technologies like screenreaders, it's opaque how to build software that is accessible. On top of that, there is also the question of how to test whether you did it right, given you're not a regular user of assistive technologies. AccessKit</a> tries to help solve the first question, and has amongst others, been used to improve accessibility support for Slint</a>, a GUI toolkit**. For the second question, I hope people will support their work and perhaps provide funding to them (or others) to develop a general test suite or framework which can be used by implementers of accessibility libraries***. In the mean time, I found that there is an introduction</a> on the topic over at MDN, which has a particular focus on accessibility for webpages, but also includes a more general introduction. Matt will give a talk about AccessKit</a> tomorrow at 10:25</a> local time (main track). RustWeek has a livestream</a> if you want to follow along online. Recordings of talks will be published online at a later moment. * Disclaimer: I also volunteered, props go to the other volunteers 😉. ** I'm not involved with Slint in any way *** I may be ignorant of the existence of such a test suite; sorry! Orphaned markdown [brackets] 2025-04-19T00:00:00+00:00 Every project needs a changelog. And let's be honest, the work keep-a-changelog</a> did to make this a more common practice is awesome. But there is something many seem to forget: Did you ever notice [version numbers] in release titles within a CHANGELOG.md</code>? These brackets were supposed to be links</a>. But in reference style, you need to complete the reference elsewhere. Let's look at an example (also in the wild</a>): ## [0.18.3] - 2025-04-19 - Lost: reference to the version number 0.18.3 somewhere </code></pre> This snippet, produces the following output: [0.18.3] - 2025-04-19</h2> Lost: references to version numbers</li> </ul> However, if you scroll to the bottom of the keep-a-changelog example</a>, you can see that the version numbers in brackets, have their link completed at the bottom. And rendered, it looks like this</a>. So how do we fix our changelog? By adding reference style links: ## [0.18.4] - 2025-04-19 - Found: references to version numbers [0.18.4]: https://github.com/foresterre/cargo-msrv/compare/v0.18.3...v0.18.4 </code></pre> This produces the following output: 0.18.4</a> - 2025-04-19</h2> Found: references to version numbers</li> </ul> Don't like linking to the diff?</h1> Not a problem. Use an alternative like a release</a> page or something else you like. Or just leave the brackets out: 0.18.5 - 2025-04-19</h2> Also good: This version number has no link</li> </ul> Call to action</h1> So next time you write a changelog, please keep these digital tumbleweeds out. Complete your links, fix your [brackets]! A sneak peek Into:: (slide deck, 2022) 2025-02-27T00:00:00+00:00 Today I rediscovered a slide deck I made for a lunch talk I gave at the beginning of 2022. It is an introduction to Rust, and specifically the features which made me fall in love with Rust since 2014. It was aimed at an engineering audience consisting of among others software engineers, mechanical engineers and control systems engineers. Everyone in the audience had at least some programming experience. I decided to post it to my blog, in case anybody would like to use it for inspiration, or would find it otherwise useful. The slide deck can be found here</a>. P.S. the title was a bit of an inside joke. It might not roll off the tongue as nicely as I would have wanted otherwise 🙃. A few cargo-msrv 0.16 release highlights 2024-10-09T00:00:00+00:00 A quick tour through some of the cargo msrv 0.16.0</code></a> highlights. What is cargo-msrv</code></a>?</h2> cargo-msrv</code> is a cargo plugin</a> which helps you "Find the minimum supported Rust version (MSRV) for your project". Aside from finding the MSRV, it has additional tools baked in, such as listing the MSRV's of dependencies and verifying your (new) code against a given MSRV. Find out more here</a> 😉. The tour</h2> The remainder of this post can also be found in the cargo-msrv</code> book</a>. The noticeable one - cargo msrv find</h3> The tagline of cargo-msrv</code> is "Find the minimum supported Rust version (MSRV) for your project". Previously, one could achieve this by running cargo msrv</code>. If you want to do the same in 0.16, you instead should run cargo msrv find</code>. The top level cargo msrv</code> action is no more. There are two primary reasons to move this action to a subcommand instead of keeping it at the top level: Consistency: cargo msrv</code> can do more than that tagline, and placing all actions on the subcommand level signals that they're equals.</li> Unsupported CLI flags and options: When actions are placed on two layers, and one of these layers is below the other, then the bottom layer inherits its flags and options, even though they do not always overlap. For example, the set of CLI flags and options of cargo msrv find</code> and cargo msrv list</code> are not identical. cargo msrv find</code> for example has an option called --release-source</code> which should be present for cargo msrv find</code> but not for cargo msrv list</code>. If cargo msrv find</code> would still be run as cargo msrv</code>, you could also invoke this option for cargo msrv list</code>, like so: cargo msrv --release-source rust-dist list</code>. However, contextually, the --release-source</code> option does not make sense for cargo msrv list</code>, so previously it was ignored. By making cargo msrv find</code> a subcommand like cargo msrv list</code>, the flags and options which are not shared between all actions can be put solely below their own subcommand.</li> </ol> A consequence of (2) is that some unnecessary options and flags have been removed from the top level, and so this is a breaking change, not just for cargo msrv find</code> but also for cargo msrv list</code>. Minor reasons for this change include that I can now talk about cargo msrv find</code> as "cargo msrv find</code>" instead of cargo msrv (find)</code> or "the top level command". Plus, it addressed some difficulties around the code which does CLI parsing, about which I wrote in this</a> previous post. I'm glad I opted to go this route instead though 😅. The UI part 1: output format options</h3> The way the UI is rendered has been updated. Internally, it is now easier to add and maintain different output formats. cargo-msrv</code> now supports 3 output formats: human (the default one, intended for the human eye)</li> json (intended for machine readability)</li> minimal (*new*, it was requested for environments where people only care about success/failure, such as CI)</li> </ul> The UI part 2: cargo msrv find</code> and verify</code> "human" output</h3> As they say, "a picture is a thousand words": Previously... </a> New... </a> I'll be iterating the UI further in the future. Constructive feedback is more than welcome! cargo msrv find --write-msrv</code></h3> This option will write the MSRV to your Cargo manifest: </a> cargo msrv find --min</code> and --max</code></h3> The --min</code> and --max</code> options would previously only take three component semver versions like "1.2.3" or editions. It is common to specify the MSRV in a two component version like "1.2", so these are now also supported. cargo msrv verify --rust-version</code></h3> cargo msrv verify</code> can be used to check whether your project is compatible with its MSRV. The MSRV is usually read from the Cargo manifest (Cargo.toml</code>). Sometimes it can be useful to provide it manually instead. That's where this option comes in handy. It should be noted that cargo-msrv</code> does, at present, not unset any value you may have specified in the Cargo manifest. So if you have a Cargo manifest with rust-version = "1.56.0"</code> and supply the --rust-version</code> option with the value 1.55.0</code>, the cargo project will (if the default options are used) fail to compile, and as a consequence cargo-msrv</code> will report that your crate is not compatible with the specified MSRV. Fetching the rust releases index</h3> The rust releases index, the thing we use to figure out which Rust versions exist, are now only fetched when a subcommand needs it (currently cargo msrv find</code> and cargo msrv verify</code>). The changelog</h3> The complete changelog can be found here</a>. Thanks!</h2> Thanks to all contributors, whether you submitted a PR</a> or reported an issue</a>, or contributed in some other way. Some of your issues and PR's really made my day! 💛 Puzzle: Sharing declarative args between top level and subcommand using Clap 2024-06-25T00:00:00+00:00 Alternative title: ... And a short introduction to cargo msrv</code> The problem</h1> In cargo-msrv</a> we have the following situation. The top level command is used when "finding the MSRV" of a Rust project, while a subcommand can be used to verify that a specific MSRV works for a given project. The former can be done by running cargo msrv</code> while the latter would be cargo msrv verify</code>. Once upon a time, an issue was reported that cargo msrv --target x verify</code> worked, but cargo msrv verify --target x</code> did not. Another Cargo tool used by the reporter, together with cargo-msrv</code>, would always specify the latter form, so the former could not be used as a workaround. While diving into this issue I figured, this should work: cargo msrv --target x verify</code></li> cargo msrv verify --target x</code> (equivalent to 2 for the user)</li> </ol> But this should not: cargo msrv --target x verify --target y</code></li> </ul> The latter form is confusing to a user. If you allow both, you have to consider which takes precedence. Or whether they define the same thing. This should also not work (since the list</code> subcommand currently doesn't use the target</code> CLI argument at all): cargo msrv --target x list</code></li> cargo msrv list --target x</code></li> </ul> This post describes a short journey into the search for a satisfying solution. cargo-msrv</code> uses clap</code>, the most commonly used CLI argument parser (in the Rust library landscape). For the remainder of this post I will assume some familiarity with Rust and clap</code>. Background on cargo msrv</h2> This section can be useful to better understand this post since I decided to keep the original problem, instead of describing a more minimal reproduction. But feel free to skip this section (I might refer back to it though 😜). A short history cargo-msrv</code> was originally born out of a desire to find the MSRV for a Rust project (more specifically package). MSRV stands for "minimal supported Rust version" and is the earliest or oldest version supported by a Rust project. For different projects this may mean different things, but for this post I will consider "support" as "does compile with a Rust toolchain of a certain version". Fast forward a few years, and the MSRV has become somewhat more ubiquitous which can also be seen by its inclusion into Cargo as the rust-version</a>. Over time some additional tools were added to cargo-msrv</code>. One of these was the cargo msrv verify</code> subcommand. This subcommand can be used to check whether a Rust project supports its defined MSRV (e.g. via this rust-version</code> field in the Cargo manifest). For example, in a CI pipeline you can use this to check whether your project works for the version you promised to your users. Originally, I kept the cargo msrv</code> top level command aside from the subcommands for backwards compatibility reasons. In hindsight I probably shouldn't have done that, but as is, their coexistence at least provides me with the opportunity to write this blog post 😅. How cargo msrv works I described the "support" from "minimal supported Rust version" (MSRV) above as the somewhat simplified "does compile with a Rust toolchain of a certain version". You may write that as a function like so: fn is_compatible(version) -> bool</code>. If you run this test for some Rust version, when the function produces the value true</code>, then we consider the Rust version to be supported. If instead the function produces the value false</code>, then the Rust version is not supported. cargo msrv</code> specifically searches for the minimal Rust version which is supported by a given Rust project. While there are some caveats, we build upon Rust's stability promise</a> . In our case that is the idea that Rust versions are backwards compatible. For a simple example to determine an MSRV, you can linearly walk backwards from the most recent Rust version to the earliest. When your project doesn't compile for a specific Rust version, then the last version that did compile can be considered your MSRV. Let's make it a bit more concrete with an example. For this example, we assume that Rust the following Rust versions exist: 1.0.0</code> up to and including 1.5.0</code>. Consider a project which uses the Duration</a> API which was stabilised by Rust 1.3.0</a> (and nothing more recent 😉). Then, if you would compile this project with Rust version from most recent to least recent, you would expect the following to happen: is_compatible(Rust 1.5.0)</code> returns true</code> ✅</li> is_compatible(Rust 1.4.0)</code> returns true</code> ✅</li> is_compatible(Rust 1.3.0)</code> returns true</code> ✅</li> is_compatible(Rust 1.2.0)</code> returns false</code> ❌ ("Duration is not stable")</li> is_compatible(Rust 1.1.0)</code> returns false</code> ❌</li> is_compatible(Rust 1.0.0)</code> returns false ❌</li> </ul> Since we only care about the minimal Rust version, you could have stopped searching after compiling Rust 1.2.0; Rust 1.3.0 was the earliest released Rust version which worked. In reality doing a linear search is quite slow (at the time of writing, there are 79 minor versions), so we primarily use a binary search instead to incrementally reduce the search space. cargo msrv verify</code> works quite similar to "finding the MSRV", but instead of running a search which produces as primary output the MSRV, in this case the MSRV is already known in advance. So given a MSRV</code> of 1.3.0</code> we just run the is_compatible(Rust 1.3.0)</code> function once. If it returns true</code> we can say that the 1.3.0 is an acceptable MSRV (although not necessarily strictly so). More importantly, if it returns false, then the specified version is actually not supported, and thus can not be an MSRV). Enough background, back to the post. Definition of the CLI</h1> cargo-msrv</code> uses clap</code> as its CLI argument parser. It nowadays uses the macro derive</code> based API. In the code blocks below, I have isolated the primary definition of the CLI which describes the cargo msrv</code> top level command (a.k.a. Find</code> in the code), and the cargo msrv verify</code> subcommand. I've taken the liberty to remove some unnecessary details, and added some arrows and comments for relevant items. Otherwise, this code is the copied directly from the actual source. #[derive(Debug, Args)] #[command(version)] pub struct CargoMsrvOpts { // <- The top level, i.e. `cargo msrv {...}` #[command(flatten)] pub find_opts: FindOpts, // <- Options relevant for "find msrv" #[command(flatten)] pub shared_opts: SharedOpts, #[command(subcommand)] pub subcommand: Option<SubCommand>, // <- Subcommands, like "verify" in "cargo msrv verify" } #[derive(Debug, Args)] #[command(next_help_heading = "Find MSRV options")] pub struct FindOpts { #[arg(long, conflicts_with = "linear")] pub bisect: bool, #[arg(long, conflicts_with = "bisect")] pub linear: bool, // ... omitted some options for brevity #[command(flatten)] pub runner_opts: RunnerOptsFind, } </code></pre> CargoMsrvOpts</code> is the top level CLI interface, i.e. cargo msrv</code>. The options relevant to "finding the MSRV" are specified on the top level (i.e. FindOpts</code>). FindOpts</code> should not be used for other subcommands (ironic considering this post, I know, at least cargo msrv verify --help</code> doesn't list them 😜). #[derive(Debug, Subcommand)] #[command(propagate_version = true)] pub enum SubCommand { List(ListOpts), Set(SetOpts), Show, Verify(VerifyOpts), // <- The options for the verify subcommand } #[derive(Debug, Args)] #[command(next_help_heading = "Verify options")] pub struct VerifyOpts { #[command(flatten)] pub runner_opts: RunnerOpts, // <- The options we want to share between the top level "find msrv" (i.e. 'cargo msrv') and "verify msrv" subcommand (i.e. 'cargo msrv verify') #[arg(long, value_name = "rust-version")] pub rust_version: Option<BareVersion>, } </code></pre> Options supplied to the verify</code> subcommand are specified by the VerifyOpts</code> struct. As a user, you would interface with it like so: cargo msrv verify {opts}</code>, e.g. cargo msrv verify --target example</code>. #[derive(Debug, Args)] pub struct RunnerOpts { #[command(flatten)] pub rust_releases_opts: RustReleasesOpts, #[command(flatten)] pub toolchain_opts: ToolchainOpts, // <- The examples will use this one #[command(flatten)] pub cargo_check_opts: CheckCommandOpts, } #[derive(Debug, Args)] #[command(next_help_heading = "Toolchain options")] pub struct ToolchainOpts { #[arg(long, value_name = "TARGET")] pub target: Option<String>, #[arg(long, value_name = "COMPONENT")] pub add_component: Vec<String>, } </code></pre> RunnerOpts</code> specifies options relevant to run the is_compatible</code> test I introduced in the How cargo msrv works section. What this actually entails is not relevant to this post. All you need to know is that each of these flattened commands define some arguments. I will use the arguments in ToolchainOpts</code> for the examples: --target</code> (as my primary example) and --add-component</code> (just to point out some edge cases). The last detail I will add is that for both the "find msrv" top level command and each of the subcommands, we produce a flattened context which contains the inputs for that command. Both the FindContext</code> and VerifyContext</code> contain a pub toolchain: ToolchainContext</code> field. The context is currently created via the TryFrom</code> trait from the Opts</code> (or resolved from the environment) to the Context</code>. The fields in the ToolchainContext</code> can be considered static for the duration of the program. The goal</h1> Let's make the problem a bit more concrete again. First lets be explicit: the problem is limited to "matching (in name and type) CLI arguments which can be provided to both cargo msrv</code> and cargo msrv verify</code>", and I'll mention that if no value is given for either, we use some default which we will assume just exists. In the end, (1) we want to end up with a CLI interface like cargo msrv {top_level_arg} verify {subcommand_arg}</code> where a matching argument is provided to either the top level xor</code> the subcommand xor</code> use the default. In addition, (2) the matching args should not be available to subcommands, other than verify</code>. In the next section, I'm going to throw some ideas over the wall. To generate these ideas I primarily used the clap</code> rustdoc documentation on docs.rs</a> as a reference. Let me spoil it for you in advance 🙄: None of these solutions really make me happy, so I will probably choose a pragmatic choice instead. I mention this beforehand because I want to explicitly state that none of this is something I blame on clap</code> (or anyone else). clap's</code> documentation is extensive, and is very well written. If it is described, then I didn't look in the right places. It might just be a puzzle I haven't solved yet 🧩. Also, this scenario where you have a top level CLI and some subcommands which have to share some things is most likely non standard, and honestly, discouraged for similar reasons as why I'm putting this effort in: user experience. Idea 1: merging Opts</h1> A first idea is to keep the current definition and simply merge its values. You may see some obvious flaws with this: first, goal (2) will not be met, since one of the RunnerOpts</code> is defined on FindOpts</code> which is at the top level of the CLI, so subcommands other than verify</code> will also have allow the arguments defined by RunnerOpts</code> to be specified (even though they will be ignored). Second, goal (1) is dependent on custom merging logic. For this, let's quickly consider the output which we would get from clap</code> after it parsed the CLI arguments like in this idea (in simplified Rust code), to consider what it would look like: let opts = CargoMsrvOpts { ... }; // Output from Clap's parse method let find_opts = opts.find_opts; let Some(VerifyOpts(verify_opts)) = opts.subcommand else { todo!() }; let find_toolchain_opts = find_opts.runner_opts.toolchain_opts; let verify_toolchain_opts = verify_opts.runner_opts.toolchain_opts; </code></pre> If opts.subcommand</code> is not Some(VerifyOpts(_))</code> then we can simply take all arguments from the find_toolchain_opts</code>. If opts.subcommand</code> is Some(VerifyOpts(_))</code>, then we would need to merge find_toolchain_opts</code> and verify_toolchain_opts</code>. Most of this merging code would likely be fairly trivial considering the limited common CLI input options and the XOR-or-default condition that clap</code> would enforce if this concept worked. Values which are marked as optional, i.e. via the Option<T></code> type are trivial. If one is Some</code>, then the other one must be None</code> (by the XOR-or-default condition). Values which instead use a default value, may not be so clear cut. There is the question: did the user provide this default value, or was it omitted. The first case is a choice, similar to Some</code>, while the second case is a fallback to a default like None</code>. This information is no longer known after argument parsing. The good news however is that we only need to compare two values per field. Consider enum Choice { #[default] A, B, C }</code>. Since we know that at most only one of the two values was provided, since if our idea works, the argument parser rejects if the user provides both. From an external point of view, there are four options A (default), A (provided), B and C</code>. However, we have to decide on a merged value for each pair just using their values A, B and C</code>. If values B or C, on both find xor verify</code>, are given it is simple: by the XOR-or-default condition, B and C are always the user selected values. For A, we luckily do actually not need to care whether it was provided or not. If the other side provides B or C, it was the default (see previous), and if it is A, then we can simply use A. -> I feel the merging/selecting would likely be reasonably possible with this fairly simple scenario in mind, but haven't put much thought into searching counter arguments where it doesn't work (or proving that it always works for that matter). </blockquote> Yet, it would still all be a bit too hairy for my liking considering we use the derive</code> API to get a nice declarative, clean looking argument parser. Positives: The code (likely) compiles</li> The interface becomes no worse than it is today</li> </ul> Negatives: Custom merging logic on top of the declarative API</li> </ul> Currently my preferred choice, mostly because it won't worsen the current user experience. Idea 2: naming a command</h1> If we could name one of these derived commands, then we might get away with saying to clap</code>: "the fields within this named command are incompatible with the fields in this other named command"; i.e. I'm trying to apply some constraint. #[derive(Debug, Args)] #[command(next_help_heading = "Find MSRV options")] pub struct FindOpts { #[arg(long, conflicts_with = "linear")] pub bisect: bool, #[arg(long, conflicts_with = "bisect")] pub linear: bool, // ... omitted some options for brevity #[command(flatten, id = "runner_opts_find", conflicts_with = ["runner_opts_verify"])] pub runner_opts: RunnerOptsFind, } #[derive(Debug, Args)] #[command(next_help_heading = "Verify options")] pub struct VerifyOpts { #[command(flatten, id = "runner_opts_verify")] pub runner_opts: RunnerOpts, #[arg(long, value_name = "rust-version")] pub rust_version: Option<BareVersion>, } </code></pre> Unfortunately, this idea doesn't quite cut it. Deriving flatten</code> and supplying an id</code> at the same time is not allowed: error: methods are not allowed for flattened entry --> src\cli\find_opts.rs:53:15 | 53 | #[command(flatten, id = "runner_opts_find", conflicts_with = ["runner_opts_verify"])] | ^^^^^^^ </code></pre> -- If this idea would have worked, we also would still need to merge the Opts</code> together, like in the last example. The other reason why this idea is doomed is that when you put the id on the whole group of arguments, I suspect that once you give any argument in either the top level or the subcommand, all other values in the group must also be from the same group; otherwise they would be considered in conflict. Considering cargo msrv {group_top_level} verify {group_subcommand}</code>, then cargo msrv --target x --add-component y verify</code> or cargo msrv verify --target x --add-component y</code> would be fine, but mixing it up like cargo msrv --target x verify --add-component y</code> would be in conflict. Positives: I can dream about a declarative only solution</li> Maybe this would work on an argument level? I haven't tried that yet</li> </ul> </li> </ul> Negatives: Doesn't compile</li> Likely wouldn't work in the first place</li> If it did, it would likely work per whole group, so I would have to use a group per argument</li> </ul> Idea 3: Separate structs, groups and conflicts</h1> I also wanted to try a variation on the previous idea: this idea instead provides two 'separately' nameable things, which then can be marked to be in conflict with one another. We only let the top level variant be in conflict with the subcommand variant, since the latter cannot exist without the former. #[derive(Debug, Args)] #[command(next_help_heading = "Find MSRV options")] pub struct FindOpts { #[command(flatten)] pub runner_opts: RunnerOptsFind, } #[derive(Debug, Args)] #[command(next_help_heading = "Verify options")] pub struct VerifyOpts { #[command(flatten)] pub runner_opts: RunnerOptsVerify, // ... etc. } // NB: Should be kept in sync with `RunnerOptsVerify`! #[derive(Debug, Args)] #[group(id = "runner_opts_find", conflicts_with = "runner_opts_verify", multiple = true)] pub struct RunnerOptsFind { #[command(flatten)] pub rust_releases_opts: RustReleasesOpts, #[command(flatten)] pub toolchain_opts: ToolchainOpts, #[command(flatten)] pub cargo_check_opts: CheckCommandOpts, } // NB: Should be kept in sync with `RunnerOptsFind`! #[derive(Debug, Args)] #[group(id = "runner_opts_verify", multiple = true)] pub struct RunnerOptsVerify { #[command(flatten)] pub rust_releases_opts: RustReleasesOpts, #[command(flatten)] pub toolchain_opts: ToolchainOpts, #[command(flatten)] pub cargo_check_opts: CheckCommandOpts, } </code></pre> However, running results in: cargo run -- msrv verify --target x Compiling cargo-msrv v0.16.0-beta.22 (C:\ws\cargo-msrv) Finished `dev` profile [unoptimized + debuginfo] target(s) in 11.24s Running `target\debug\cargo-msrv.exe msrv verify --target x` thread 'main' panicked at C:\Users\x\.cargo\registry\src\index.crates.io-6f17d22bba15001f\clap_builder-4.5.7\src\builder\debug_asserts.rs:314:13: Command msrv: Argument group 'runner_opts_find' conflicts with non-existent 'runner_opts_verify' id stack backtrace: </code></pre> There's probably a logical explanation here why this doesn't work; I guess I don't properly understand how ArgGroup</code> works... Neutral: I don't seems to understand ArgGroup</code> properly yet</li> </ul> Idea 4: global = true</h1> This was the first idea I had when I read the originally reported issue. It will again not satisfy goal (2), because marking a command as global, makes it, well, available to all subcommands. This could however be a pragmatic choice, since in the current form they're already present via the top level FindOpts</code>. #[derive(Debug, Args)] #[command(next_help_heading = "Toolchain options")] pub struct ToolchainOpts { #[arg(long, value_name = "TARGET", global = true)] pub target: Option<String>, #[arg(long, value_name = "COMPONENT", global = true)] pub add_component: Vec<String>, } </code></pre> When I looked at this idea in more detail, I actually found that this may be considered slightly worse since cargo msrv list --target x</code> would be valid when global = true</code>, while the current form 'only' allows cargo msrv --target x list</code> (the residue of having the FindOpts</code> at the top level). Plus, the current form does, for better or worse, not show the FindOpts</code> help text when providing --help</code> on the subcommand: i.e. cargo msrv verify --help</code>. Now, it also doesn't really satisfy goal (1). For example: cargo msrv --add-component a --add-component b --target x verify --add-component c --add-component d --target y</code> , produces: toolchain: ToolchainContext { target: "y", components: [ "c", "d", ], }, </code></pre> While, cargo msrv --target x --add-component a verify --add-component b --target y --target z</code> , does result in : error: the argument '--target <TARGET>' cannot be used multiple times</code> Positives: The code compiles</li> Most simple scenarios work</li> It doesn't need hairy merging code (on the surface)</li> </ul> Negatives: The interface will allow additional ignored arguments for subcommands other than verify This list can grow large if all of RunnerOpts</code> arguments are included</li> </ul> </li> Mixed usage does not limit the num_args</code> for Args</code> on a global level</li> Mixed usage overwrites values specified on a deeper subcommand level Behaviour can possibly be changed with ArgAction</code> (?)</li> This wouldn't be a problem if on a global level it is possible to enforce that arguments could be only provided to one level / for non collection types, that the num_args</code> would be complied with on the global level</li> </ul> </li> Mixed usage is unintuitive for a user</li> </ul> Remarks on using Clap</h1> In this likely non-standard use case. Clap's API surface</h2> Clap</code> has grown quite the set of options. There's something for everyone. It may very well still be possible to fulfill the use case I described above. Just because I couldn't find it after searching for it for a while doesn't mean it doesn't exist. In the end, I decided to choose pragmatic over pure. Skip</h2> Many attributes define the magic skip</code> option. It is available for ArgGroup</code> and Arg</code>. It is not available to Command</code> in general (a variation with different behaviour is on Subcommand</code>). At first it sounded like logical name for the something I'm looking for, however it ignores fields and sets a provided expression (or Default::default if omitted), so this doesn't feel like it works. Aside: what kind of expression should I even put in, even if it fulfilled my use case; you would need to be able to refer to something which ought to be skipped. In my case that would be conditionally skipping if the subcommand is Some(s) where S is not Verify</code> Command::args_conflicts_with_subcommands</h2> For a second, I hoped that if a command could be marked with args_conflicts_with_subcommands</code> we could then reject all subcommands which are not verify</code>, but this method args_conflicts_with_subcommands(...)</code> takes a bool; not a list of subcommands... 😭, and has another use case altogether... Shared value state</h2> At some point I had a fleeting wish that there could be a GroupArg</code> (or something else altogether) where values share their state. I.e. given a group G</code>, defined on the top level as G_t</code> and on a subcommand as G_s</code>, when setting a value for G_t</code> or G_s</code>, their value state would be shared. Still just this would not solve the most prominent problem, i.e. for the user we want to explicitly allow just one of each argument for any i</code> in G_i</code> to be defined... I suppose, this is not dissimilar to global = true</code> on Args</code>, except for some action override since global = true</code> doesn't work intuitively by default for args defined on mixed levels. Derive and groups</h2> When using derive, it is not always straightforward to get an Arg</code> from a group, since we have the derived structs; not ArgMatches</code>. With ArgMatches</code> you can, if I understand the documentation correctly, get the value of the group using one of the get_{}</code> methods on ArgMatches</code>. Possibly I could hack this together by using ArgAction::set</code> with Command::args_override_self(true)</code> ..? I still think I don't really understand the true value of ArgGroup</code>. The "a group of shared commands" I was looking for is probably something else entirely. 😉 Conclusion</h1> If you, dear reader, by any chance know how to solve the issue of this post, or have other ideas: I love to learn</a> (about them). ^{You also send me a mail, or contact me in another way, see my GitHub profile.} In the mean time, I suppose that this just isn't the way forward. To meet goal (2) in particular, having some shared arguments also at the top level makes solving the issue a lot harder. I tried to add constraints on how this definition could be used, but none of these really worked out. Maybe it is finally time to sunset the cargo msrv</code> top level command and introduce a dedicated subcommand for "find your msrv" instead. p.s. I kind of wrote this all on a whim, so it may be full of mistakes 🫧. Thanks!</h1> This post is based on an issue</a> originally reported by Finomnis</a> , thanks! A tale of setInterval and useEffect in React Native 2024-04-19T00:00:00+00:00 At work, I've been building a new React Native</a> app. Initially, I wanted this app to be as simple as possible, to allow for quick iterative cycles. Now this app needs to refetch a certain resource from the server in regular intervals. I have to admit: I briefly considered to use React Query</a>, but decided it wasn't quite time for that yet. Simple first. Complex later. I looked at the React Native docs in an attempt for figure out what the canonical way of doing this was. The docs told me: "hey, you can use the Timers</code> module which contains setInterval</code> and clearInterval</code>". Just what I needed! setInterval</code> executes a callback after a given milliseconds delay. It doesn't have the option to immediately fire, however. Luckily it's not hard to work around this: for example by just executing the function provided in the callback first. As an alternative, MDN</a> suggested that you could also use setTimeout</code>, although in my case, the execution duration is shorter than the interval frequency, so I figured everything should be fine 🤞. To give an idea of what the code looked like: export default function MyComponent(): React.JSX.Element { useEffect(() => { setInterval(() => void fetchResource()); }, []); } async function fetchResource() { try { const result = await client.resource.fetch(); setOk(result); } catch (error: unknown) { const error = ResourceErrorParser.parseError(error); setError(error); } } </code></pre> Now one of the most useful features of React Native, is its ability to live inspect changes you just made. Running the Metro</a> development server in combination with a debug build of the app gives you live updates out of the box. For me, that's simply running npm run start</code> to start Metro and in a second terminal tab npm run android</code> to build a debug build of the app and install it on a device (or emulator). Now, changes made to components or other code can be updated, and the changes can be observed on the app without rebuilding. Great! One day, I was checking the logs in the Metro terminal app, and I there seemed to be a few too many fetches to the backend. Normally, it should refetch the resource every 10 seconds or so (or immediately after certain actions), now it was making requests to fetch the resource tens of times per second. Whoops. So what happened? The callback in useEffect</code> was being rerendered after each change in the code. And as a result, the setInterval</code> function was being rerun as well. On repeat. Oops 😅. Luckily, it can be fixed! As it turns out, setInterval</code> can return a clean up function, which runs when the component unmounts (or when the props get updated and the dependencies provided to the useEffect</code> have been changed, or even every rerender if no dependency array is provided): type Id = ReturnType<typeof setInterval>; // elsewhere: export default function OtherComponent(): React.JSX.Element { const [refetchId, setRefetchId] = useState<Id | undefined>(undefined); return <MyComponent id={refreshId} setId={setRefetchId} onClear={() => setRefetchId(undefined)} />; } export default function MyComponent(props: { id?: Id; setId: (id: Id) => void; onClear: () => void; }): React.JSX.Element { useEffect(() => { const id = setInterval(() => void fetchResource()); props.setId(id); return () => ({ if (id) { clearInterval(id); } }); }, []); } </code></pre> Note that the dependency array can be empty, since we only want to disable the fetch task if the component is unmounted. Otherwise it can just do its thing and fetch the resource at each specific interval. And you know what. That's good enough for me, ... at least for now. Wishlist: I wish there was a way to see all active useIntervals and useTimeouts: if you know a way (without storing the id with some state management utility): please let me know</a> 🙏 I did end up extending the functionality ever so slightly: I added the option to toggle refreshing altogether and changed when refetches happen, to reschedule the interval when a manual refresh happened (which happens after certain actions) 😅. Feedback & discussion</h1> Feedback is most welcome. Feel free to discuss at GitHub</a>. What's new in Yare 3.0.0 (A lean parameterized testing macro for Rust) 2024-03-08T00:00:00+00:00 What is Yare?</h1> Yare</a> is a lean parameterized testing macro for Rust. This practically means that when using #[yare::parameterized]</code>, it is easier to write a test scenario, which can be tested against multiple different inputs. Each set of inputs is a separate test case. For example: use yare::parameterized; #[parameterized( apple = { Fruit::Apple, "apple" }, pear = { Fruit::Pear, "pear" }, blackberry = { Fruit::Bramble(BrambleFruit::Blackberry), "blackberry" }, )] fn a_fruity_test(fruit: Fruit, name: &str) { assert_eq!(fruit.name_of(), name) } </code></pre> The above scenario will generate 3 test cases: apple</code>, pear</code> and blackberry</code>, while it was only necessary to specify the scenario once. As you might imagine, if your add more tests, the removal of duplicated test cases does not only save writing (and maintenance!) time, but makes it also easier to keep scenarios the same for a large set of inputs (especially while refactoring code, changes to test scenarios may sneak in, which should also have applied to equivalent inputs). What's new in 3.0.0</h1> Custom test macro (e.g. tokio::test)</h2> Prior to 3.0.0, Yare would always generate test cases with the Rust built in #[test]</code> attribute. While it is exceptionally useful to have this macro built in, at times you may want to use a different macro because the built-in one doesn't support a feature you need. A common example is the tokio::test</code> macro, when using the tokio</a> asynchronous runtime. While you could create your own Runtime</a> and spawn futures onto this runtime for your test cases, it is perhaps not as elegant as using the tokio::test</a> macro. With this use case in mind, Yare can now be used with user specified test macro's. If none is specified, the Rust built-in #[test]</code> will be used. Example use yare::parameterized; #[parameterized( zero_wait = { 0, 0 }, show_paused = { 500, 0 }, )] #[test_macro(tokio::test(start_paused = true))] async fn test(wait: u64, time_elapsed: u128) { let start = std::time::Instant::now(); tokio::time::sleep(tokio::time::Duration::from_millis(wait)).await; assert_eq!(time_elapsed, start.elapsed().as_millis()); } // to use `start_paused = true`, enable the test-util feature for your tokio dependency // example inspired by: https://tokio.rs/tokio/topics/testing </code></pre> How does it work?</h3> To make this work, the #[parameterized(...)]</code> attribute in Yare parses all attributes placed after it (all attributes must be placed on top of the test function): use syn::parse::{Parse, ParseStream, Result}; enum Attribute { /// A regular attribute, which isn't named "test_macro" /// NB: Attribute and syn::Attribute are not the same! Normal(syn::Attribute), // An attribute named "test_macro" TestMacro(syn::Meta), } pub struct TestFn { attributes: Vec<Attribute>, fun: syn::ItemFn, } impl Parse for TestFn { fn parse(input: ParseStream) -> Result<Self> { Ok(TestFn { attributes: input .call(syn::Attribute::parse_outer)? .into_iter() .map(|attr| { if attr.path().is_ident("test_macro") { attr.parse_args::<syn::Meta>().map(Attribute::TestMacro) } else { Ok(Attribute::Normal(attr)) } }) .collect::<Result<Vec<_>>>()?, fun: input.parse()?, }) } } </code></pre> So for the following Rust source code: #[parameterized( red = { FunctionColor::Red }, blue = { FunctionColor::Blue }, )] #[test_macro(function_color::test_macro)] #[should_panic] fn test(color: FunctionColor) { // ... } </code></pre> We end up with 1 test_macro attribute and 1 "normal" attribute (i.e. not test_macro): vec![ Attribute::TestMacro(syn::Meta::parse("test_macro(function_color::test_macro)")), // hypothetically, if a &str would be a syn::ParseStream Attribute::Normal(syn::Attribute::parse("#[should_panic]")), ]; </code></pre> In the code generation phase, we can obtain these separately from TestFn</code>: impl TestFn { pub fn attributes(&self) -> Vec<syn::Attribute> { self .attributes .iter() .filter_map(Attribute::to_normal) .collect() } pub fn test_macro_attribute(&self) -> syn::Meta { self.attributes .iter() .find_map(Attribute::to_test_macro) // NB: We elsewhere asserted that there's at most one of these. .unwrap_or_else(|| { // A definition for the default #[test] macro syn::Meta::Path(syn::Path::from(syn::Ident::new( "test", proc_macro2::Span::call_site(), ))) }) } } </code></pre> And finally during generation itself: impl TestCase { pub fn to_token_stream(&self, test_fn: &TestFn) -> Result<proc_macro2::TokenStream> { let test_meta = test_fn.test_macro_attribute(); let attributes = test_fn.attributes(); // Many other things omitted... Ok(quote::quote! { #[#test_meta] // <-- Our custom macro attribute, or #[test] if none was specified #(#attributes)* // <-- The "normal" attributes, reproduced #visibility #constness #asyncness #unsafety #abi fn #identifier() #return_type { #bindings #body } }) } } </code></pre> When the code generation phase of the macro has been completed, the parameterized test function will have been substituted by two separate test functions: #[function_color::test_macro] #[should_panic] fn red() { // ... } #[function_color::test_macro] #[should_panic] fn blue() { // ... } </code></pre> Gotchas to be aware of</h3> The #[test_macro(...)]</code> attribute must be placed after #[parameterized]</code> Like all macro's, yare::parameterized</code> can only parse the available scope. Since yare::parameterized</code> is supposed to be placed on top of functions, we can access our own attribute (which we use to parse the test case identifier and arguments for test cases) and the function underneath (used to specify the parameters and test scenario in the function body). While yare::parameterized</code> does have access to attributes placed after it, the ones which come before it, are inaccessible. Subsequently, yare::parameterized</code> can only recognize placements of #[test_macro(...)]</code> which come after it. So, the following is ok: use yare::parameterized; #[parameterized( wow = { "wow!" }, whew = { "whew!" }, )] #[test_macro(tokio::test)] async fn test(sample: &str) { // ... } </code></pre> While this doesn't work: use yare::parameterized; #[test_macro(tokio::test)] #[parameterized( wow = { "wow!" }, whew = { "whew!" }, )] async fn test(sample: &str) { // ... } </code></pre> One #[test_macro(...)]</code> per parameterized test function Yare currently accepts one #[test_macro(...)]</code> for a parameterized test function. The following is not allowed and will return an error: use yare::parameterized; #[parameterized( wow = { "wow!" }, whew = { "whew!" }, )] #[test_macro(tokio::test)] #[test_macro(tokio::test(start_paused = true))] async fn test(sample: &str) { // ... } </code></pre> Returned error: error: Expected at most 1 #[test_macro(...)] attribute, but 2 were given --> tests/fail/multiple_test_macro_attributes.rs:8:14 | 8 | #[test_macro(tokio::test(start_paused = true))] | ^^^^^ </code></pre> The reason is that it's unclear what should happen when multiple #[test_macro(...)]</code> attributes are present. Should the first one be used by #[parameterized(...)]</code>, and subsequent be left in place? Or would that just be confusing, if only because the test author will need to keep track of which macro uses which attributes. Renaming attributes Yare's parameterized attribute can be used with a different name if you would like, by rebinding the target import part under a local name: use yare::parameterized as test_macro_for_twitchcraft_and_lizardry; // <-- Rebinding! #[test_macro_for_twitchcraft_and_lizardry( <-- Usage gryffinroar = { "Gryffinroar" }, hufflefluff = { "Hufflefluff" }, ravenpaw = { "Ravenpaw" }, slytherfin = { "Slytherfin" }, )] fn houses(name: &str) { // ... } </code></pre> However, since the #[test_macro(...)]</code> is parsed by yare::parameterized</code>, it cannot be renamed. Extended function qualifier support</h2> Previously, when Yare was still written to support mostly just the built-in #[test]</code> macro, it wasn't so useful to support the function qualifiers: const</code>, async</code>, unsafe</code> and extern</code>. Firstly, because half of these aren't even supported by #[test]</code>. For the ones that are, namely const</code> and extern</code>, the I deemed the usefulness to be limited. For example: with const</code> you can't use the commonly used assert_eq!</code> since the PartialEq</code> trait is not marked as const</code>. And regarding extern</code>, I've never seen anyone call unit test functions over FFI (but if you do, I would like to know, it does sound fun 😅). However, with custom test macro's, you want at least support for async</code> and maybe for unsafe</code>. Adding the other two is hardly more work, so I also added const</code> and extern</code> for completeness. NB: when specifying one ore more qualifiers in the function definition of your test function, the underlying test macro (whether #[test]</code> or a custom macro #[test_macro(x)]</code>) must also support the specified qualifiers. Example use yare::parameterized; // NB: The underlying test macro also must support these qualifiers. For example, the default `#[test]` doesn't support async and unsafe. #[parameterized( purple = { &[128, 0, 128] }, orange = { &[255, 127, 0] }, )] const extern "C" fn has_reds(streamed_color: &[u8]) { assert!(streamed_color.first().is_some()); } </code></pre> Ideas, feedback and bug reports for Yare</h1> Ideas, feedback and bug reports are most welcome. Feel free to open an issue on GitHub</a>. Discuss this post</h1> Discuss on Reddit</a>. Using the todo! macro to prototype your API in Rust 2023-04-24T00:00:00+00:00 Let's sketch a situation. You're designing and implementing a library in Rust, for some great idea you had. And, you aim to create a seamless API that makes this library user-friendly not only for others, but also for yourself. One way to figure out the design of the library is to write a prototype, and write the bare minimum code to stub out the the initial API. I hear you think: Rust is not to most convenient prototyping language, because it's quite strict and verbose: we have to satisfy the borrow checker and, in many places, Rust requires you to explicitely type your code. And altough I believe both will help you design better code, I can also understand the argument that it reduces the prototyping velocity at least a bit. Luckily for us, the Rust standard library has a useful tool in its toolbox: the todo!</a> macro. Let's look at an example. Imagine1</a> we're re-designing a Rust API to fetch Rust releases metadata. We will first prototype a few data structures around the concept of "releases": /// A data structure consisting of the set of known Rust releases. /// /// Whether a release is known, and how much information is known /// about a release, depends on the source used to build up this /// information. struct RustReleases { // We divide all releases by platform, so we end up with the // set of available toolchains for each platform. registry: HashMap<rust_toolchain::Platform, ReleaseRecords>, } /// A set of releases, for a single platform. struct ReleaseRecords { releases: BTreeSet<Release>, } /// A single release. /// /// In this example, we define a release as a toolchain of a specific /// version (stable, beta) or date (nightly), and its associated /// components. struct Release { toolchain: rust_toolchain::Toolchain, /// Rustup has the concept of components and extensions. /// /// When installing a toolchain, components are installed by default, while extensions are optional components. /// In this implementation, they're combined. components: Vec<rust_toolchain::Component>, } </code></pre> Now, let's consider how we want to use the data captured by these data structures. For example, we may want to find the most recently released Rust release: impl ReleaseRecords { /// Find the most recent Rust release. /// /// Returns `None` if no release could be found. pub fn last_released(&self) -> Option<&Release> { todo!() } } </code></pre> See that todo!</code> macro 😃? Instead of providing an actual, or fake, implementation which needs to satisfy the return type of our method, we placed a todo!</code> macro in the body. This allows us to not worry about our implementation just yet, so we can focus on the design of our API instead. It also accepts the same arguments as panic!</a>, so the following will work as well: impl Release { pub fn release_date(&self) -> rust_toolchain::ReleaseDate { todo!("release date of the toolchain") } pub fn find_component(&self, name: &str) -> Option<rust_toolchain::Component> { todo!("find component with name: '{name}'") } } </code></pre> If we run the find_component</code> method, we'll find that it panics the thread, and shows the panic message we provided, prefixed with "not yet implemented": not yet implemented: find component with name: 'hello-world' thread 'tests::find_component' panicked at 'not yet implemented: find component with name: 'hello-world'', crates/rust-releases-core/src/lib.rs:77:9 stack backtrace: 0: std::panicking::begin_panic_handler at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579 1: <snip> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. </code></pre> Under the hood, todo!</code> is the same as panic!</code>, to which it defers its implementation, but with a clear change of semantics: this bit is not yet implemented, but we'll do so soon. Every rose has its thorn</h2> Let's expand our design and add a few more useful methods: impl Release { /// Returns an iterator over the components which are installed by default. pub fn components(&self) -> impl Iterator<Item = &rust_toolchain::Component> { todo!("components installed by default") } /// Returns an iterator over the components which are optional, /// and not installed by default. pub fn extensions(&self) -> impl Iterator<Item = &rust_toolchain::Component> { todo!("components not installed by default") } } </code></pre> In the above code we defined two methods on Release</code>, which both return an iterator of &rust_toolchain::Component</code> items. What happens if we try to compile the code above?: error[E0277]: `()` is not an iterator --> crates/rust-releases-core/src/lib.rs:80:33 | 80 | pub fn components(&self) -> impl Iterator<Item = &rust_toolchain::Component> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `()` is not an iterator | = help: the trait `Iterator` is not implemented for `()` </code></pre> 😢 It turns out</a>, there is an issue</a> where the compiler is unable to figure out what type to use for types which have the never type as their return type and use impl Trait</code> in return position. The todo!</code> macro falls in this category. There are several ways to work around the problem though. One option is to use dynamic dispatch and box: impl Release { pub fn extensions<'this>( &'this self, ) -> Box<dyn Iterator<Item = &'this rust_toolchain::Component> + 'this> { todo!("components not installed by default") } } </code></pre> Another is to return a simple concrete type: impl Release { pub fn extensions(&self) -> Vec<&rust_toolchain::Component> { todo!("components not installed by default") } } </code></pre> A third is to use the explicit type in the return type, but this requires you to think ahead on which iterator type you will be using, which you probably don't want to worry about (especially if you will be using impl Iterator</code> on implementation). A fourth would be to implement Iterator</code> for a concrete type, but this also adds a lot of boilerplate. A fifth</a> was suggested by natalialt. I like this one very much, because it is short and to the point (altough also not universably applicable to any impl Trait</code> return type). This solution returns an iterator via the std::iter::once()</code> function: use std::iter; impl Release { pub fn extensions(&self) -> impl Iterator<Item = &rust_toolchain::Component> { iter::once(todo!("components not installed by default")) } } </code></pre> The reason that this works, is because std::iter::once</code> returns a valid iterator, namely Once</a>, which makes the return type satisfiable. Where the never type !</code> didn't implement Iterator</code>, Once</code> does. Taking it to the next level</h2> So far, we saw that todo!</code> can be a powerful prototyping tool. If we want to take it to the next level, we should start making use of Rust's type checking capabilities for the composition and usage of our API. This helps us be much more confident throughout designing of the library. As shown before, the compiler knows that we do not need to satisfy our return types (within the method body). However, the return type of these methods will still be checked wherever we use these methods. This allows us to not only define the new API, while leaving the implementation for later but also write some code on how to use it. This can be particularly useful to explore whether an API is easy to use as a caller. I like to do this by writing unit tests for my API. If your API is painful to use, you're much more likely to find this out if you had to write a usage example yourself. Plus, this way you also already have a first test in place. Example: #[test] fn find_component_returns_none_if_release_has_no_components() { let channel = rust_toolchain::Channel::Nightly; let release_date = rust_toolchain::ReleaseDate::new(2023, 1, 1); let platform = rust_toolchain::Platform::host(); let version = None; let toolchain = rust_toolchain::Toolchain::new(channel, release_date, platform, version); let release = Release::new(toolchain, vec![]); let component = release.find_component("hello"); assert!(component.is_none()); } </code></pre> And if we were not yet sure how to construct an input for our function under test, we can also use the todo!</code> macro here: #[test] fn find_component_returns_none_if_release_has_no_components() { // We can use todo!() here too! // // We may not be sure yet how to construct our input. // Let's take the design of the API, one step at a time. let toolchain = todo!(); // The code below will be unreachable though! let release = Release::new(toolchain, vec![]); let component = release.find_component("hello"); assert!(component.is_none()); } </code></pre> Alternatively, instead of writing inline unit tests, you could also use doctests</a> for this purpose: impl Release { /// Find a component by its name. /// /// If the component does not exist for this `Release`, /// returns `Option::None`. /// /// # Example /// /// ```rust /// use rust_releases_core::Release; /// /// let channel = rust_toolchain::Channel::Nightly; /// let release_date = rust_toolchain::ReleaseDate::new(2023, 1, 1); /// let platform = rust_toolchain::Platform::host(); /// let version = None; /// /// let toolchain = rust_toolchain::Toolchain::new(channel, release_date, platform, version); /// /// let release = Release::new(toolchain, vec![]); /// let component = release.find_component("hello"); /// /// assert!(component.is_none()); /// ``` pub fn find_component(&self, name: &str) -> Option<&rust_toolchain::Component> { todo!("find component with name: '{name}'") } } </code></pre> Implementation time!</h2> Once we are satisfied with the basic structure of our API, we can gradually replace each todo!</code> macro with an actual implementation. We do not have to replace all the macros simultaneously, so we can focus on one implementation step at a time. Developing a well-designed API requires careful planning and attention to detail. Taking the time to establish a solid foundation will pay off in the long run, as it will result in more user-friendly and reliably designed API. Footnotes</h1> ^{1 I'm currently working on the next version of}rust-releases</a>. Thanks!</h1> Special thanks to Chris Langhout, Jean de Leeuw and Martijn Steenbergen for proofreading my blog post; any mistakes are solely mine. Also many thanks to proudHaskeller on Reddit</a> for reporting an issue I missed: the type signature I initially used to deal with the todo!</code> and impl Trait</code> would never type check with a concrete implementation (this has been addressed), and to natalialt on Reddit</a> for suggesting a useful workaround to the same issue when the return type is impl Iterator</code>, by using iter::once(todo!())</code>. Discuss</h1> Discussions and feedback are most welcome! Discuss on Reddit</a>, HackerNews</a> or create an issue</a>.

The good parts</h2>

Global music library</h3>
Spotify is pretty great in this regard. It has an almost perfect library. Songs are rarely removed, unlike for example film centric platforms. Songs are also usually available worldwide, and not as much fenced by region (afaik), unlike say e-book or audiobook platforms.</p>

Audio quality</h3>
Disclaimer: I'm not an audiophile. I've been streaming Spotify on "Very high" and more recently sometimes on "Lossless" too; I've can't complain about the quality. It's good.</p>

Pain points</h2>

0.18.5 - 2025-04-19</h2>

Also good: This version number has no link</li> </ul>

Call to action</h1>
So next time you write a changelog, please keep these digital tumbleweeds out. Complete your links, fix your [brackets]!</p>

Call to action</h1>
So next time you write a changelog, please keep these digital tumbleweeds out. Complete your links, fix your [brackets]!</p>

`The changelog</h3>The complete changelog can be found here</a>.</p> Thanks!</h2> Thanks to all contributors, whether you submitted a PR</a> or reported an issue</a>, or contributed in some other way.</p> Some of your issues and PR's really made my day! 💛</p>`

Thanks!</h2>
Thanks to all contributors, whether you submitted a PR</a> or reported an issue</a>, or contributed in some other way.</p>
Some of your issues and PR's really made my day! 💛</p>

Remarks on using Clap</h1>
In this likely non-standard use case.</em></p>

`Thanks!</h1>This post is based on an issue</a> originally reported by Finomnis</a> , thanks!</p>`

Feedback & discussion</h1> Feedback is most welcome. Feel free to discuss at GitHub</a>.</p>

Ideas, feedback and bug reports for Yare</h1>
Ideas, feedback and bug reports are most welcome. Feel free to open an issue on GitHub</a>.</p>

Discuss this post</h1>
Discuss on Reddit</a>.</p>

`Discuss</h1> Discussions and feedback are most welcome! Discuss on Reddit</a>, HackerNews</a> or create an issue</a>.</p>`

Don't panic, impl Things

The Middle Ground

Notes on AI and empowerment

The Value of Things

How I use Spotify

Github's malicious notification problem

Where are the security advisories of the recently compromised NPM packages?

Grammar checking from the CLI with Harper

Thank you all for 10 years of (stable) Rust

Accessibility and Rust podcast at RustWeek

Orphaned markdown [brackets]

A sneak peek Into:: (slide deck, 2022)

A few cargo-msrv 0.16 release highlights

Puzzle: Sharing declarative args between top level and subcommand using Clap

A tale of setInterval and useEffect in React Native

What's new in Yare 3.0.0 (A lean parameterized testing macro for Rust)

Using the todo! macro to prototype your API in Rust

Don't panic, impl Things

The Middle Ground

Notes on AI and empowerment

The Value of Things

How I use Spotify

The good parts</h2>

Audio quality</h3> Disclaimer: I'm not an audiophile. I've been streaming Spotify on "Very high" and more recently sometimes on "Lossless" too; I've can't complain about the quality. It's good.</p>

Pain points</h2>

Github's malicious notification problem

Where are the security advisories of the recently compromised NPM packages?

Grammar checking from the CLI with Harper

Thank you all for 10 years of (stable) Rust

Accessibility and Rust podcast at RustWeek

Orphaned markdown [brackets]

[0.18.3] - 2025-04-19</h2> Lost: references to version numbers</li> </ul>

0.18.4</a> - 2025-04-19</h2> Found: references to version numbers</li> </ul>

0.18.5 - 2025-04-19</h2> Also good: This version number has no link</li> </ul> Call to action</h1> So next time you write a changelog, please keep these digital tumbleweeds out. Complete your links, fix your [brackets]!</p>

Call to action</h1> So next time you write a changelog, please keep these digital tumbleweeds out. Complete your links, fix your [brackets]!</p>

A sneak peek Into:: (slide deck, 2022)

A few cargo-msrv 0.16 release highlights

Puzzle: Sharing declarative args between top level and subcommand using Clap

Idea 2: naming a command</h1> If we could name one of these derived commands, then we might get away with saying to clap</code>: "the fields within this named command are incompatible with the fields in this other named command"; i.e. I'm trying to apply some constraint.</p>

Remarks on using Clap</h1> In this likely non-standard use case.</em></p>

A tale of setInterval and useEffect in React Native

What's new in Yare 3.0.0 (A lean parameterized testing macro for Rust)

How does it work?</h3> To make this work, the #[parameterized(...)]</code> attribute in Yare parses all attributes placed after it (all attributes must be placed on top of the test function):</p>

Ideas, feedback and bug reports for Yare</h1> Ideas, feedback and bug reports are most welcome. Feel free to open an issue on GitHub</a>.</p>

Using the todo! macro to prototype your API in Rust

Audio quality</h3>
Disclaimer: I'm not an audiophile. I've been streaming Spotify on "Very high" and more recently sometimes on "Lossless" too; I've can't complain about the quality. It's good.</p>

0.18.5 - 2025-04-19</h2>

Also good: This version number has no link</li> </ul>

Call to action</h1>
So next time you write a changelog, please keep these digital tumbleweeds out. Complete your links, fix your [brackets]!</p>

Call to action</h1>
So next time you write a changelog, please keep these digital tumbleweeds out. Complete your links, fix your [brackets]!</p>

Remarks on using Clap</h1>
In this likely non-standard use case.</em></p>

Ideas, feedback and bug reports for Yare</h1>
Ideas, feedback and bug reports are most welcome. Feel free to open an issue on GitHub</a>.</p>