Recently I was helping someone get bootstrapped on their Axum project, and they were getting a bit frustrated with the lack of context about the goings on in their application. While Axum and it's ecosystem are well instrumented, by default most of it is not very well surfaced for beginners. It can be a bit intimidating figuring out how to put the pieces together and use them.

Rust spoils me, I rarely need to reach for a debugger thanks to structured logging via tracing and errors with spantraces thanks to eyre. When I do find myself wanting to really dig my grubby little paws into some code, configuring the debugger targets can feel intimidating.

Experience has taught me that I can conquer intimidating things though, and sometimes that is best done with a little help. While hacking on a pgx bug, I realized I was using a newly installed system, and needed to reconfigure my debugger settings.

This made a good opportunity for me to share with you! This short article will cover how to configure Visual Studio Code with CodeLLDB so you can visually debug your pgx extensions. This includes being able to step into the pgx or postgres sources. While the instructions may be Arch Linux specific, they should be able to be adapted to a different Linux.

A few years ago, I saw bunnie's Precursor on Crowd Supply and instantly fell in love. The idea enamored me despite hardly knowing what FPGAs were at the time.

Embedded development has always been a fun hobby of mine, and I think it's an excellent pursuit for any developer to improve their knowledge. If you like Rust (like me), some great starting points are the nRF52840s, the ESP32-C3-DevKitC-02, or one of the TockOS boards (like the Hail).

While I love those, one thing I've wanted for a long time was a portable board with a battery, screen, keyboard, SDR, and user-servicable parts that could be hacked on top to bottom.

The Precursor offers all of the above list (except, sadly, the SDR) and is powered by a XC7S50-1L CSG324I System-on-Chip (SoC) running the open Betrusted SoC and an iCE40UP5K SG48 Embedded Controller (EC) running the open Betrusted EC on an open hardware design. It seems almost perfect for me.

Well... I finally convinced myself to order one as a reward for doing a big thing, and it has now arrived! So, let's explore!

Reaching for something like SUM(vals) or AVG(vals) is a common habit when using PostgreSQL. These aggregate functions offer users an easy, efficient way to compute results from a set of inputs.

How do they work? What makes them different than a function? How do we make one? What kinds of other uses exist?

We'll explore creating some basic ones using SQL, then create an extension that defines aggregates in Rust using pgx 0.3.0's new aggregate support.

PostgreSQL offers an extension interface, and it's my belief that Rust is a fantastic language to write extensions for it. Eric Ridge thought so too, and started pgx awhile back. I've been working with him to improve the toolkit, and wanted to share about one of our latest hacks: improving the generation of extension SQL code to interface with Rust.

This post is more on the advanced side, as it assumes knowledge of both Rust and PostgreSQL. We'll approach topics like foreign functions, dynamic linking, procedural macros, and linkers.

When designing an API for your crate one topic which can come is how to handle optional arguments. Let's explore our Options in Rust!

Recently there has been quite a bit of talk about WebAssembly, a new format for code for the web. It is a compile target for languages like C and Rust that enables us to write, and run, code from these languages in our browser.

In the interest of learning more about this technology (and to avoid writing more Javascript) let's explore together and get our hands dirty!

Disclaimer: WebAssembly is stabilized, but most implementations are not. The information contained here may become out of date or be incorrect, despite working at the time of writing.

In this post we'll be discussing one way to set up your machine for Rust development. There are different ways, particularly related to the text editor, so feel free to skip what is irrelevant to you. We'll focus on:

• Setting up Rust via Rustup.
• Valuable tools like clippy and rustfmt.
• Configuring VS Code for Rust.
• Debugging with the command line and inside of VS Code.
• Using different compile targets.

Everything we do should be functional on both Linux and MacOS, on Windows your mileage may vary. I, unfortunately, don't have a Windows instance to test on.

