Bluesky has added a new feature that lets you hide reposts from a specific person in your feeds. The tool might be helpful if you want to stop seeing reposts from that one person who clogs up your feed with reposts of things you don't care about. If you follow me, I may be that person, I'm sorry. I try not to be.

You can hide reposts from individual users by going to their profile, clicking the three dots button, and selecting the option to "Hide reposts in feeds." (X offers a similar toggle.)

Bluesky also says that it's launching a beta feature that will automatically add post numbers to threads. For long threads, it could be a useful w …

Read the full story at The Verge.

Linus Torvalds released Linux 7.2-rc7 on August 9, 2026, and the seventh release candidate arrived far heavier than the kernel project usually sees one week before a stable debut. The build carries more than 400 fixes signed by over 230 contributors, a volume Torvalds attributes to AI and large language model tools that now scan kernel code continuously and surface bugs human reviewers missed or deprioritized for years. "I can't say that I'm exactly thrilled about the size of this all," Torvalds wrote in his announcement on the Linux Kernel Mailing List, describing the volume as the new normal, with… [Continue Reading]

AI power demand is surging, but the grid problem emerging in US data is more local and complicated than a nationwide electricity shortage.

The post Will AI Data Centers Overwhelm the Power Grid? What US Grid Data Shows appeared first on TechRepublic.

The Gates Foundation broke its own record at the University of Washington with the largest charitable gift in university history: $540.2 million for the Institute for Health Metrics and Evaluation.

The commitment, announced Monday, will fund a 10-year expansion of IHME’s Global Burden of Disease study, increasing the number of locations it covers from about 925 to nearly 5,000. For many countries, the study is the only source of comparable data on causes of death and disease, according to IHME.

It will also support the institute’s health forecasting and its tracking of health spending worldwide.

The funding “will allow us to provide high-quality evidence at a much more local level and help leaders understand not only where health is improving or worsening, but which decisions can make the greatest difference for people,” said Dr. Christopher Murray, IHME’s director and a professor of health metrics sciences at UW, in a statement announcing the grant.

Roughly 60% of IHME’s budget comes from the Gates Foundation, according to the institute. The rest comes from federal grants, projects with other countries and other philanthropies.

IHME describes the new commitment from the Gates Foundation as a core grant that keeps the institute at a “steady state.” The previous core grant, $279 million announced in 2017, ramps down in December, and the new one begins in January.

IHME employed 425 people in fiscal 2026, down from 469 the year before, the institute said. No significant additional hiring is planned.

The institute became widely known during the COVID-19 pandemic, when its projections of cases, hospitalizations and deaths were used by the White House coronavirus task force and cited around the world. It drew criticism from statisticians who said its early forecasts understated the U.S. death toll and that its uncertainty ranges were too narrow, prompting revisions by IHME.

The Gates Foundation helped create IHME at UW in 2007 with a $105 million grant, then the largest in UW history. It has repeatedly set UW’s donation record since then, including $210 million in 2016 for the building that now houses the institute and $279 million to IHME in 2017.

The latest grant comes as global health funding falls sharply. IHME’s own tracking found that development assistance for health dropped 21% between 2024 and 2025, driven by a 67% decline in U.S. spending. Britain, France and Germany also cut their contributions.

It also comes at a tough moment for UW, which is facing a budget crisis driven by funding cuts. KUOW reported in April that NIH award money promised to UW dropped 50% from fiscal 2025 to fiscal 2026, with funds in hand down 74% because of slow federal grant processing.

The foundation is going through a transition of its own. It announced in May 2025 that it would spend $200 billion over 20 years and close on Dec. 31, 2045. Its board approved a record $9 billion budget for 2026 and a plan to cut up to 500 of its roughly 2,375 staff positions by 2030.

The new grant will run into 2036, about a decade before the foundation closes.

Updated after publication with additional information from IHME.

On the most recent episode of Zero to Agent in 30 Minutes, Vicki Reyzelman, senior solutions engineer at Akamai Technologies, drew on more than 25 years in technology and a background in software engineering to build an agent for her Chat About AI YouTube channel.

Vicki wanted the agent to monitor channel performance, identify bottlenecks, and recommend ways to grow subscribers and improve click-through rates. She defined the requirements, designed the workflow, built the agent, tested it, and revised the instructions following the same iterative process used in software development.

How to build a YouTube analytics agent, step by step

1. Define the goal.
   Start with the problem the agent should solve. Vicki wants to understand which videos perform well, where channel performance falls short, and what actions could help more viewers discover and subscribe to the channel.
