https://boats.gitlab.io/blog/ Recent content on withoutblogs Hugo -- gohugo.io woboats@gmail.com (boats) woboats@gmail.com (boats) Mon, 01 Jun 2020 00:00:00 +0000 https://boats.gitlab.io/blog/post/new-blog/ Mon, 01 Jun 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/new-blog/ My content has moved permanently to https://without.boats/blog https://boats.gitlab.io/blog/post/ringbahn/ Wed, 27 May 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/ringbahn/ In my previous post, I discussed the new io-uring interface for Linux, and how to create a safe API for using io-uring from Rust. In the time since that post, I have implemented a prototype of such an API. The crate is called ringbahn, and it is intended to enable users to perform IO on io-uring without any risk of memory unsafety. io-uring is going to be majorly important to the development of async IO on Linux in the future, and Linux is the most used platform for the kinds of high performance network services that are a major user of Rust. https://boats.gitlab.io/blog/post/io-uring/ Wed, 06 May 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/io-uring/ Last fall I was working on a library to make a safe API for driving futures on top of an an io-uring instance. Though I released bindings to liburing called iou, the futures integration, called ostkreuz, was never released. I don’t know if I will pick this work up again in the future but several different people have started writing other libraries with similar goals, so I wanted to write up some notes on what I learned working with io-uring and Rust’s futures model. https://boats.gitlab.io/blog/post/the-problem-of-effects/ Mon, 13 Apr 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/the-problem-of-effects/ In a previous post, I shortly discussed the concept of “effects” and the parallels between them. In an unrelated post since then, Yosh Wuyts writes about the problem of trying to write fallible code inside of an iterator adapter that doesn’t support it. In a previous discussion, the users of the Rust Internals forum hotly discuss the notion of closures which would maintain the so-called “Tennant’s Correspondence Principle” - that is, closures which support breaking to scopes outside of the closure, inside of the function they are in (you can think of this is closures capturing their control flow environment in addition to capturing variables). https://boats.gitlab.io/blog/post/why-ok-wrapping/ Tue, 07 Apr 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/why-ok-wrapping/ I’ve long been a proponent of having some sort of syntax in Rust for writing functions which return results which “ok-wrap” the happy path. This is has also always been a feature with very vocal, immediate, and even emotional opposition from many of our most enthusiastic users. I want to write, in one place, why I think this feature would be awesome and make Rust much better. I don’t want to get into the details too much of the specific proposal, but here’s a sketch of one way this could work (there are a number of variables). https://boats.gitlab.io/blog/post/failure-to-fehler/ Mon, 06 Apr 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/failure-to-fehler/ About two and a half years ago I wrote a Rust library called failure, which quickly became one of the most popular error handling libraries in Rust. This week, its current maintainer decided to deprecate it, a decision I strongly support. This week, I also released a new and very different error-handling library, called fehler. I wanted to discuss these two libraries briefly. A brief history of failure When I released failure, the most popular error handling library by far was error-chain. https://boats.gitlab.io/blog/post/vulnerabilities/ Wed, 01 Apr 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/vulnerabilities/ This is just a post about something that grinds my gears a bit more than it reasonably should: I think the habit of applying for CVEs for Rust (and Rust ecosystem libraries) is silly at best and harmful at worst. I think it muddies the waters about what a vulnerability is, and paints an overly negative picture of Rust’s security situation that can only lead people to make inaccurate evaluations when contrasting it with other languages like C/C++. https://boats.gitlab.io/blog/post/waitmap/ Thu, 12 Mar 2020 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/waitmap/ I’ve just released a new crate called waitmap. This is a concurrent hash map (built on top of dashmap) intended for use as a concurrency primitive with async/await. It extends the API of dashmap by having an additional wait method. The wait future looks up an entry in the map and suspends this task if the entry was not present when wait was called. The task will be woken whenever a value is inserted under that key. https://boats.gitlab.io/blog/post/global-executors/ Thu, 14 Nov 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/global-executors/ One of the big sources of difficulty on the async ecosystem is spawning tasks. Because there is no API in std for spawning tasks, library authors who want their library to spawn tasks have to depend on one of the multiple executors in the ecosystem to spawn a task, coupling the library to that executor in undesirable ways. Ideally, many of these library authors would not need to spawn tasks at all. https://boats.gitlab.io/blog/post/iou/ Fri, 08 Nov 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/iou/ Today I’m releasing a library called iou. This library provides idiomatic Rust bindings to the C library called liburing, which itself is a higher interface for interacting with the io_uring Linux kernel interface. Here are the answers to some questions I expect that may provoke. What is io_uring? io_uring is an interface added to the Linux kernel in version 5.1. Concurrent with that, the primary maintainer of that interface has also been publishing a library for interacting with it called liburing. https://boats.gitlab.io/blog/post/poll-drop/ Wed, 16 Oct 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/poll-drop/ The first version of async/await syntax is in the beta release, set to be shipped to stable in 1.39 on November 7, next month. There are a wide variety of additional features we could add to async/await in Rust beyond what we’re shipping in that release, but speaking for myself I know that I’d like to pump the breaks on pushing forward big ticket items in this space. Let’s let the ecosystem develop around what we have now before we start sprinting toward more big additions to the language. https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/ Wed, 17 Jul 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/ Many people who use Rust for a bit - especially those who like the language but do not fall in love with it - feel a sense that there must be a smaller, simpler variation on the same theme which would maybe be a little less powerful, but would also be much easier to use. I agree with them, but I think they are almost always wrong about what would need to change. https://boats.gitlab.io/blog/post/await-decision-ii/ Tue, 28 May 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/await-decision-ii/ In my previous post I said that the lang team would be making our final decision about the syntax of the await operator in the May 23 meeting. That was last Thursday, and we did reach a decision. In brief, we decided to go forward with the preliminary proposal I outlined earlier: a postfix dot syntax, future.await. For more background, in addition the previous post on my blog, you can read this write up about some of the trade offs from April. https://boats.gitlab.io/blog/post/zero-cost-abstractions/ Thu, 16 May 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/zero-cost-abstractions/ The idea of a zero cost abstraction is very important to certain programming languages, like Rust and C++, which intend to enable users to write programs with excellent performance profiles with relatively little effort. Since this idea is fundamental to the design of Rust and my work, I want to investigate, for a moment, what exactly a zero cost abstraction even is. The idea is summarized in its original by Bjarne Stroustrup, the original developer of C++: https://boats.gitlab.io/blog/post/await-decision/ Mon, 06 May 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/await-decision/ This is an announcement regarding the resolution of the syntax for the await operator in Rust. This is one of the last major unresolved questions blocking the stabilization of the async/await feature, a feature which will enable many more people to write non-blocking network services in Rust. This post contains information about the timeline for the final decision, a proposal from the language team which is the most likely syntax to be adopted, and the justification for this decision. https://boats.gitlab.io/blog/post/for-await-i/ Mon, 15 Apr 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/for-await-i/ The biggest unresolved question regarding the async/await syntax is the final syntax for the await operator. There’s been an enormous amount of discussion on this question so far; a summary of the present status of that discussion and the positions within the language team is coming soon. Right now I want to separately focus on one question which impacts that decision but hasn’t been considered very much yet: for loops which process streams. https://boats.gitlab.io/blog/post/generators-ii/ Mon, 18 Feb 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/generators-ii/ This is my second post on the design of generators. In the first post, I outlined what an MVP of the feature would look like. In this post, I want to take a look at the first design issue for the feature: how it integrates with the ? operator. To explain exactly what I mean, let’s start with a specific motivating example: // This generator yields the number of alphanumeric characters in every line // in some io::Read'able data // exact sign function declaration syntax left unspecified on purpose |data| { let mut buffered_data = BufReader::new(data); let mut string = String::new(); while buffered_data. https://boats.gitlab.io/blog/post/generators-i/ Mon, 11 Feb 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/generators-i/ We’re still not finished with the design of async/await, but it’s already become clear that it’s time to get the next phases of the feature into the pipeline. There are two extensions to the minimal async/await feature we’ve currently got that seem like the clear high priority: Async methods: allowing async fn to be used in traits. Generators: allowing imperative control flow to create Iterators and Streams the same way async fn allows imperative control flow to create a Future. https://boats.gitlab.io/blog/post/wakers-ii/ Fri, 11 Jan 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/wakers-ii/ In the previous post, I provided a lot of background on what the waker API is trying to solve. Toward the end, I touched on one of the tricky problems the waker API has: how do we handle thread safety for the dynamic Waker type? In this post, I want to look at that in greater detail: what we’ve been doing so far, and what I think we should do. https://boats.gitlab.io/blog/post/wakers-i/ Mon, 07 Jan 2019 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/wakers-i/ Work on supporting async/await in Rust continues to progress rapidly. I’m hoping to write a retrospective on everything that happened in 2018 in a few weeks. Right now we’re closing in on an important milestone: stabilizing the futures API that will be used to interact programmatically with asynchronous computations. The biggest remaining area of work is the design of the waker API, an essential but somewhat opaque part of how our asynchronous programming system works. https://boats.gitlab.io/blog/post/rust-2019/ Sun, 16 Dec 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/rust-2019/ We all know that classic aphorism: Year comes to an end, Rust blog post press send. This is mine. There are lots of cool technical improvements to Rust that I want the project to achieve this year, and a few in particular that I’m definitely going to be putting a lot of time into. But this blog post is going to talk about none of them. Instead, I want to talk about organizational debt, and how badly the Rust project needs to deal with it in 2019. https://boats.gitlab.io/blog/post/romio/ Wed, 05 Dec 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/romio/ This blog post is about a project called Romio that I’ve been working on over the past two or three weeks. Romio is a port of a small part of the Tokio project to the newer futures APIs. I started the project to get some experience porting code from the old futures API to the new API. However, we realized that this code could also be useful to other people who want to experiment with networking code using the new async/await syntax, so with the help of others we polished it up during the RustFest Rome “impl days” and now its being released for people to experiment with. https://boats.gitlab.io/blog/post/await-syntax/ Thu, 08 Nov 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/await-syntax/ One thing we’ve left as an unresolved question so far in the matter of async/await syntax is the exact final syntax for the await operation. In the current implementation, awaits are written using a compiler plugin: async fn foo() { await!(bar()); } This is not because of any technical limitation: the reason we have done this is that we have not decided on the precise, final syntax for the await operation. https://boats.gitlab.io/blog/post/anchored-uniform/ Fri, 02 Nov 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/anchored-uniform/ Rust 2018 is almost out the door, but there is one big decision the language team has yet to make. It has to do with the modules and paths system, so of course it is a very easy decision that no one has a strong opinion about. ;-) In Rust 2018, we’ll be making some big changes to how paths work to try to create a more consistent experience. The “lodestar” (if you will) of these changes is an idea we call “1path:” the idea no matter where you are in your project, whether in a use statement or normal code, a path is interpreted the same way. https://boats.gitlab.io/blog/post/shifgrethor-iv/ Wed, 31 Oct 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/shifgrethor-iv/ The post before this one covered how shifgrethor handles rooting: how we track for the garbage collector that this object is alive. That isn’t sufficient for implementing a tracing garbage collector though: the idea of a tracing garbage collector is that we can trace from rooted objects through all of the objects they reference. That way, instead of having to root everything you use, you can only root a few objects from which all of the live objects can be traced. https://boats.gitlab.io/blog/post/shifgrethor-iii/ Wed, 24 Oct 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/shifgrethor-iii/ After the digression in the previous post, it’s time to get back to what I promised in the first post: a look at how shifgrethor handles rooting. Shifgrethor’s solution is somewhat novel and takes advantage of some of Rust’s specific features, so I want to start by looking briefly at some of the other options. How to root a GC’d object There are two broad categories of rooting strategies that are common among precise, tracing garbage collectors: https://boats.gitlab.io/blog/post/shifgrethor-ii/ Mon, 22 Oct 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/shifgrethor-ii/ In the previous post I said that in the second post in the series we’d talk about how rooting works. However, as I sat down to write that post, I realized that it would be a good idea to back up and give an initial overview of how a tracing garbage collector works - and in particular, how the underlying garbage collector in shifgrethor is implemented. In the abstract, we can think of the memory of a Rust program with garbage collection as being divided into three sections: the stack, the “unmanaged” heap, and the “managed” heap. https://boats.gitlab.io/blog/post/shifgrethor-i/ Tue, 16 Oct 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/shifgrethor-i/ I’m really excited to share with you an experiment that I’ve been working on for the past 5 or 6 weeks. It’s a Rust library called shifgrethor. shifgrethor implements a garbage collector in Rust with an API I believe to be properly memory safe. I’ll be going through all of the technical details in future blog posts, so I want to kick this series off with a high level overview of the project’s purpose and design decisions. https://boats.gitlab.io/blog/post/the-hard-part-of-open-source/ Tue, 16 Oct 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/the-hard-part-of-open-source/ Evan Czaplicki, the creator and maintainer of the Elm project (a project that I love by the way) gave a great talk at Strange Loop last month called “The Hard Parts of Open Source.” I really enjoyed and valued this talk, and I encourage everyone who is involved in open source to watch it. You can find on YouTube here. In particular, I got a lot of value out of his identification of three specific harmful patterns of behavior in the open source community, and of his geneological work tracing the origins of those behaviors through the history of the “hacker” subculture. https://boats.gitlab.io/blog/post/pin-cell/ Tue, 09 Oct 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/pin-cell/ Today I realized a new crate called pin-cell. This crate contains a type called PinCell, which is a kind of cell that is similar to RefCell, but only can allow pinned mutable references into its interior. Right now, the crate is nightly only and no-std compatible. How is the API of PinCell different from RefCell? When you call borrow_mut on a RefCell, you get a type back that implements DerefMut, allowing you to mutate the interior value. https://boats.gitlab.io/blog/post/names-and-scuba/ Mon, 10 Sep 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/names-and-scuba/ There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. Naming a project, tool, or concept that you want other people to use is a very hard problem. The most important thing, of course, is that the name sounds cool. Then, significantly less important, but still quite important, is that the name convey useful information to your users. This is where things get tricky. https://boats.gitlab.io/blog/post/rethinking-pin/ Wed, 22 Aug 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/rethinking-pin/ A few months ago we introduced the concept of “pinned” references - pointers which “pin” the data they refer to in a particular memory location, guaranteeing that it will never move again. These are an important building block for certain patterns that had previously been hard for Rust to handle, like self-referential structs and intrusive lists, and we’ve in the process of considering stabilizing the API. One thing has always nagged about the API we have right now though: the proliferation of different reference types that it implies. https://boats.gitlab.io/blog/post/my-experience-with-rust-2018/ Tue, 24 Jul 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/my-experience-with-rust-2018/ Recently, I wrote a little a side project to sign git commits without gpg. When I did this, I decided to use the Rust 2018 edition. I also transitioned an existing library from Rust 2015 to Rust 2018 to see how that tooling worked. I thought I’d write a blog post about my experience using the Rust 2018 preview and the state of things right now. Module changes The main thing I noticed vividly was the new experience of the module system. https://boats.gitlab.io/blog/post/signing-commits-without-gpg/ Mon, 23 Jul 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/signing-commits-without-gpg/ Unlike most git users, I try to sign my commits. Unfortunately, the only way to do this right now is to use PGP signatures, because that is all that git is able to integrate with. This has meant that in practice I have to use GPG if I want to sign my commits, an experience I do not relish. Last week, I wrote a program to replace GPG for that purpose. https://boats.gitlab.io/blog/post/async-methods-ii/ Mon, 04 Jun 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/async-methods-ii/ Last time, we introduced the idea of async methods, and talked about how they would be implemented: as a kind of anonymous associated type on the trait that declares the method, which corresponds to a different, anonymous future type for each implementation of that method. Starting this week we’re going to look at some of the implications of that. The first one we’re going to look at is object safety. https://boats.gitlab.io/blog/post/async-methods-i/ Thu, 31 May 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/async-methods-i/ Async/await continues to move along swimmingly. We’ve accepted an RFC describing how the async/await syntax will work in Rust, and work is underway on implementing support for it in the compiler. We’re hopeful that users will be able to start experimenting with the syntax on nightly by early July. The RFC for async/await didn’t address one important thing: async methods. It is very important for people defining libraries to be able to define traits that contain async functions, like this: https://boats.gitlab.io/blog/post/2018-04-06-async-await-final/ Fri, 06 Apr 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-04-06-async-await-final/ I’m really excited to announce the culmination of much of our work over the last four months: a pair of RFCs for supporting async & await notation in Rust. This will be very impactful for Rust in the network services space. The change is proposed as two RFCs: RFC #2394: which adds async & await notation to the language. RFC #2395: which moves a part of the futures library into std to support that syntax. https://boats.gitlab.io/blog/post/2018-03-20-async-vi/ Tue, 20 Mar 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-03-20-async-vi/ It’s hard to believe its been almost 6 weeks since the last post I made about async/await in Rust. So much has happened that these last several weeks have flown by. We’ve made exceptionally good progress on solving the problem laid out in the first post of this series, and I want to document it all for everyone. Future and the pinning API Last month I wrote an RFC called “Standard library API for immovable types”. https://boats.gitlab.io/blog/post/2018-02-22-failure-1.0/ Thu, 22 Feb 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-02-22-failure-1.0/ I’m planning to release a 1.0.0 version of failure on March 15. Once this happens, I don’t plan to release any further breaking changes to the failure crate (though maybe someday in the distant future). Breaking changes in 1.0 failure is in a somewhat unique position as being a significant part of the public API of other libraries that depend on it. Whether they use the Error struct or derive Fail for a custom error type, this becomes a part of the API they expose to other users. https://boats.gitlab.io/blog/post/2018-02-08-async-v-getting-back-to-the-futures/ Thu, 08 Feb 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-02-08-async-v-getting-back-to-the-futures/ Two posts ago I proposed a particular interface for shipping self-referential generators this year. Immediately after that, eddyb showed me a better interface, which I described in the next post. Now, to tie everything together, its time to talk about how we can integrate this into the futures ecosystem. Starting point: this Generator API To begin, I want to document the generator API I’ll be using in this post, which is roughly what followed from my previous post: https://boats.gitlab.io/blog/post/2018-02-07-async-iv-an-even-better-proposal/ Wed, 07 Feb 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-02-07-async-iv-an-even-better-proposal/ I did not plan to write this blog post. I thought that the fourth post in my series would explain how we could go from the generator API in my previous post to a futures API in which you don’t have to heap allocate every async call. But eddyb surprised me, and now I have to revisit the API in the previous post, because we can implement everything we need from immovability with a safe interface afterall. https://boats.gitlab.io/blog/post/2018-01-30-async-iii-moving-forward/ Sun, 04 Feb 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-01-30-async-iii-moving-forward/ In the first post, we looked at the relationship between generators and a more general notion of self-references. In the second post, we narrowed down exactly what problem we need to solve to make generators work, and talked about some solutions that we’ve considered but don’t feel like we could ship in the near future. In the original post, I promised that I would have a near term solution by the end of this series. https://boats.gitlab.io/blog/post/2018-01-30-async-ii-narrowing-the-scope/ Wed, 31 Jan 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-01-30-async-ii-narrowing-the-scope/ Last time we talked about the broader problem that generators with references across yield points represent: self-referential structs. This time, I want to narrow in on the specific problem that needs to be solved to make generators work, and also discuss some ideas for solutions that I think are false starts. (I still don’t have a proposal about what to do in this post, but it will come soon enough! https://boats.gitlab.io/blog/post/2018-01-25-async-i-self-referential-structs/ Thu, 25 Jan 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-01-25-async-i-self-referential-structs/ This is the first in a series of blog posts about generators, async & await in Rust. By the end of this series, I will have a proposal for how we could expediently (within the next 12 months) bring generators, async & await to stable Rust, and resolve some of the most difficult ergonomics problems in the futures ecosystem. But that proposal is still several posts away. Before we can get to a concrete proposition, we need to understand the scope & nature of the problem we need to solve. https://boats.gitlab.io/blog/post/2018-01-18-configure/ Thu, 18 Jan 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-01-18-configure/ Hi :) I’ve been working on a project called configure, which is intended to create a uniform way to load configuration variables from the environment of the program. Specifically, the goal is to create something that libraries can rely on to allow applications to delegate decisions about how configuration is loaded to applications, without those applications having to write a lot of bespoke configuration management glue. Storing configuration in the environment “The 12 Factor App” has this very good advice about managing configuration: https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/ Tue, 09 Jan 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-01-08-goals-for-rust/ The Rust project has requested blog posts about the project’s goals for 2018. I found myself in pretty much complete agreement with Nick Cameron’s post, so I thought instead I would write about my own personal goals for Rust in 2018. I am fortunate enough to work on Rust full-time; modulated by the work that needs to get done to accomplish larger team goals, these are some things that I’m individually very motivated to make progress on in 2018. https://boats.gitlab.io/blog/post/2018-01-04-unsafe-abstractions/ Thu, 04 Jan 2018 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2018-01-04-unsafe-abstractions/ Unsafety in Rust is often discussed in terms the primitive operations that can only be performed inside of unsafe blocks (such as dereferencing raw pointers and accessing mutable statics). I want to look at it from a different angle from these primitive operations, and instead focus on the capability to produce unsafe abstractions. The general concept of unsafe abstractions An unsafe abstraction is a new abstraction which requires the unsafe keyword to apply to some context (this is an intentionally “abstract” definition, because as we will see there are several highly divergent forms of unsafe abstraction supported in Rust). https://boats.gitlab.io/blog/post/2017-12-27-things-explicit-is-not/ Wed, 27 Dec 2017 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2017-12-27-things-explicit-is-not/ Oftentimes when I am conversing about the design of Rust with other users - as on RFCs or the internals forum - I witness a peculiar remark about “explicitness.” It usually goes something like this: I do not like Feature Design X because it is too implicit. Magic is okay in Other Language Y, but Rust is supposed to be an explicit language, so we should go with Feature Design Z instead. https://boats.gitlab.io/blog/post/2017-11-30-failure-0-1-1/ Thu, 30 Nov 2017 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2017-11-30-failure-0-1-1/ I’ve just published failure 0.1.1 to crates.io. It’s mostly some incremental improvements to failure that have been suggested since the first release two weeks ago. Improvements to the derive A big change in version 0.1.1 is that the derive can be used without depending on the failure_derive crate separately. All that needs to be done is tagging the extern crate statement with #[macro_use]: // No direct dependency on `failure_derive` #[macro_use] extern crate failure; #[derive(Fail, Debug)] #[fail(display = "An error occurred. https://boats.gitlab.io/blog/post/2017-11-16-announcing-failure/ Thu, 16 Nov 2017 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2017-11-16-announcing-failure/ I’m really excited to announce a new crate I’ve been working on, called failure, and which I’ve just released to crates.io. Failure is a Rust library intended to make it easier to manage your error types. This library has been heavily influenced by learnings we gained from previous iterations in our error management story, especially the Error trait and the error-chain crate. The Fail trait The core abstraction in failure is the Fail trait, a replacement for the existing std::error::Error trait. https://boats.gitlab.io/blog/post/2017-10-28-alternative-registries/ Mon, 23 Oct 2017 14:10:21 -0700 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2017-10-28-alternative-registries/ cargo gained a new feature this week! You can now download dependencies from alternative registries, alongside the dependencies you download from crates.io. This is an important step in enabling organizations to distribute their internal libraries through cargo without requiring them to upload those libraries to a public registry. This feature will be available on nightly only, and it is gated behind the alternative-registries feature gate. We’ve used feature gates to iterate on new and unstable features in rustc since the 1. https://boats.gitlab.io/blog/post/2017-09-28-blogging-with-gitlab-and-hugo/ Thu, 28 Sep 2017 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2017-09-28-blogging-with-gitlab-and-hugo/ Previously, I attempted to maintain a blog using GitHub Pages. I was very unsuccessful at actually producing blog posts, though. I don’t care a lot about the appearance or maintenance of my blog site. What I want from the experience is the same experience I have writing Rust RFCs (because I have a lot of experience doing that): I write some markdown. I commit and push. Other people can read it. https://boats.gitlab.io/blog/post/2017-01-21-handshake-patterns/ Sat, 21 Jan 2017 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2017-01-21-handshake-patterns/ The problem: defining a ‘handshake’ protocol between two traits You have a problem that decomposes in this way: you want any type which implements trait Alpha to be composable with any type which implements trait Omega… That is, if Foo and Bar are both Alphas and Baz and Quux are both Omegas, you can compose Foo with Baz or Quux, and the same with Bar, and so on. This is not a trivial problem. https://boats.gitlab.io/blog/post/2017-01-04-the-rust-module-system-is-too-confusing/ Wed, 04 Jan 2017 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/post/2017-01-04-the-rust-module-system-is-too-confusing/ A while ago I was considering an idea, so I wrote a tweet to ask what folks thought about it. A very spirited discussion followed about the Rust module system and what the pain points with it were (indeed - whether or not there were pain points at all). Depending on your skill at navigating Twitter’s UI, you may or may not be able to read the whole discussion by following the link above. https://boats.gitlab.io/blog/page/about/ Mon, 01 Jan 0001 00:00:00 +0000 woboats@gmail.com (boats) https://boats.gitlab.io/blog/page/about/ This is the blog of withoutboats, a Rust contributor and a stack of labrador puppies in an overcoat.