DEV Community: Jacob W Runge

Comparing Apples and Oranges: Rust and JavaScript in AOC 2023 Day 1

Jacob W Runge — Fri, 01 Dec 2023 21:33:13 +0000

(cover photo by Anastasiya Romanova on Unsplash)

I just wrote a rather long-winded article sharing my experience completing the Advent of Code 2023 Day 1 challenge in Rust. I really like Rust, but like most frontend-brained devs giving into the Stockholm Syndrome that JavaScript inflicts on us, I found myself constantly saying, "This would be 15 minutes and 10 lines of code in JavaScript."

Let's put that to the test. In this article, I'll talk through what it was like to complete this challenge both in new, scary Rust and my cozy JS blanket. Oh, I also did some benchmarking of the two implementations, with some pretty surprising results. If someone can set me on the right path to interpreting that craziness, I'm all-ears.

Context, if you need it: This code is meant to loop through 1000 strings and extract the first and last number (maybe typed out, like "eight," and maybe numeric, like 8), concatenate them (4 and 8 makes 48), then add their results.

My 10 lines of JavaScript

Comparing the code length and development speed of writing this challenge in Rust vs. in JavaScript isn't really fair. For one, I'm a Rust newb, and I've been programming in JavaScript pretty much daily for a several years. Also, I wrote the Rust implementation first, knew it worked, and then followed the same pattern in the JavaScript. Heading in knowing the solution and how to arrive at it, knowing the language-agnostic gotchas, and slipping into the warm, comfortable embrace of JS, I was feeling pretty good.

That said, it wasn't all rainbows and sunshine. Here's my 10 lines of JS (Node) in 32 lines:

const fs = require("fs");
const words = { "one": "1", "two": "2", "three": "3", "four": "4", "five": "5", "six": "6", "seven": "7", "eight": "8", "nine": "9" };
const lines = fs.readFileSync("./coords.txt", "utf8").split("\r\n");
let total = 0;

function getFirstOrLastNumber(line, last) {
    if(last) line = line.split("").reverse().join("");
    for(let char of line) {
        try { 
            const parsed = parseInt(char); 
            if(!isNaN(parsed)) return parsed;
        }
        catch(_) { true }
    }
}

for(let line of lines) {
    let newLine = "";
    for(let i=0; i < line.length; i++) {
        for(const word in words) {
            const substr = line.slice(i, i + word.length);
            if(substr === word) {
                newLine += words[word];
            }
        }
        newLine += line[i];
    }
    let newNum = `${getFirstOrLastNumber(newLine)}${getFirstOrLastNumber(newLine, true)}`
    total += parseInt(newNum) || 0;
}

console.log(total);

Look, it's not 10 lines, I get it. I could get it down to 1 line if I minified it, leave me alone.

The point is, it's over a third the line length of the Rust code. I didn't work as hard to break everything out into functions, but it also feels a lot less necessary here. Compared to Rust, it feels just much more natural to do string manipulation in JS.

I'm not going to get into time-to-completion much here, because there's really no objective way to look at it. I got the JS working mostly as-intended in about 15 minutes, I would guess. But again, I'm much more comfortable with the language; it's a lot higher-level, really well-suited for string manipulation; and I was literally porting the Rust code I had already written.

Despite getting it up-and-running so quickly, I actually spent another 20 minutes or so debugging. Why? Well, some weird stuff cropped up.

Notice that try-catch block in getFirstOrLastNumber()? Yeah, that's because I wasn't sure what would happen if I fed parseInt something that couldn't be parsed as a number. It turns out, parseInt always returns NaN in that case, whether you give it a string, or null, or undefined, or some random object. And NaN doesn't fail the try-catch block, so I was getting NaN for a lot of the strings I passed in.

(Fun fact: My previous statement about parseInt always returning NaN isn't actually true. parseInt([4, 5, 6]) returns 6. Isn't JavaScript great? /s)

To account for that, I added the isNan() check. The try-catch block is actually completely unnecessary. But it goes to show you how, even in a language I work with regularly, one that is ostensibly "simple" and "easy," there are some hidden complexities that make code behavior not so clear-cut.

The same goes for that total += parseInt(newNum) || 0; line near the end of the code. I pretty much superstitiously add || someDefault after any function from which I expect a return value, because I never know if the return value will be falsey or not.