2. Review the available data.
   Examine each source before designing the workflow. YouTube Studio exports include metrics such as impressions and click-through rates. The YouTube Data API provides information about channels, subscriptions, comments, and activity, but it doesn’t include every metric available through YouTube Studio.
3. Choose how the agent will receive the data.
   Vicki downloads her analytics as CSV files instead of connecting the agent directly to her account. This gives her more control while she tests the workflow. She notes that she could add an authenticated API connection later, after testing the agent’s permissions and guardrails.
4. Write the skills file.
   The skills file defines the agent’s mission, capabilities, data sources, rules, and expected output. Vicki instructs the agent to audit channel metrics, identify bottlenecks, compare performance over time, and recommend actions tied to subscriber growth and click-through rates.
5. Add guardrails and acceptance criteria.
   Tell the agent how to handle the data and what it must avoid. Vicki directs it to use only the supplied numbers, ignore bot activity, report silent failures, and stay within approved systems and data sources. These instructions help prevent unsupported conclusions and actions outside the agent’s assigned role.
6. Build and test the agent.
   Vicki uses the console’s quick-start process to create the agent, add its instructions and sample analytics, select an environment, and start a session. Her first test encounters input problems, so she stops the session, adjusts the data, and runs it again.
7. Monitor cost and performance.
   Observability tools show token consumption, errors, active time, and deployments. Vicki explains that more capable models may need less context but usually cost more to run. Teams can balance model capability against token cost by improving their instructions, selecting less expensive models for simpler work, or dividing a workflow among specialized agents.

Vicki recommends revisiting the skills file as new requirements emerge. Clearer instructions, stronger guardrails, and regular testing help the agent continue to produce useful results. Her process reinforces a practical software engineering lesson: Faster implementation doesn’t reduce the need for clear requirements, reliable data, security controls, and testing.

Coming next week

Join us for the next episode on August 12, when AI and machine learning leader Ofer Mendelevitch will explain how to design multi-agent systems that can keep work moving without constant human involvement. He’ll use Jam to build a team of agents that can plan, divide work, execute tasks, review progress, escalate problems, and repeat the process. He’ll show how an architect agent can take a project brief, recruit developer agents, assign work, and guide the project toward a clear definition of done.

This is a guest post by Mateusz Maćkowski and Marek Grzelak, co-maintainers of cot.rs and speakers at Rustikon 2026. You can watch the full talk here.

RIIR. If you’ve spent any time in open source communities, you’ve seen it. Someone opens an issue on a C or C++ project and suggests rewriting in Rust for memory safety and performance. Sometimes it’s a serious proposal. Sometimes it’s a meme. In 2026, it’s honestly a bit of both.

We wanted to find out which one it really is. Not in theory, but by looking at what actually happened when people did it. The wins, the performance numbers, the projects that were abandoned three years in, and the CVEs that showed up in freshly written Rust code. We’ve been in this ecosystem long enough to have seen all of it, and this blog post, based on our talk on Rustikon 2026, was our attempt to give it an honest look. 

TL;DR

• RIIR can deliver real performance and safety gains, but not automatically. Some projects are faster because of Rust, some just because they were rewritten from scratch.
• Rewrites introduce new bugs. Even well-funded teams with experienced engineers make mistakes.
• Not every rewrite succeeds. Prisma, Loglog Games, and the curl/hyper integration all hit walls for different reasons.
• Binary size, platform support, and interoperability with other languages are real practical challenges.
• The best approach is almost always to expand incrementally rather than rewrite everything at once.
• Rust in the Linux kernel and Windows is arguably the biggest validation the RIIR movement has ever had.

What is RIIR? Why did it take off?

RIIR stands for Rewrite It In Rust. The phrase started appearing in issue trackers on C and C++ projects as a way to suggest migration to a memory-safe, performant alternative. According to Google Trends, the “rewrite rust” term started climbing significantly around 2022, which we think aligns roughly with the Rust 2021 edition release, though a lot happened around that time, and we wouldn’t claim to know for certain.

The reasons people reach for Rust when considering a rewrite come down to three things: 

1. Memory safety
2. Performance
3. Fearless concurrency

On memory safety, the Android team’s data is hard to argue with. After Android began transitioning new development to memory-safe languages, the velocity of Rust code in the codebase steadily increased. The data shows a clear linear correlation: as the velocity of memory-unsafe code decreases, so does the number of memory safety vulnerabilities.

