This is a copy of our weekly Rust email newsletter.

If you’d like to receive these emails in your inbox, you can subscribe on Substack.

Meanwhile, you can read the article through the link down below

🦀 Systemd Finally Lets Rust In

🦀 Systemd Finally Lets Rust In was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reading the Linux 6.14 progress report from the Asahi team feels like watching a group of engineers finally get room to breathe after years of carrying an entire platform on their backs.

The numbers alone tell the story: more than ninety thousand lines added across twelve hundred and fifty patches, plus the usual constellation of downstream forks for U-Boot, Mesa, virglrenderer, and Flatpak.

That is a full-time job that never ends, especially when every upstream Rust abstraction merge forces another painful rebase.

What stands out is the deliberate shift in priorities.

After the administrative dust settled from the leadership change, the team put the glamorous work on hold and focused on the unglamorous necessity of getting code accepted upstream.

The ISP driver, the Touchbar controllers, the TAS amplifier extensions, the steady stream of smaller fixes: these are the patches that actually reduce the maintenance tax.

Anyone who has maintained a long-lived out-of-tree driver knows exactly how corrosive that tax becomes.

Janne’s ongoing work keeping the patch set alive against an accelerating Rust abstraction cadence is the kind of thankless effort that decides whether a project survives or collapses under its own weight.

The microphone support is the part that feels most characteristically Asahi.

Reverse-engineering the Always-On Processor, writing a stub for the Secure Enclave, then building Triforce because three closely spaced PDM microphones are otherwise useless.

The story of wrestling with immature scientific libraries in Rust, dusting off high-school maths and university statistics, and ending up with something that actually works on the first try is pure engineering satisfaction.

It is the opposite of the polished demo. It is the messy, iterative reality of making hardware that was never designed for you behave like it belongs.

Community funding has changed the equation.

Buying the next Mac no longer means deciding between hardware and rent.

CI infrastructure that should have existed years ago is finally possible. The project can show up at conferences without financial stress.

That is the difference between a volunteer effort that burns people out and a sustainable effort that can keep shipping.

The real measure of progress is the shrinking delta between what Asahi carries and what the mainline kernel already contains.

Every accepted driver, every cleaned-up abstraction, every bit of maintenance load removed is a step toward the day when Asahi becomes just another set of well-supported Apple Silicon platforms instead of a heroic parallel tree.

That is the work that matters, and it is the work they are choosing to do first.

Reference:

Progress Report: Linux 6.14 - Asahi Linux

Asahi Linux’s Grind Toward the Mainline was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over five years ago, counting from this writing, I published my most successful article here on Medium. That article grew from the need to filter a particularly noisy sensor’s data from a telematics data stream. Concretely, it was a torque sensor connected to a truck’s drive shaft, and the noise needed to go. LOESS was the answer, hence that article.

LOESS

By then, I was neck-deep in Python, and the project required Spark, so implementing the algorithm in Python was a no-brainer. Times change, though, and now I use Rust more often, so I decided to translate the old code. This article describes the porting process and the choices I made when rewriting the code. You should read the original article and the reference material to learn more about the algorithm. Here, we will focus on the intricacies of writing matrix code in Rust, replacing the earlier NumPy implementation as closely as possible.

Rust Numerical Computing

As a firm believer in not reinventing the wheel, I searched for recommended Rust crates to replace NumPy in the original Python code, and it didn’t take long to find nalgebra.

nalgebra is meant to be a general-purpose, low-dimensional, linear algebra library, with an optimized set of tools for computer graphics and physics.

Although we will not do any physics or computer graphics, it fits the low dimensionality requirement like a glove.

Differences

When converting the Python code to Rust, I met some difficulties that took me a while to sort out. In Python, we use all the features the language and the library provide to improve the code’s expressiveness and readability. Rust is more verbose than Python, and, at the time of this writing (version 0.33.0), the nalgebra crate still misses some features that help improve its expressiveness. Terseness is a challenge.

My first hurdle was indexing arrays using other arrays. With NumPy, you can index an array using another array of integers or booleans. In the first case, each element of the indexing array indexes into the source array, and the indexer may have a dimension equal to or smaller than the data array. With boolean indexing, the indexer must have the same size as the data, and each element must indicate whether to include the corresponding data element. This feature is handy for selecting data with boolean expressions.

Handy as it is, I used this feature throughout the Python code:

# Python
xx = self.n_xx[min_range]

Here, the min_range variable in an integer array containing the subset of indices to retrieve from the self.n_xx array.

Try as I might, I couldn’t find a solution in the Rust crate that mimics NumPy indexing, so I had to implement one. After a couple of tries and benchmarks, I reached the final version. This solution was straightforward and effective.