Recently there has been a lot of progress in the Rust language towards a robust asynchronous stack. In this article we'll take a look at what these things are, take a tour of what's available, play with some examples, and talk about how the pieces fit together.

We'll get started with the futures crate to start, move on to futures_cpupool, and then eventually to tokio. We will assume you have some knowledge of programming, and have at least thought about trying Rust before.

Lately I've been thinking a lot about the patterns and structures which we program with. It's really wonderful to start exploring a project and see familiar patterns and styles which you've already used before. It makes it easier to understand the project, and empowers you to start working on the project faster.

Sometimes you're working on a new project and realize that you need to do something in the same way as you did in another project. This thing might not be a functionality or a library, it might not be something which you can encode into some clever macro or small crate. Instead, it may be simply a pattern, or a structural concept which addresses a problem nicely.

One interesting pattern that is commonly applied to problems is that of the 'State Machine'. Let's take some time to consider what exactly we mean when we say that, and why they're interesting.

I'm happy to introduce the first stable version of my Rust Heroku Buildpack!

Just looking to get your hands dirty? Look here.

The project was a really interesting learning experience about how Heroku does things, on bash scripting, and about multirust, which I'd not used before but now am quite a fan of! (I previously just rustup'd the newest nightly every few days.)

Evolving How We Learn Systems with Lessons from Programming in the Large

Some bugs are just that+++a one off. A wayward moth that just happens to be innocently fluttering through the wrong relay at the wrong time. But some kinds of bugs aren't like that. Instead, they have risen to superstar status, plaguing veterans and newcomers alike. But what if these aren't bugs at all? What if they are actual deficiencies in safety and robustness offered by the C programming language as a consequence of the degree to which guesswork is introduced. Here we explore a more explicit approach to systems level programming supported by Rust, which we believe will better promote understanding of design intent, and eliminate some of the guesswork. Guided by a set of classic, but still relevant, bugs identified almost 15 years ago by Engler, we consider this in the context of the new generation of students learning about systems in a typical OS course, where students often first encounter these deficiencies.

A selection of images from my trip that I thought I'd share with the world.

If you want to use one of these for anything at all, just fire me an email and ask!

The next few weeks are full of excitement and busy-ness! First up is the Meetup in San Fran (See our planning). I can't wait! It will be so fun to meet many people I've already met in IRC and through the community!

If you'd like to do something, or show me around the city, let me know! I've never been to the USA before, let alone San Fransisco.

After that I'm moving into a new place! A friend and I landed a great location for the next year and we're looking forward to the changes ahead. Once I'm settled in classes will be starting and I have a very busy term ahead!

We've also got couple nice working examples! Yes, they're ready to play with!

Can't wait, need code? Visit Raft and check out the examples/ directory!

In preparation for the forthcoming 0.0.1 release of Raft we've taken several forward steps to improve our (already pretty darn cool!) tooling and infrastructure. If you attempt to set up any of these on your own and have issues let me know! I'd be more than happy to help. You can find our .travis.yml here.

We've been resoundingly busy with our Raft implementation after a brief period of calm in the early summer! I'll be posting a few bits over the next weeks to help people both learn Rust, and learn about Raft!

As a result of Raft development two new crates have been put together for general consumption! Both of these are macro-centric and lead mainly by James.

In Rust, function signatures tell a story. Just from glancing at the signature of a function an experienced Rust user can tell much of the functions behaivor.

In this article we'll explore some signatures and talk about how to read them and extract information from them. While exploring, you can find many great function signature examples in the Rust API docs. You can play around on the Playpen.

This article assumes some knowledge of Rust, glossing over a bit of the book should be quite sufficient if you are lacking that but have programmed before.

I've been playing around with a new project that uses a lot of collections of results, for example Vec<Result<()>> and asked some folks on Rust if they new a good way of transforming this into a Result<Vec<()>>.

Turns out, .collect() can do it for you!

One of my favorite features of Rust is iterators. They are a fast, safe, 'lazy' way of working with data structures, streams, and other more creative applications.