In terms of performance, a 2017 paper comparing energy efficiency, execution time, and memory usage across programming languages ranked Rust near the top for both energy efficiency and execution speed. The methodology is not perfect, and direct comparisons between languages are difficult, but the results still point to a broader trend: Rust performs competitively on both speed and efficiency. Memory usage was higher than the absolute best performers, but still within the upper half of the comparison.

And then there’s the Stack Overflow Developer Survey. Rust has been the most admired language for years running. A lot of RIIR projects probably exist simply because developers want to write Rust. That’s worth being honest about.

Three types of rewrites

Not all rewrites are the same, and it helps to be specific about what category you’re talking about. Here we have three categories. 

Drop-in replacements aim to be functionally identical to the original. You replace the binary and nothing else changes. Projects like uutils coreutils, sudo-rs, youki as a container runtime replacement, and Arti as a Tor reimplementation all fall under this. There are thousands of these across the ecosystem, ranging from small file format libraries like the PNG crate replacing libpng, to larger infrastructure projects with serious corporate and community funding behind them.

Alternatives solve the same problem but make different choices. ripgrep instead of grep, delta instead of diff, bat instead of cat, Typst instead of LaTeX, Polars instead of pandas. These aren’t trying to be identical replacements. They’re often faster, more ergonomic, or designed with a different philosophy. Typst is a good example of the readability argument:

LaTeX and Typst can produce the same output, but the source code tells a very different story. And on raw performance, Marek ran both ripgrep and grep against a 37 GB cargo target directory searching for the word “cot”. grep finished in 52 seconds. ripgrep finished in six. That’s not a marginal difference.

Self-rewrites are when an existing project decides to rewrite part or all of itself in Rust, without replacing an external binary. Firefox, the Linux kernel, Windows, Cloudflare’s infrastructure, and the Fish shell all belong here. These are not small bets. Some of the most widely deployed software in the world now contains Rust, and it got there through this category.

Rust rewrite performance: Does it actually deliver?

Sometimes, yes. Sometimes for the wrong reasons. Looking at uutils, sort runs almost four times faster than GNU sort. The reason is parallel merge sort, which Rust’s concurrency model makes considerably easier to implement correctly. But some other utilities are faster simply because they’re a fresh rewrite with 30 years of hindsight. The original project couldn’t experiment as freely because production users depended on it.

The PNG crate is a better example of Rust-specific gains. The Rust implementation is nearly twice as fast as libpng. Part of this comes from auto-vectorization: the Rust compiler generates SIMD instructions automatically from a regular for loop, while most C implementations require hand-written SIMD. The other part comes from streaming DEFLATE decompression, which fits more data into the CPU cache at once. Both are genuine Rust advantages.

Rust binary size: The problem and how projects solve it

Rust binaries are famously large, and the reasons are real: panic handling code, Debug trait implementations, the standard library compiled into each binary, monomorphization from generics, and static linking of all dependencies.

uutils dealt with this through a multicall binary format, the same approach used by BusyBox. All utilities are compiled into one binary and invoked through symlinks. The result: 73 MB of individual binaries becomes 13.8 MB as a multicall binary, which actually beats the 18.4 MB of the GNU coreutils standard install. Compressed with UPX, it gets down to 5 MB.

The problem is solvable, but it requires serious effort.

Rewriting in Rust: What can go wrong and why?

This part doesn’t get talked about enough. Every rewrite introduces new bugs. You’re writing code from scratch, which means you’ll inevitably introduce new bugs or regressions not found in the original project. This isn’t a Rust problem specifically; it’s a software rewrite problem. But it’s worth being clear-eyed about.

Cloudflare introduced an unwrap in a request-scoring component. uutils formatted dates slightly incorrectly, breaking unattended upgrades. sudo-rs echoed a partially typed password back to the terminal after a timeout. The first CVE in Rust code in the Linux kernel came from a race condition in an unsafe block in the Android binder driver. TARmageddon was an RCE vulnerability in async-tar caused by incorrect parsing of the .tar format.

If projects backed by significant funding and experienced teams still make these mistakes, we will too. That’s not a reason not to rewrite, but it is a reason to take testing seriously.

Sometimes, Rust isn’t even the right choice at all. Microsoft chose Go for the TypeScript compiler rewrite largely because Go is much closer to TypeScript in its programming model, which mattered while the codebase would contain both languages for quite some time. The NTPsec project chose Go because, at the time, Go had better network primitives and a less fragmented ecosystem. These were reasonable decisions, not failures of imagination.