None of this is to say that JavaScript is behaving unpredictably or even inconsistently -- it's kind of a skill issue, I'll admit. And some of this would have alleviated had I used TypeScript. But at the end of the day, it also goes to show that JavaScript's attempts to hide complexity from the programmer are a double-edged sword that sometimes (often) result in a different, more frustrating kind of complexity.

The Rust

I won't go into detail here -- you can check my other post for that. Since the last post, I did do a bit of refactoring to DRY the code out a bit. Here's the result:

use std::{fs, collections::HashMap};

fn get_calibration(filename: &str) -> i32 {
    let contents = fs::read_to_string(filename).expect("Something went wrong reading the file");
    let lines = contents.split("\n");

    let mut sum: i32 = 0;
    for line in lines {
        sum += number_from_line(line);
    }

    sum
}

fn number_from_line(line: &str) -> i32 {
    let replaced: String = check_for_word(line);
    let first_num = first_or_last_number(&replaced, false);
    let last_num = first_or_last_number(&replaced, true);
    let combo_str = format!("{}{}", first_num.unwrap(), last_num.unwrap());
    let as_num = combo_str.parse::<i32>().expect("Combo string should parse to i32");
    as_num
}

fn first_or_last_number(input: &str, reverse: bool) -> Option<char> {
    let new_str = match reverse {
        true => input.chars().rev().collect::<String>(),
        false => input.to_string()
    };

    println!("New string: {}", new_str);

    for c in new_str.chars() {
        if c.is_digit(10) {
            return Some(c);
        }
    }

    None
}

fn check_for_word(input: &str) -> String {
    let words: HashMap<String, &str> = HashMap::from([
        ("one".to_string(), "1"),
        ("two".to_string(), "2"),
        ("three".to_string(), "3"),
        ("four".to_string(), "4"),
        ("five".to_string(), "5"),
        ("six".to_string(), "6"),
        ("seven".to_string(), "7"),
        ("eight".to_string(), "8"),
        ("nine".to_string(), "9"),
    ]);

    let mut replaced = "".to_string();
    let mut i = 0;
    for char in input.chars() {
        for word in words.keys() {
            let substr = match input.get(i..i+word.len()).ok_or("Out of bounds") {
                Ok(str)=> str,
                _ => {continue;}
            };

            if substr == word {
                replaced.push_str(words.get(word).unwrap());
            }
        }

        replaced.push_str(char.to_string().as_str());
        i += 1;
    }

    replaced
}

fn main() {
    let coords = get_calibration("coords.txt");
    println!("Calibration: {}", coords);
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_first_num() {
        assert_eq!(first_or_last_number(&"ab12cd34ef", false).unwrap(), '1');
    }

    #[test]
    fn test_last_num() {
        assert_eq!(first_or_last_number(&"ab12cd34ef", true).unwrap(), '4');
    }

    #[test]
    fn test_check_for_word() {
        assert_eq!(check_for_word(&"jjhxddmg5mqxqbgfivextlcpnvtwothreetwonerzk"), "jjhxddmg5mqxqbg5fivextlcpnv2two3three2tw1onerzk");
    }

    #[test]
    fn test_check_for_word_nums() {
        assert_eq!(number_from_line("two1nine"), 29);
        assert_eq!(number_from_line("eightwothree"), 83);
        assert_eq!(number_from_line("abcone2threexyz"), 13);
        assert_eq!(number_from_line("xtwone3four"), 24);
        assert_eq!(number_from_line("4nineeightseven2"), 42);
        assert_eq!(number_from_line("zoneight234"), 14);
        assert_eq!(number_from_line("7pqrstsixteen"), 76);
    }
}

A lot bigger, huh? And apparently more complex.

But I'd argue it's not, really. Yeah, if you read my breakdown of the Rust code in my other post, you'll know I struggled a bit with this. But I don't think I struggled nearly as much with the Rust syntax as I did with the AOC prompt and figuring out how to transform those spelled-out numbers to numeric ones without mangling other spelled-out numbers.

I thought about types WAY more in my JS code than I did in Rust, where the LSP kindly annotated everything for me; the compiler clearly explained when my expectations didn't align with reality; functions clearly signaled when they might panic and variables had to be unwrapped and every potentiality accounted for.

