The other day, someone on the Rust user forums posted a question that really nerd-sniped me. They had data generated by a C++ program and were wanting to load it into a Rust program, but when asked what format the data was in the author didn’t provide some something like a JSON schema or Protobuf file, instead they just got the definition for a C struct.
A common method for “serializing” data in C is to create a struct and directly write its bytes into a file, the “deserializing” is just a case of reading the data out of the file and interpreting it as your type. This technique is actually kinda genius when you think about it, it makes no intermediate copies or heap allocations because the OS’s
read()function will literally write your data to its destination, and there are no extra dependencies or complicated serialization frameworks involved.
I’m not going to go into this technique’s drawbacks (of which there are many… there is a reason we use things like JSON and Protocol Buffers nowadays, after all) and instead let’s just focus on how to read these sorts of files.
Google wants to see Rust programming language support within the Linux kernel so much so that they have contracted the lead developer working on “Rust for Linux” as the work aims to get mainlined.
Google is going public today with their formal support for Rust in the Linux kernel to enhance memory safety and that they have contracted developer Miguel Ojeda to further his work on Rust for the Linux kernel and related security efforts. This contract is going through at least the next year.
Besides attracting new developers and opening up new doors with Rust in the kernel, Google’s primary motivation with this public support and Miguel’s contract is centered around improving memory safety of the kernel.
This news though really shouldn’t be surprising. Following the RFC patch series for Rust in the kernel, Google did voice their support back then and earlier this year began allowing Rust for core Android development.
Google should have out a blog post shortly announcing their latest support around Rust for the Linux kernel.
This is the last part of the Learning to Fly series in which we’re coding a simulation of evolution using neural network and genetic algorithm:
Today, I’m writing about what types can be used for other than checking code properties. It will involve a good chunk of dynamic typing, and yes it’s in Rust. There are some wild ideas in it, so fasten your seatbelt and get ready for a ride!
Sizedness is lowkey one of the most important concepts to understand in Rust. It intersects a bunch of other language features in often subtle ways and only rears its ugly head in the form of “x doesn’t have size known at compile time” error messages which every Rustacean is all too familiar with. In this article we’ll explore all flavors of sizedness from sized types, to unsized types, to zero-sized types while examining their use-cases, benefits, pain points, and workarounds.
One of the main challenges of evaluating Rust for use within the Android platform was ensuring we could provide sufficient interoperability with our existing codebase. If Rust is to meet its goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. To accomplish this, we need to provide the majority of functionality platform developers use. As we discussed previously, we have too much C++ to consider ignoring it, rewriting all of it is infeasible, and rewriting older code would likely be counterproductive as the bugs in that code have largely been fixed. This means interoperability is the most practical way forward.
Before introducing Rust into the Android Open Source Project (AOSP), we needed to demonstrate that Rust interoperability with C and C++ is sufficient for practical, convenient, and safe use within Android. Adding a new language has costs; we needed to demonstrate that Rust would be able to scale across the codebase and meet its potential in order to justify those costs. This post will cover the analysis we did more than a year ago while we evaluated Rust for use in Android. We also present a follow-up analysis with some insights into how the original analysis has held up as Android projects have adopted Rust.
Two particularly useful enums are
Resultgives you a way to represent whether an operation is successful or not, as well as a way to access the data or error of the… result. 👀
Optiongives you a way to represent whether something exists or not. This is generally used as a replacement for nullable types (which Rust does not have*).
But what really makes Rust shine is that it forces you to explicitly handle enum variants before you can access the underlying data. This is done using the
matchkeyword. Rust also has special syntax for handling Results and Options when you raise issues from the unhappy path.
To start, let’s compare how we handle a simple http endpoint with Go’s
One big selling points of Rust is zero-cost abstractions. So using zero-cost abstractions arguably makes Rust code more idiomatic. The binary search implementation presented in the original offers some potential into that direction.
Binary search also may optionally provide the position where an element would fit, if it were to be inserted.
In this post I want to explore some of these possibilities.
Rust’s adoption is at an all-time high: more and more companies are trying it out and hiring for it.
If you are interested in building APIs with Rust, Zero To Production is the ideal starting point for your Rust journey.
You will learn by doing: we will start from scratch and build together, step by step, a fully functional email newsletter backend API.
You’ll learn how to:
Navigate and leverage Rust’s crates ecosystem
Structure your application to make it modular and extensible
Write tests, from single units to full-blown integration tests
Model your domain using the type system to enforce invariants
Collect logs, traces and metrics to observe the state of your application
Set up a robust continuous integration and continuous deployment pipeline for your Rust projects
All code comes attached to the book, tests included.
It all started with an informal chat with my friend Anthony. We were talking about languages, and I said that I preferred compiled ones. He then went on to mention Rust. We admitted that we were too afraid to learn it because of its perceived complexity.
After the chat, I thought about it, and I wondered why I didn’t check by myself. I did. And I became interested.
There are tons of resources on the Web on how to learn Rust. This post is a memo of the steps I followed. It’s probably less structured than my other posts but I hope you might benefit from those notes anyway.
Have you ever wanted to write a structurally typed function in Rust? Do you spend a lot of time and effort getting your Rust
structs just so, and want to DRY-out data access for common field paths without declaring a new
traitand implementing it for each struct (let’s say,
Dogboth have a
name: Stringfield)? If so, read on.
This post talks about how we can leverage
Pathtraversers (functionally similar to lenses), and use them to write clean and performant structurally typed functions with all the compile-time safety that you’ve come to expect from Rust.
Recently I tweeted:
Once again I am being tempted to try out Rust, despite a relatively high confidence that I’m going to not like it. It’s the wave of the future, though. Sooner or later I’m going to have to read and hack on Rust code.
More than five years ago, I wrote an entry on my feelings on using on Rust myself which I have since summarized to people as ‘Rust cares about things that I don’t any more’. I understand that Rust has much better ergonomics than it did in 2015 (when Rust 1.0 was just out), and so some of my other issues might be better.
But that’s not why Rust is a wave of the future (in the manner of tweets, I said ‘the wave’). Rust is a wave of the future because a lot of people are fond of it and they are writing more and more things in Rust, and some of these things are things that matter to plenty of people. There’s Rust in your Python cryptography. There’s Rust in Curl (sort of) (also). There’s Rust in your librsvg. There’s a lot of Rust in your Firefox. There are a growing number of command line tools written in Rust, including the excellent ripgrep. Someday there will probably be Rust in the Linux kernel. All of this is only growing with time, especially in the open source world.
All of this means that dealing with Rust is going to become increasingly necessary for me and a lot of people. We may not write it, but we need to be able to deal with programs that use it and are written in it. Our systems increasingly need a Rust build environment, I recently explored Rustup, and sooner or later I’m going to have to read and perhaps change Rust code in order to understand some problem we’re having and perhaps fix it. Learning how to write some Rust myself is one way of getting the experience and knowledge necessary to do that well.
By the way, this isn’t some nefarious conspiracy to force Rust on everyone. Some of it is that Rust really does solve problems that people have, but as I mentioned, a larger part of it is that lots of people genuinely like writing in Rust. When people like a programming language, things get written in that language and some of them become widely used or popular (or both). We saw this with Go in certain areas, and we’re seeing this with Rust.
We last left off writing a graphics driver and an event driver for our operating system. We also added several system calls to handle drawing primitives as well as handling keyboard and mouse inputs. We are now going to use those to animate the simple game of pong. Just like hello world is the test of every programming language, pong is a test of all of our graphics and event systems.
Over the past several weeks I have been attempting to reimplement the API of an existing python library as a wrapper for an equivalent library in Rust.
tl;dr: this ended up being much harder than I expected it to be, partly because of important differences in the behaviour of the two languages, and partly because of the (self-imposed) obligation to match an existing (idiomatic) python API.
You may not know this, but it’s possible to give names to your lifetimes which are longer than a single character! Effectively naming your lifetimes can help improve code clarity in several scenarios, which this post describes in detail.