never met a part of the stack I didn't like. sr. engineer at clique studios in chicago, perpetual creative hobbyist, bird friend, local gay agenda promoter. she/her. tips: https://ko-fi.com/carlymho
I enjoyed it - AoC proved to be a pretty good way to get comfortable with Rust! Coding up more complex data structures (like trees and graphs) was a little harder than in, say, C, because you have the borrow checker looking over your shoulder, and you have to do a fair amount of work to convince it you're being safe with those kinds of data structures. What I often ended up doing was create a "node" type that would have a label and a list of labels representing the neighbors/children for that node, and use a label → node hash map to traverse between nodes. Please don't take this as me saying the borrow checker is a downside - it's just my opinion that it makes Rust less suitable for prototyping, but better for writing rock-solid software!
That being said, I would still rate myself as a Rust amateur, so perhaps there are smarter ways to build trees and graphs than I could come up with, or libraries I could leverage for this.
This is all speaking based on the journal notes I took during AoC last year - I didn't mention speed in notes, and I don't remember feeling that Rust's speed gave me a particular advantage over Racket the previous year. That being said, I used what I learned to port some Python code I'd used to parse Wikipedia data dumps into Rust - Rust's speed plus its easy multithreading facilities definitely helped!
I did AoC with Racket in 2016, and I did 2017's in Rust (and a few in Idris); I was thinking of maybe doing Clojure this year.
How did you find Rust for working on AoC? I imagine the speed probably helps since a lot of the puzzles are kind of optimization problems.
I enjoyed it - AoC proved to be a pretty good way to get comfortable with Rust! Coding up more complex data structures (like trees and graphs) was a little harder than in, say, C, because you have the borrow checker looking over your shoulder, and you have to do a fair amount of work to convince it you're being safe with those kinds of data structures. What I often ended up doing was create a "node" type that would have a label and a list of labels representing the neighbors/children for that node, and use a label → node hash map to traverse between nodes. Please don't take this as me saying the borrow checker is a downside - it's just my opinion that it makes Rust less suitable for prototyping, but better for writing rock-solid software!
That being said, I would still rate myself as a Rust amateur, so perhaps there are smarter ways to build trees and graphs than I could come up with, or libraries I could leverage for this.
This is all speaking based on the journal notes I took during AoC last year - I didn't mention speed in notes, and I don't remember feeling that Rust's speed gave me a particular advantage over Racket the previous year. That being said, I used what I learned to port some Python code I'd used to parse Wikipedia data dumps into Rust - Rust's speed plus its easy multithreading facilities definitely helped!
Thanks for unsticking me on a graph in Rust, incidentally.