I ran my Rust code completely confident that it would work the way I intended it to work, and that any errors came from a flaw in my logic, not from unclear expectations about what the code would do.

Also, that thing I said about the code being 3x as large as the JavaScript? It's also better structured, more readable, and more modular. Plus a third of it is built-in tests.

Oh yeah -- the tests! It's so nice to just plunk some tests in there and assert equality without having to resort to just randomly printing to the console or installing Jest or something. So, so good.

That's it

I'm digging Rust a lot. If someone can explain these weird benchmarks, I'm on-board for writing everything I can in native Rust and WASM. I'm excited to keep knocking out these AOC challenges in Rust, and I'll definitely be posting them (though I probably won't go so hard with comparisons and benchmarks next time unless it's warranted 😅). If you like these articles, give me a follow here... and maybe on Twitter / X, too?

Later!

Rust is SLOW actually? - AOC 2023 day 1 performance comparison

Jacob W Runge — Fri, 01 Dec 2023 21:12:55 +0000

UPDATE: I've stuck a comment below with updated benchmarks after the community helped me to improve my Rust code. Spoiler alert: Rust is wicked fast. WAY faster than the equivalent JavaScript. I've pasted that comment here at the end of the post, in case the comment gets buried someday.

I just got through with the Advent of Code 2023 Day 1 challenge, and I wrote about my trials and tribulations in great, long-winded detail. I'm a frontend guy who's used to working in TypeScript, a near-total Rust newb, so I thought it might be interesting to do a little comparison write-up. I ran through the challenge in Rust, then circled back and ported it to JavaScript (running in Node.js). After the lengthy account in my initial post, I figured the comparison would be short and sweet, just some general impressions about what I like about each language, with a fun little benchmark at the end that showed just how much faster Rust was.

Then I ran the benchmarks, and what I saw was shocking enough that I figured I'd better yank the benchmarks out of my comparison article and make a dedicated post in an attempt to get some answers.

Full disclosure: I'm not a benchmarker. When my apps run slow, I do performance testing, but beyond that, I'm usually happy just knowing something is "fast" or "slow." And in my mind, Rust is fast and JavaScript is slow.

But that's not what I'm seeing in these numbers, and I think I need a sanity check.

My test

To test execution speed, I used PowerShell's measure-command (I use Windows, btw -- why are you laughing?). measure-command is a rough equivalent to the time command in Unix.

I compiled the Rust code using cargo build --release, then ran each implementation 5 times and took the average execution speed.

The initial results

Running each, we end up with: JavaScript, avg 39.9254ms; Rust: 18.3171ms. Rust is faster by ~54%.

That makes sense. I don't doubt this result at all.

Let's see if that scales

I then ran each implementation on on a loop (internal to the code, not via the command line) 1000 times and see how it handles prolonged activity. That's an fs::read_to_string() (Rust) or an fs.readFileSync() (JS) followed by processing 1000 strings, 1000 times.

This is where the results get a little sus. JavaScript: 3260.6001ms; Rust: 6564.07532ms. Oof... Rust is more than twice as slow. That doesn't feel right...

I thought perhaps that Rust's file reader implementation just wasn't up to snuff, assuming Node's readFileSync implements some battle-tested C or C++ function, but no... removing file reads seemed to have little affect on either implementation.

I'm not exactly dissatisfied with Rust's performance: it actually scaled pretty well, as far as I understand it. With 1000x the work, Both programs scaled well; with 1000x the work, the Rust code was only ~358x slower. The prolonged activity didn't scale linearly, instead finishing significantly faster that one would expect. This, to me, suggests one of two things:

