I started experimenting with asynchronous Rust code back when futures 0.1 was all we had - before async/await. I was a Rust baby then (I’m at least a toddler now), so I quickly drowned in a sea of .and_then, .map_err and Either<A, B>.

But that’s all in the past! I guess!

Now everything is fine, and things go smoothly. For the most part. But even with async/await, there are still some cases where the compiler diagnostics are, just, so much.

The day 15 puzzle falls into the “math puzzle” territory more than “let’s learn something new about Rust”, but since several folks asked if I was going to continue… let’s continue.

The sample input is as follows:

Sensor at x=2, y=18: closest beacon is at x=-2, y=15 Sensor at x=9, y=16: closest beacon is at x=10, y=16 Sensor at x=13, y=2: closest beacon is at x=15, y=3 Sensor at x=12, y=14: closest beacon is at x=10, y=16 Sensor at x=10, y=20: closest beacon is at x=10, y=16 Sensor at x=14, y=17: closest beacon is at x=10, y=16 Sensor at x=8, y=7: closest beacon is at x=2, y=10 Sensor at x=2, y=0: closest beacon is at x=2, y=10 Sensor at x=0, y=11: closest beacon is at x=2, y=10 Sensor at x=20, y=14: closest beacon is at x=25, y=17 Sensor at x=17, y=20: closest beacon is at x=21, y=22 Sensor at x=16, y=7: closest beacon is at x=15, y=3 Sensor at x=14, y=3: closest beacon is at x=15, y=3 Sensor at x=20, y=1: closest beacon is at x=15, y=3

Welcome back to the “Making our own executable packer” series, where digressions are our bread and butter.

Last time, we implemented indirect functions in a no-libc C program. Of course, we got lost on the way and accidentally implemented a couple of useful elk-powered GDB functions - with only the minimal required amount of Python code.

The article got pretty long, and we could use a nice distraction. And I have just the thing! A little while ago, a member of the Rust compiler team stumbled upon this series and gave me some feedback.

My honeymoon with the Go language is extremely over.

This article is going to have a different tone from what I’ve been posting the past year - it’s a proper rant. And I always feel bad writing those, because, inevitably, it discusses things a lot of people have been working very hard on.

In spite of that, here we are.

Having invested thousands of hours into the language, and implemented several critical (to my employer) pieces of infrastructure with it, I wish I hadn’t.

In hours, I have played more of The Binding of Isaac than any other game in my Steam library. Edmund McMillen said he wasn’t expecting it to be a hit, and has since proceeded to be proven thoroughly wrong.

It is kind of a big deal among a certain crowd: as I’m writing this, the second season of the Binding of Isaac Racing League, hosted and commented by Crumps, is in full swing - even though the game was certainly not designed for that!

This series has to end somewhere, so let’s end it here!

However, here is a list of some things I’d like to come back to:

Bundling & TypeScript

Using a bundler like Parcel so I can write some of the client-side logic in TypeScript, have it take care of building the SCSS, etc.

I do that to great effect in another project of mine and I’d like to show you how I did it!

Welcome back and thanks for joining us for the reads notes… the thirteenth installment of our series on ELF files, what they are, what they can do, what does the dynamic linker do to them, and how can we do it ourselves.

I’ve been pretty successfully avoiding talking about TLS so far (no, not that one) but I guess we’ve reached a point where it cannot be delayed any further, so.

Against all odds, it looks like the year 2020 will actually come to an end - in less than a day now. I know! Hard to believe for me too.

A lot of things have happened for me personally, and professionally. It’s been a big year in many ways, and I feel like, to get some closure, I need to highlight some of them.

From “looking at graphs” to “driving to the hospital”

Day 2, Day 2! Woo!

The Advent of Code 2020, Day 2 problem talks about passwords. Sounds familiar.

Basically, our input looks like this:

1-3 a: abcde 1-3 b: cdefg 2-9 c: ccccccccc

Each line contains a “password policy” and a “password”. For the first line, the policy is that the password must contain between 1 and 3 (inclusive) times the letter “a”.

In the previous chapter, we’ve made a nix “dev shell” that contained the fly.io command-line utility, “flyctl”.

That said, that’s not how I want us to define a dev shell.

Our current solution has issues. I don’t like that it has import <nixpkgs>. Which version of nixpkgs is that? The one you’re on? Who knows what that is.

Also, we haven’t really seen a mechanism to use .nix files from elsewhere.