// Rust
fn select_indices(values: &DVector<f64>,
                  indices: &DVector<usize>) -> DVector<f64> {
    indices.map(|i| values[i])
}

The map expression is quite simple, but using the function name is more expressive, so I replaced the Python code above with the corresponding Rust one:

// Rust
let xx = select_indices(&self.xx, min_range);

There is also no built-in method to create a vector from a range of integers. Although easy to do with nalgebra, the code becomes a bit long:

// Rust
range = DVector::<usize>::from_iterator(window, 0..window);

We can avoid much of this ceremony if we fix the vector and array sizes at compile time, but we have no such luck here because the dimensions are unknown. The corresponding Python code is more terse:

# Python
np.arange(0, window)

This terseness also extends to other areas, such as when filling a matrix row-wise. In Python, we can do something like this:

# Python
for i in range(1, degree + 1):
    xm[:, i] = np.power(self.n_xx[min_range], i)

As of this writing, I found no better way of doing the same thing with nalgebra than this:

// Rust
for i in 1..=degree {
    for j in 0..window {
        xm[(j, i)] = self.xx[min_range[j]].powi(i as i32);
    }
}

Maybe something hidden in the package is waiting to be discovered that will help here with conciseness.

Finally, I found the nalgebra documentation relatively sparse. We can expect that from a relatively young Rust crate with a lot of promise.

The Upside

The best comes at the end—the raw performance. I invite you to run both versions of the same code (GitHub repository links are below) and compare their performance. On my 2019 MacBook Pro 2.6 GHz 6-Core Intel Core i7, the release version of the Rust code runs in under 200 microseconds, while the Python code runs in under 5 milliseconds.

Conclusion

This project was another exciting and educational Python-to-Rust port of my old code. While converting from well-known Python control structures to Rust is getting more accessible by the day, converting NumPy to nalgebra was more of a challenge. The Rust package shows much promise but needs more documentation and online support. I would warmly welcome a more thorough user guide.

Rust is more ceremonious than Python but performs much better when properly used. I will keep using Python for daily work, prototyping, and discovery, but I will turn to Rust for performance and memory safety when moving to production. We can even mix and match both using crates like PyO3, so it is a win-win.

Rust rocks!

References

joaofig/loess-rs: An implementation of the LOESS / LOWESS algorithm in Rust. (github.com)

joaofig/pyloess: A simple implementation of the LOESS algorithm using numpy (github.com)

Credits

I used Grammarly to review the writing and accepted several of its rewriting suggestions.

JetBrains’ AI assistant helped me write some of the code, and I also used it to learn Rust. It has become a staple of my everyday work with both Rust and Python. Unfortunately, support for nalgebra is still limited.

João Paulo Figueira is a Data Scientist from Lisbon, Portugal.

LOESS in Rust was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have watched Discord sit on Electron for years while the rest of the industry complained about the memory and the process sprawl.

The announcement that the entire desktop client is moving to GPUI, with React Native going away on mobile as well, feels like one of those rare moments where a large product team actually follows through on the architecture they already half-built.

Discord has used Rust since 2018 for infrastructure and voice.

Parts of the current client already lived there. The CTO called the full client rewrite the holy grail.

That language is accurate. Electron was always a pragmatic choice for shipping features fast across platforms.

It also meant every Discord window carried a Chromium instance and the associated cost.

Early numbers from the Discord Phoenix build show roughly 290 MB for two concurrent accounts.

The old client could idle at a gigabyte or more and occasionally climb higher. That gap is the difference between a browser and a native GPU-rendered UI.

GPUI is the interesting part of the decision. It is not Tauri.

There is no system webview for the main interface. The framework renders directly, the same approach Zed uses.

Discord is carrying its own patches and has signaled willingness to upstream what makes sense.

That is the pragmatic engineering move: take a production-proven Rust UI layer, adapt it hard, and keep the door open for the original maintainers.

Mobile keeps native UI shells while sharing the core application logic through Rust. The result is one coherent codebase instead of three separate stacks fighting each other.

I am not naive about the risk.

Full client rewrites of applications this large rarely ship on the first schedule.

Accessibility, security, and the long tail of platform quirks will still demand attention. The team has said those concerns are treated with the same priority as performance. That statement matters more than the RAM numbers.

What I appreciate most is the honesty of the trajectory.

They started with Rust where it made sense, kept the pressure on the remaining Electron surface, and eventually decided the cost of staying was higher than the cost of finishing the migration.

Most companies stop at the first convenient layer. Discord is finishing the job.

When the new client reaches wider testing, the real test will be whether the feel stays identical while the resource profile finally matches a modern native application.

I expect it will. The foundation was already there.

Discord is finally rewriting the client in Rust with GPUI was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.