And some rewrites that chose Rust still didn’t succeed. Prisma migrated away from their Rust query engine back to TypeScript due to skill-set gaps, deployment complexity, and runtime issues. Loglog Games abandoned Rust after three years of game development. They found it excellent for refactoring but poor for iteration speed, and noted that the Rust game development community focuses more on engine technicalities than on shipping finished games. The curl/hyper integration got to 95% completion and was then abandoned due to the difficulty of the last 5% and the lack of community momentum. Interestingly, the collaboration still benefited both projects: the process of trying to integrate them led to forced cleanups in both codebases.

Licensing is a real decision

One thing that doesn’t get discussed enough in RIIR conversations is that if you’re creating a new project that reimplements an existing one, your license choice has consequences.

A more restrictive license, like GPL, may exclude users who can’t introduce copyleft dependencies into proprietary projects. A more permissive license may draw criticism from the open source community, as some fear companies will use the code without contributing back. There’s no universally correct answer. It depends entirely on your project’s goals and community. But it’s a decision worth making consciously rather than by default.

Is the RIIR movement still happening in 2026?

The RIIR meme has faded somewhat. But the actual movement hasn’t. Rust in the Linux kernel is no longer experimental, and the maintainers declared the experiment a success at the 2025 Maintainers Summit. Rust is running in the Windows kernel. Cloudflare, Firefox, and countless infrastructure projects have committed significant Rust code to production.

The scale is real. Between Linux and Windows alone, Rust is running on billions of devices. That’s arguably the biggest validation the “rewrite it in Rust” idea has ever received.

How to actually do it well

If you’re considering a rewrite, a few things we’d recommend thinking through first. Make sure it actually makes sense for your use case. Ask whether your codebase is in a memory-unsafe language, whether it’s critical software, whether you have real performance and reliability requirements, and whether you have significant parallel or concurrent code that’s hard to reason about. The more of those boxes you check, the stronger the case.

Make sure your team is ready. Either they already know Rust, or they’re genuinely willing to learn and contribute to it. Google’s data suggests that around two-thirds of developers feel confident contributing to a Rust codebase within two months. But that’s not a guarantee, and the last 5% of a rewrite is almost always harder than you expect. Small rewrites take months. Medium ones take one to two years, and large rewrites take two to five. It almost always takes longer than you estimated.

Prefer expanding incrementally over rewriting completely. Adding new components in Rust while keeping the old codebase running is almost always less risky than a full replacement. You get the benefits without betting the whole project on it.

When you do rewrite, build a serious test suite. The best example of this in practice is uutils, which runs against the official GNU coreutils test suite to track parity. As of early 2026, they’re at 92.2% pass rate and climbing.

So is it worth it?

If your project is written in a memory-unsafe language, handles critical functionality, has real performance requirements, and involves substantial concurrent code, yes. A rewrite is strongly justified, and the evidence supports it.

Outside of those conditions, it’s still potentially worth it, but the analysis needs to be more careful. The enthusiasm is understandable as Rust is genuinely good. But it was designed as a systems programming language, and that’s where it does its best work. Treating RIIR as a default answer to every performance or safety concern is how you end up with a two-year rewrite project that ships six months late and introduces bugs you already fixed.

Frequently Asked Questions

What does RIIR mean?
RIIR stands for Rewrite It In Rust. It started as a suggestion in open-source issue trackers to migrate C and C++ projects to Rust for memory safety and performance, and became a broader cultural meme in the Rust community.

Is rewriting software in Rust worth it?
It depends on your situation. If your codebase is in a memory-unsafe language, handles critical functionality, and has real performance or concurrency requirements, the case for a Rust rewrite is strong. In other situations, the benefits are less clear, and the costs, but the learning curve, rewrite time, and new bugs deserve serious consideration.

What are the risks of rewriting in Rust?
Every rewrite introduces new bugs, including bugs the original project already fixed. Rust rewrites also require developers to learn the language, can take significantly longer than estimated, and may face challenges with platform support, binary size, and interoperability with other languages.

What is the best approach to migrating to Rust?
Incremental expansion rather than full rewrite. Add new components in Rust while keeping existing code running. When you do rewrite, invest in a thorough test suite that validates the new implementation behaves identically to the original.

Did Rust succeed in the Linux kernel?
Yes. At the 2025 Linux Kernel Maintainers Summit, the consensus was that the Rust experiment was a success. Rust is now a core part of the kernel and is no longer considered experimental.