There is a hefty invocation cost (this doesn't seem likely - running the program once only cost ~18ms)
There is a "warm-up" period, with the code executing faster over time

I suppose a third option could be that invocation is slow (say, 17ms); the code executes initially very fast (1ms), and then slows down over the duration of the program's runtime. That seems less likely to me.

Is Node just really fast?

In any case, the JavaScript code was only ~82x slower at 1000x the load. So another possible explanation would be that the Node is doing some kind of magic like caching the file read or certain execution patterns... In which case, highly repetitive tasks could be a rare performance boon for scripting languages like JS.

It's also possible (likely) that, as a Rust newb, there is some kind of inefficiency in my code that is exacerbated by prolonged run time / repetition. That code, in addition to being mostly included in my previous article, can be found on GitHub.

It's also possible that I'm a JavaScript prodigy and have the unique ability to make it run faster than compiled code. /s

So I'm curious, Rustaceans and Node... Node-heads? What could be the cause of this discrepancy between a single execution and execution over time?

Getting the Rust right

UPDATE: I've got my answer. Rust is, in fact, WAY faster, ESPECIALLY in the 1000x test. Many thanks to all who commented and helped me get my Rust up to snuff. 😅

I updated my Rust code to use iterators directly (thanks Eduard!), globalize the HashMap instead of recreating it each function call (thanks Mike Stemle!), and generally be smarter about searching for numbers (not doing full string replaces, but stopping my loops as soon as a valid match was found). Where those changes could be ported to the JS version, I did so. Full code on GitHub.

Here are the new results:

Rust single iteration is down to 10.161ms (almost cut in half from the previous 18.317!).

JavaScript single iteration is up to 71.723. It looks like the previous version was more efficient at ~39ms, which just goes to show you that porting code one-to-one between languages as different as Rust and JavaScript isn't always the best practice. While it would be interesting to investigate further, I think it's most fair to compare the fastest working JS code to the fastest working Rust code here, and Rust ends up at ~25% of the JS code's total the execution time.

Rust 1000x iterations is down to an amazing 385.875 ms, 17x faster than before (at ~6 seconds) and only ~38x slower for 1000x the work. 🤯

JavaScript 1000x iterations comes out to 3691.43. This is, not surprisingly, MUCH slower than the Rust 1000x test (by ~100x) and slower than the previous JS version's 1000x test. What IS surprising is that it's not off the previous version by much, with the old code coming in at 3260.6. So despite the difference in single-iteration performance of the JS code from old to new nearly doubling, the 1000x iteration test only ends up being ~400ms slower.

That said, in that 400ms difference, the Rust code could have run it's full 1000 iterations and had a spot of tea.

Calibrating an Elven Trebuchet in Rust: Advent of Code 2023 Day 1

Jacob W Runge — Fri, 01 Dec 2023 16:56:37 +0000

Strap in, folks: I stayed up until 2 AM trying to get a solution to the first challenge of this year's Advent of Code. Why? Because I decided I was going to do it in Rust, that's why.

I'll just take you through my approach to the problem. I won't cover the code in great detail (you can check out the repo if you want to take a closer look), but I will touch on some points of pain and interest. If you, too, are learning Rust or thinking about, this article may help to call attention to what makes Rust, Rust. If you're a seasoned Rustacean, well, consider this a comedy article. (But please do let me know if there are better ways to approach any of this!)

The first prompt

This first AOC challenge came in two parts. The first had something to do with elves launching me into space on a trebuchet to get power stars or something, I didn't quite follow, but the actual task was pretty simple: given a list of strings like this:

mxmkjvgsdzfhseightonetwoeight7
3five4s84four9rtbzllggz
75sevenzdrpkv1onetwo
3q7ctkghhqkpb5four

For each line, get the first and last number and concatenate them. Then, for each number you've found, add them all up, and that's the solution to the problem.

For example, the first line above would yield 77 (as 7 is both the first and last number); the second would yield 39; the third, 71; and so on. My list contained 1000 lines like this.

So right now I'm thinking, "No sweat! This is, like, 4 lines of JavaScript." I knew Rust would be a bit more complicated, but I've toyed around in Rust enough to know how to write the code and where to look for what I don't know.

Getting started

I Cargo init'd, saved the 1000-line input to a file in my Rust project, and wrote up a little file loading function that printed the file contents to the console, just to make sure I could load the data correctly. No problem.

use std::fs;

fn load_input_from_file(filename: &str) -> () {
    let contents = fs::read_to_string(filename).expect("Something went wrong reading the file");
    println!("File contents: {}", contents);
    ()
}

Quick note here to say that I'm not worrying too much about failing gracefully. I used expect() above to provide a decent error message on panic if the file load failed, but you'll see some unwrap()s later on (which is considered bad practice in production code).

Next, I tried to get fancy and import the reqwest Cargo crate to load straight from the URL instead of loading from a file, and got my first ego check: AOC data is unique per-user and instead of getting the list of 1000 strings, I got a prompt to authenticate. I'm not dealing with that right now, and this isn't really a Rust problem, so we'll stick with loading from a file and just move on.

Making the borrow checker mad

Turns out, loading a string from a file is really not all that complicated, so it doesn't make much sense to have a whole function dedicated to it. In an effort to make functions as single-purpose and reusable as possible (I don't know what AOC has in store!), I wrote up this little beauty, which takes a filename and returns its contents as a Split<'_, &str>:

