In this post I share a few small thoughts on what Rust should do in 2018, and more broadly about the current direction of the language.
In this post I discuss the experiences of people coming to Rust from other languages. What their expectations generally are, how Rust meets or doesn’t meet those expectations, and how Rust might do better both at meeting those expectations, and at helping new users to calibrate expectations appropriately.
In this post I will discuss monomorphization: what it is, why it’s useful, and what problems can potentially arise from it, with a particular focus on the problem of monomorphization bloat. I will also look at options for dealing with monomorphization bloat in your codebase.
In this post I will talk about an interesting and useful addition to the Rust standard library in version 1.12.0. One which allows for an interesting API improvement to existing libraries, without harming backwards compatibility if libraries decide to use it.
There is a common pattern in writing Rust libraries that seems to be asked about fairly often: the unsafe core + safe interface. The essence is that you write the core of your library using unsafe Rust (usually for performance, or because you’re wrapping FFI code) and then write safe Rust to provide a nice, safe interface for the unsafe core. In this post I am going to give a quick explanation of how this is done, and what the considerations are. If you’re looking for a greater degree of detail on this, check out The Advanced Rust Programming Language (also called The Rustonomicon).
I love the Rust community, I really do. Like I said in my recent post about how to take part in it, I think the Rust community is one of the most consistently welcoming and friendly programming communities with which I’ve interacted. That being said, I think there are some problems with the way the Rust community presents itself and Rust to the outside world. In this post, I’d like to outline those problems, and some ideas for how the Rust community can be even better at explaining and pitching Rust to people who may not be sold on the idea yet.
Rust’s module system follows some fairly simple rules, but also seems to be a tripping point for new users of the language. In this post, I am going to walk through how the Rust module system works, and how it maps to the organization of files on the file system.
If you’re new to the Rust community, and unsure of what to read, how to take part, or where to ask questions, this post is for you. The Rust community is growing and active, and it can be difficult to understand what all the parts of it are, and how to go about orienting yourself in the Rust world. Hopefully, by the end of this post you will have a better sense of things.
As of the writing of this post, this site is now on a proper domain name: suspectsemantics.com. I’ve had this domain name for a good long while (years at this point), and I’m glad I’ve found a good use for it. The transition to the new name went smoothly, and links to the old GitHub Pages URL all appear to be redirecting correctly. If you have any issues with the new site, let me know on the site’s GitHub Repo.
This seems to be a common issue, so let’s talk about the different string types
in the Rust programming language. In this post I’m going to explain the
organization of Rust’s string types with
examples, then get into the lesser-used string types—
Path—and how the
Cow container can make working with
Rust strings easier.