2 results found

• Abstraction

  Published on 2024-12-03

  Tags: zig, rust, aoc

  Despite saying previously that I was just going to use Rust for the Advent of Code this year, I did feel a slight twinge of regret that I was wasting an opportunity for learning a new language. Zig had piqued my interest recently and I tried my Rust in Zig. After an hour or two of reading the language documentation, looking through the Zig Cookbook, and attempting to write a solution I feel like I can confidently say that Zig is an interesting language that is entirely not for me.

  The simple task of opening a file and reading through it line by line in Zig requires setting up allocators, getting a file handle, creating a reader, then wrapping that reader in a buffer reader, and then streaming the text into the buffer. Reading a single file a single time doesn’t need that level of abstraction. How fine-grained your control needs to be should be dictated by how performant that action must be. If I’m creating a hot loop that relies on constantly opening and closing files and then quickly streaming and parsing the bytes, then I want the ability to drop down to extremely low level control. In that situation we need little to no abstraction. In the majority of cases however, I don’t want to have to worry about the precise strategy I’m using to allocate chunks of memory.

  Just as it’s useful for a language to allow stripping away as much abstraction as possible when necessary, it’s also useful for that language to allow using abstractions when complete control isn’t necessary. The problem with Zig is that it doesn’t allow more abstractions, you’re trapped at the lower levels. This is just as bad as trapping you at high levels of abstraction. You’re stuck with the opposite problem of Python or Ruby.

  A good language should allow you to move up and down the layers of abstraction at will. This is why I love Rust. If I want to read a file, all I need is a single line of code using the read_to_string function and it’ll be fast enough for the vast majority of use cases. I know everything will “just work”. Rust also allows moving down the levels of abstraction as well. If I’m quickly reading small amounts of bytes, then BufReader can help. I can preallocate memory for vectors, pick between a half dozen available allocators, customize it, or even write my own. I don’t have to sacrifice either the low end or high end of abstraction.

• Cross Compiling Rust for the Raspberry Pi

  Published on 2024-11-01

  Tags: rust, rpi

  To get this blog up and running I had to endure the horrors of cross-compiling Rust. I currently use a MacBook Air that I do most of my programming on. This blog is simply a Cargo project that I compile and rsync over to my Raspberry Pi to run. The issue of course is that compiling the Rust binary on my MacBook means cross compilation. Here’s a detailed outline of the steps I took to get this working to save future people pain.

  Specs

  Technology is always changing and both MacBooks and Raspberry Pis will both continue to update. Here are the exact tech specs I’m working with. If yours are different you may have to adapt these instructions.

  I’m working on a 2020 M1 MacBook Air. The Raspberry Pi is a gen 4 Model B Rev 1.4.

  Install musl-cross

  This Homebrew formula contains a ton of cross-compilation tools for every architecture under the sun. I originally installed it to cross-compile Golang projects that relied on cgo for a x86_64 Linux server but it had the required tools to also compile Rust for a Raspberry Pi.

  Install Rust std lib

  Next you’ll need the Rust standard library for the Raspberry Pi. If you’re using Rust you should have rustup installed. Run rustup target add aarch64-unknown-linux-musl to add the std lib for the Raspberry Pi.

  Side note here, from my limited understanding it seems like both arm and aarch64 can run on the RPi but arm is 32 bits while aarch64 is 64 bits as the name implies. Not completely sure about this though.

  Add the linker for the target

  While it doesn’t seem like you need to specify CC, you do need a linker. Create a file at .cargo/config.toml and put the following config options into it to specify the linker for the aarch64-unknown-linux-musl target we’ll be using.

  [target.aarch64-unknown-linux-musl]
  linker = "aarch64-linux-musl-ld"

  This part tripped me up because I assumed that this must be an older way of configuring Cargo because everyone knows config options go in the Cargo.toml file right? Wrong. Apparently the Cargo.toml and .cargo/config.toml both serve different functions as shown by the docs here, and here, respectively.

  Compiling

  Now we can cross-compile our project with the command cargo build --release --target=aarch64-unknown-linux-musl.

  One weird bug I ran into is that if I run that shell command directly on the command line it compiles correctly but if I run it from a Makefile then it throws a weird error while compiling a sqlx macro. I’ll update this blog if I figure out why that is.

  Edit: The issue had nothing to do with cross compilation was instead related to how environment variables are handled in Make. The issue was fixed in this commit