fn load_coords_from_file(filename: &str) -> Split<'_, &str> {
    let contents = fs::read_to_string(filename).expect("Something wen wrong reading the file");
    let lines = contents.split("\n");
    lines
}

Bad move, Jake.

There are two issues the compiler let me know about here. The first is that I should use .collect() to return a vector of string references. That feels a lot better... but I'm not going to do it, because the second issue would likely still remain: "cannot return a value referencing a local variable 'contents.'

I've run afoul of the borrow checker. The borrow checker is the pain and beauty of Rust, and it exists to ensure that you aren't leaking memory by leaving references around after their block goes out of scope. And that's what's happening here -- the &str is a string reference type, or string slice.

I've gotten into some gnarly borrow checker fights, but this isn't really one of them.If we return a &str or anything that contains one, we'll be returning a reference to memory that goes out of scope and gets cleaned up the moment that function completes. We could return a vector of strings, but this may be a good early warning that I'm stretching context across too many functions and I just need to let my function be a little bigger and do a little more.

Making some progress

With that in mind, I wrote up a get_calibration() function and a first_number() and last_number function:

fn first_number(input: &str) -> Option<char> {
    for c in input.chars() {
        if c.is_digit(10) {
            return Some(c);
        }
    }

    None
}

fn last_number(input: &str) -> Option<char> {
    for c in input.chars().rev() {
        if c.is_digit(10) {
            return Some(c);
        }
    }

    None
}

fn get_calibration(filename: &str) -> i32 {
    let contents = fs::read_to_string(filename).expect("Something went wrong reading the file");
    let lines = contents.split("\n");

    let mut nums: Vec<i32> = Vec::new();
    for line in lines {
        let first_num = first_number(line);
        let last_num = last_number(line);
        let combo_str = String::from(first_num + last_num);
        nums.push(combo_str.parse::<i32>().expect("Combo string should parse to i32"));
    }

    let mut sum = 0;
    for num in nums {
        sum += num;
    }
}

Since those first_- and last_number() functions could potentially fail, I return an Option<char>. This is roughly the equivalent of returning string | null in TypeScript, and then accounting for null on the returned variable. This is something that Rust does that takes some getting used to, but that I really like: just about everything is wrapped up in little packages, and typically unwrapped with a match function, or failure-handled with something like expect() or just straight panic-on-failure'd with unwrap(). It's verbose, but there is pretty much zero chance your code will crash because it threw an error or provided a value you didn't expect (ahem JavaScript ahem). Even pointers are wrappers around a type that work in much this same fashion, with one of the most common literally being called Box.

By the way, I could totally combine those first_number and last_number functions and add a reverse flag as a parameter, but we'll just leave it and move on.

Testing

OK, so this is my absolute favorite part of Rust (well, aside from the amazingly-detailed compiler errors and wicked-smaht LSP) -- built-in, easy-to-use testing macros.

To make sure my first_- and last_number() functions were behaving as intended, I set up a couple of tests:

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_first_num() {
        assert_eq!(first_number(&"ab12cd34ef").unwrap(), '1');
    }

    #[test]
    fn test_last_num() {
        assert_eq!(last_number(&"ab12cd34ef").unwrap(), '4');
    }
}

Yep, looking good! With that validation, I ran my code, copied the output, and got my first gold star.

The second prompt (or, Origins of Pain and Suffering)

The elves are awful, awful little monsters, and apparently they have spelled out a few numbers: "two" instead of 2, "nine" instead of 9, etc. Luckily, even though they have spelled out some words like "sixteen," we only have to account for "one" through "nine."

