Software artist. Writer aficionado. Open source enthusiast.
Runner. Father of two.
Currently: Senior Software Engineer at Google, New York City.
The point of this post is simple and I’ll spoil it from the get go: every time you make an assumption in a piece of code, make such assumption explicit in the form of an assertion or error check. If you cannot do that (are you sure?), then write a detailed comment. In fact, I’m exceedingly convinced that the amount of assertion-like checks in a piece of code is a good indicator of the programmer’s expertise.
I am pleased to announce that the first release of sandboxfs, 0.1.0, is finally here! You can download the sources and prebuilt binaries from the 0.1.0 release page and you can read the installation instructions for more details. The journey to this first release has been a long one. sandboxfs was first conceived over two years ago, was first announced in August 2017, showed its first promising results in April 2018, and has been undergoing a rewrite from Go to Rust.
Bazel’s original raison d’etre was to support Google’s monorepo. A consequence of using a monorepo is that some builds will become very large. And large builds can be very resource hungry, especially when using a tool like Bazel that tries to parallelize as many actions as possible for efficiency reasons. There are many resource types in a system, but today I’d like to focus on the number of open files at any given time (nofiles).
I used to be good at replying to emails on time. When tens of emails came in every day, I would sort them out and I would reply right away to anything that needed or caught my attention. The so-called Inbox Zero wasn’t a specific goal that required effort: “it just was”. Things have changed over the years and I am now quite awful at dealing with personal email. Some emails can go weeks (or, I confess, months) before getting a reply.
There are two ways to handle abnormal conditions in a program: errors and assertions. Errors are a controlled mechanism by which the program propagates details about a faulty condition up the call chain—be it with explicit error return statements or with exceptions. Errors must be used to validate all conditions that might be possible but aren’t valid given the context. Examples include: sanitizing any kind of input (as provided by the user or incoming from the network), and handling error codes from system calls or libraries.
There is no good answer to this question: people tend to put Go and Rust in the same bucket because they were released at around the same time, because Rust's release felt like a response to Go's, and because they are marketed to similar audiences. They are, however, vastly different. So let's give in and compare them anyway.
Thought that the Rust review was over? Think again; I was just on vacation! I’m back now to conclude the series with a bunch of random thoughts and a surprise follow-up post. The series is coming to an end. It’s time to summarize everything we have discussed so far and to cover a few more items that didn’t really deserve full posts of their own. Most of these miscellaneous items were thoughts that I jotted down while reading TRPL book.