Languages like C and C++ are standardized. They are fully specified in an internationally recognized standards document. Languages like Python, Swift and Rust do not have such a standards document.

Should Rust be standardized? Why, or why not? In this blog post, I try to explain why I do think we need an accurate specification, why I do not think we need “standardization” (depending on your definition), and give an overview of the current state of Rust’s stability and specification efforts.

The concurrency features that are included in the Rust standard library are quite similar to what was available in C++11: threads, atomics, mutexes, condition variables, and so on. In the past few years, however, C++ has gained quite a few new concurrency related features as part C++17 and C++20, with more proposals still coming in for future versions.

Let’s take some time to review C++ concurrency features, discuss what their Rust equivalent could look like, and what it’d take to get there.

A few years ago, due to some random chain of events, I ended up implementing a conversion from 128 bit integers to 64 bit floats. This would’ve turned out to be a complete waste of time, except that my final version is faster than the builtin conversion of every compiler I tested. In this blog post, I’ll explain what happened, how floats work, how this conversion works, and how it got a bit out of hand.

Last year, as an occasional contributor to the Rust project, I did not think much about the organisational structure of the team behind the project. I saw a hierarchy of teams and groups, team leaders, etc. Just like any other organisation. This year, after getting more involved, becoming a library team member and eventually team lead, I spent some more time thinking about why we have this structure, what these teams are for.

In this final part of the series, we’ll explore a trick to make the behaviour of a macro depend on whether it’s used as a statement or as part of an expression. Using that, we’ll make the python!{} macro more flexible to allow saving, reusing, and inspecting Python variables.

Have you ever seen the Rust compiler give a Python error? Or better, have you ever seen rust-analyzer complain about Python syntax? In this post, we’ll extend our python!{} macro to make that happen.

In this part, we’ll extend our python!{}-macro to be able to seamlessly use Rust variables in the Python code within. We explore a few options, and implement two alternatives.

Before continuing to extend our python!{} macro in part 2, let’s explore some things in more detail first.

About a year ago, I published a Rust crate called inline-python, which allows you to easily mix some Python into your Rust code using a python!{ .. } macro. In this series, I’ll go through the process of developing this crate from scratch.

In Software for Infrastructure, Bjarne Stroustrup shows a way to use templates to make the C++ compiler aware of the unit of a value (e.g. kilograms, seconds, etc.), such that it can check consistent use and prevent disasters like the well known error at NASA in 1999 caused by mixing incompatible units. In this article, I show how to extend this idea to support any number of base units and linearly related units (e.g. centimetres, metres and inches) by teaching the compiler how to do arithmetic on units.

Recently, gcc added support rvalue references for *this. (Clang has supported it for quite a while now.) In this post, I show how to use this feature, and how it means we can finally define accessors and a few other things like operator= correctly.