The first part was really not a problem, and I figured this wouldn't be either. Maybe 10 lines of JavaScript now, but still achievable in Rust. What a fool I was.

My approach

Rather than getting into tedious char-by-char investigations of each string, I figured, "Let's just make a HashMap linking the spelled-out number to a stringified numeric representation and do a replace."

fn check_for_word(input: &str) -> String {
    let words: HashMap<String, &str> = HashMap::from([
        ("one".to_string(), "1"),
        ("two".to_string(), "2"),
        ("three".to_string(), "3"),
        ("four".to_string(), "4"),
        ("five".to_string(), "5"),
        ("six".to_string(), "6"),
        ("seven".to_string(), "7"),
        ("eight".to_string(), "8"),
        ("nine".to_string(), "9"),
    ]);

    let mut replaced = input.to_string();
    for word in words.keys() {
        if input.contains(word) {
            replaced = replaced.replace(word, words.get(word).unwrap());
        }
    }

    replaced
}

Boom. Run that at the start of first_- and last_number() functions. Boom. Write a new test:

#[test]
fn test_check_for_word() {
    assert_eq!(check_for_word(&"one2ctwo34ef"), "12c234ef");
}

Passed. Boom. Submit.

Failure.

WHAT??? How??? It passed my test and everything!

Tricksy hobbitses... I mean elves

Here's where Rust's awesome testing functionality came to my aid again. I expanded my test_check_for_word() test with a randomly-selected string from the hot garbage these evil little elves provided me:

assert_eq!(check_for_word(&"jjhxddmg5mqxqbgfivextlcpnvtwothreetwonerzk"), "jjhxddmg5mqxqbg5fivextlcpnv2two3three2tw1onerzk");

and on closer investigation of that string, lo and behold, they were intentionally trying to trick me! The nerve.

jjhxddmg5mqxqbgfivextlcpnvtwothreetwonerzk

Look at that. Look what they did: "twone". That's a "two" and a "one" combined. Both need accounted for, but my "replace word with number" method means the "two" gets replaced and the "one" is never seen. It turns into "2ne." Aaah!

Rust strings are hard

That means I need to be a little less laissez-faire about replacing words.

BUT, if I can go char-by-char through each string, look ahead by some number of chars to see if a whole word is there (say, 5 chars, the length of the longest number-word to replace), all I would have to do is insert the numeric value before the corresponding word, and I could preserve the correct order of numbers in the string without mangling number-words that I still need to check for.

A sound plan, but at this point it was 1 AM, when the ability to implement such a plan begins to wane. I came up with this monstrosity:

fn check_for_word(input: &str) -> String {
    // --- snip --- 
    let mut replaced = "".to_string();
    let mut i = 0;
    let mut skip = 0;
    for char in input.chars() {
        if skip > 0 {
            skip -= 1;
            continue;
        }

        if i+5 <= input.len() {
            let substr = match input.get(i..i+5).ok_or("Out of bounds") {
                Ok(str)=> str,
                _ => {continue;}
            };

            let mut replaced_word = false;
            for word in words.keys() {
                if substr.contains(word) {
                    let replacement = format!("{}{}", words.get(word).unwrap(), word);
                    let new_substr = substr.replace(word, replacement.as_str());
                    replaced.push_str(new_substr.as_str());
                    i += 5;
                    skip = 4;
                    replaced_word = true;
                    continue;
                }
            }

            if replaced_word {
                continue;
            }
        }

        replaced.push_str(char.to_string().as_str());
        i += 1;
    }

    replaced
}

🤮

This took forever to come up with, partly because Rust strings are a bit of a challenge compared to in JavaScript (where anything can be a string and a string can be anything).

I'll explain... but if you don't want an explanation of bad code, you can skip this next paragraph.

Iterating over a Rust string seems to require iterating over its chars, rather than its indices. And according to the compiler and several Google searches, there is no way to iterate over its indices. All Rust strings are valid UTF-8, and each index would refer to a byte... but each char may be more than one byte in UTF-8. So, this is probably a case of front-end brain, but for my purposes, I just want an index of how many chars in we are, not a byte index, so why can't I just write for (char, i) in input.chars()? Anyway, we must accept the things we cannot change. There are bigger problems here. Problems I've made for myself.