You can play along on http://play.rust-lang.org/ and by browsing here. This article is not a subtitute for the documentation or experience.

In order to celebrate the new beta release of Rust, and as part of reporting requirements for my class, I'm happy to write to you regarding hoverbear/raft!

Awhile ago, I wrote a First Look at Cap'n Proto. Unfortunately I didn't cover how to utilize it's RPC capabilities. In Rust, this is via the capnp-rpc-rust crate.

Let's do that!

Rust is probably my favorite programming language (as the contents of this site suggests). My interests in networks, development operations, and systems programming align strongly with Rust. They're pursuing the trifecta: Safe, Fast, Concurrent. It's been a great learning journey for me so far and I learnt to write better code in all languages.

Github Pages is Github's very generous offering of web hosting to your projects. Basically, you create a branch gh-pages and push it to Github, then browse to https://$USERNAME.github.io/$REPOSITORY.

One of my next goals in my Raft project is to tame the tick() with mio. In this post, we'll explore what it is, what it can do, and why it matters. First things first: What is MIO?

MIO is a lightweight IO library for Rust with a focus on adding as little overhead as possible over the OS abstractions.

As you may have previously read, I've been working on implementing the Raft Distributed Consensus Algorithm in Rust for my classes (and fun!).

I've spent the majority of my free time this last week working on Raft. As you can see from this issue I've been mostly working on the idea of transactions.

A lot has taken shape in the codebase. It still will panic at unimplemented!() about 300ms after you start a node, but "That's a feature!"

Note: All interfaces and code are not final, and are for educational and interest purposes.

So, I found this (this, and this) Cap'n Proto library for Rust and wanted to explore it a bit. Unfortunately the documentation is sparse for the library, and I haven't played with Cap'n Proto before.

Cap'n Proto is what's billed as a 'Data Interchange Format' and 'Capability-Based RPC System'. Or a 'Cerealization Protocol'.

TL;DR: I've made Hoverbear/raft publicly available (It's still not ready)! Feel encouraged to contribute feedback or code via Github or email!

I've been working quite a bit on my Raft implementation over the last few days and I must say it's been quite a pleasure to work in Rust, which recently released it's 1.0.0-alpha.

It takes the work out of needing to serialize and deserialize data, it enforces data safety, and it's type checking is incredible. I'm very quickly able to make a change, build it, fix the errors the compiler catches for me, and build again, then test. So far the only times my tests have failed after a successful build was when I was accidently disgarding one of my channels.

I'm currently working on implementing the Raft Distributed Consensus protocol in Rust.

This is a project I'm doing for my CSC466 class at the University of Victoria, and I'm hoping to use it as part of one of my projects for CSC462.

At the end of the project I plan to release it as MIT licensed code. Please stay tuned...

I was reading about the Docopt project the other day and really liked the standardized approach to --help prompts and argument parsing that it offers.

Luckly, there is a Rust Package to play with!

A really 'cute' problem popped up in our Data Structures & Algorithms homework and I wanted to write about it.

If you're in the class this will obviously ruin the fun, so read it later, after you're done!

One of my projects over the upcoming semester is to explore the Linux boot process and the job of the init (initialization) system. The init system is considered PID 1 and is responsible for a significant portion of userspace functionality. Common init systems on Linux are OpenRC and systemd. One of the key parts of an init system is to spawn new processes, like in command shell.

Executing child processes may be useful to any number of programs, but common applications include:

• Shells
• Init systems
• Launchers
• Interfacing with command line applications

One common monadic structure is the Option (or Maybe in Haskell and other languages) type. This can be seen as an encapsulation type. Consider a function which may fail to produce a meaningful value for certain inputs. For example,

fn main () {
  // Parses a string into an integer.
  from_str::<int>("4"); // A valid input.
  from_str::<int>("Potato"); // Definitely invalid.
}