Adventofcode 2025

Third time's a charm

This year, I felt I could finally make some time to try and solve the Advent of Code (AOC). This'd be the third time I try to solve it, but other years have always been rather difficult with other obligations (either study -, work related, or both). I never really made it past a handful of days. This time I tried to really commit to it. To get (read: learn) something out of it, I intended to solve everything in Rust, with no external libraries. The latter was more of a goal rather than a strict requirement.

TL;DR: I managed:

Without wanting to go to much into detail, the core structure of every problem (12 problems with two parts each, resulting in 24 stars to earn) is the same for every problem:

1. A problem is defined using a small text input file (test.txt).
2. Code can be setup and tested for correctness with the test file.
3. When solved, a data.txt file is provided that needs to be parsed in order to get the solution for one part.
4. The second part is done on the same datafile, and is defined by a similar but more difficult puzzle.

I made a single repository to with the main.rs file just pointing to the day at hand. All days have their separate file made available as a module:

mod day01;
mod day02;
...
mod day12;

fn main() {
    day01:day1();
    day01:day1_part2();
    ...
    day12::day12();
    day12::day12_part2();
}

As for the I/O part, I've kept things as simple as possible there too. It doesn't win a price for being pretty, and I end up duplicating quite a lot of code per day/module. This is fine though, as in the end my goal is to focus on the puzzles, not win a beauty contest. In all modules the relative path to the txt files is set as a const, and directly read using either read_to_string, or with BufRead. Going through the puzzles, I've learned a few things, but most of all identified some key areas where I should improve.

In short:

• peekable in std::iter: easy way to find out if an iterator will be over after the current state. I've used this in day06, which was by far my favorite puzzle due to the 'right-to-left, vertical' nature of the problem. If anything this just highlights how ingrained left to right, top to bottom parsing is for me.
• unreachable. To 'bypass' compiler that some arm cannot be reached. This is just a detail, but I encountered this relatively often before (which is probably a reflection of my basic level in Rust).
• While I don't encounter this often in my day-to-day work, the puzzles (especially those in the second half) often reduced to a problem that can be solved efficiently by recursion, memoization, or both. If there is anything I've learned doing this year's AOC, it's that I should brush up these concepts a bit more, or at least try to make some more exercises utilizing these to get more familiarized writing code that way. Not using those often resulted in code that worked, but took forever to reach a solution.

I didn't try to solve the puzzles as fast as possible, but nevertheless it's interesting to see how much time it takes. To get an idea on this I looked at the time elapsed for all function calls (read: puzzle parts) takes. Cargo run (i.e. unoptimized) gives me 6.56 seconds of runtime, cargo run --release clocks in at 1.00 seconds for all 24 parts, which I'm pretty happy with.

Summarized, I'm happy I pushed through this AOC, learned a couple of new things that I'll use in the future, but more importantly allowed me to identify what tools I should sharpen next.