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). We would add a syntactic modifier to the
signature of a function, like this:
fnfoo()-> usizethrowsio::Error{//..
}
This function returns Result<usize, io::Error>, but internally the return expressions return a
value of type usize, not the Result type. They are “Ok-wrapped” into being Ok(usize)
automatically by the language. If users wish to throw an error, a new throw expression is added
which takes the error side (the type after throws in the signature). The ? operator would behave
in this context the same way it behaves in a function that returns Result.
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.…
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++.…
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.…
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.…
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.…
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.…
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. Here are some
notes on where I would start to create that smaller Rust.
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.…
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++:…