My test passed. I was ready to go to sleep. But my output was still wrong according to the AOC webpage.

See that nasty code that attempts to replace a word in a 5-char chunk, and then hackily skips the next 5 chars of the loop as a workaround to not being able to (figure out how to) skip several chars ahead in the iterator? Yeah, that's almost certainly the problem.

An insurmountable 2 AM problem, a 5-minute 7 AM fix

I gave up. I committed my code, git commit -m "Failure!". I went to bed. I lay awake, restless.

Then it came to me. Why try to replace the whole 5-char chunk? Why not just insert the number, and keep aggregating chars onto the string? Just let the loop run!

It took everything I had not to rush back to my computer. Good thing I didn't, because my daughter woke up crying. Then one of my dogs urinated in the hallway and I stepped in it while I was bringing her to my son's bed (where I was sleeping -- my son took my spot in my bed again). Look, I'm just saying... I'm a little sleepy. I'm hoping tomorrow's AOC adventure is a little tamer. That or maybe I can not stay up for it this time?

This morning, I did a little refactoring, updated my loop, and got another bad output. This has gone on long enough, so I won't go into to much more detail here.

I added several more test cases (I so love the integrated testing!) comparing some AOC-provided inputs and outputs, and discovered the five-chars-at-a-time approach overflowing the string's bounds, which I was handling... but it meant that spelled-out numbers at the end of a string were getting ingored. So strings like "two1nine" were returning 21 instead of 29.

Here's the simplified loop I ended up with:

let mut replaced = "".to_string();
let mut i = 0;
for char in input.chars() {
    for word in words.keys() {
        let substr = match input.get(i..i+word.len()).ok_or("Out of bounds") {
            Ok(str)=> str,
            _ => {continue;}
        };

        if substr == word {
            replaced.push_str(words.get(word).unwrap());
        }
    }

    replaced.push_str(char.to_string().as_str());
    i += 1;
}

Run, copy, submit, and...

SUCCESS!

Simple is better, folks.

I have conquered Day 1! I have obsessed and agonized and lost sleep over code for which I am not getting paid, which is in no way furthering my myriad personal projects! I'm a... winner?

Anyway, I learned a lot. I hope you got something out of this, too! I'll keep plugging away at these challenges, so if you want more (hopefully shorter?) accounts of my AOC adventures in Rust, be sure to follow this blog, or follow me on Twitter / X, where I'll do some occasional posts or blog updates.

See ya!

OK: it appears I'll be blogging

Jacob W Runge — Wed, 29 Nov 2023 20:38:21 +0000

Why? Because blogs have had a huge impact on where I've ended up as a developer, and I don't see them becoming any less important. I've gotten a lot out of articles by Flavio Copes and David Walsh, alongside countless random developers on Medium and Dev and HackerNoon.

Maybe I, too, can be someone else's random developer? Maybe I'm at a point now where what I know and what I've experienced can help someone else? Maybe writing about what I'm doing will help me to better organize my thoughts and my work?

Also, I pretty much already blog on my commute home from work each day, out loud or in my head, so it's not like I don't have anything to blog about. I've actually got kind of a daunting list of topics.

Who am I?

I'm a Software Engineer at Precision Planting, based in Illinois. I work mostly with the frontend, designing and developing the Radicle Agronomics hybrid app that deploys to the web, iOS, and Android. Maybe I'll blog about it sometime?

I've got a hard-working wife, Mary; and two pretty amazing kids: Isaac (4) and Elinor (2). Isaac is our maybe future engineer, and he loves Legos and magnets and anything with a motor; Ellie is the party's healer, providing imaginary band-aids for everyone's imaginary wounds. She also likes pretending to be a dinosaur.

When I'm not playing with or picking up after the kiddos, I'm probably working on some project or another. By day, I use Svelte and Ionic/Capacitor; by night, I experiment. Right now, I'm enjoying fighting Rust's borrow checker and trying to compile functional WebAssembly from as many languages as possible. I wish I had an excuse to learn Zig, I think TypeScript is a necessary evil, and I think React is an unnecessary evil.

And that's me!

So that's a blog post, huh?

Well... it's a start, isn't it? Words on "paper." I'll be more structured when we get hands-on with some code later on. Maybe.

Later!