Thanks for putting together this video. I’m looking forward to improving my rust skills with AoC. The tech stack lineup you put together looks like you’ll be presenting so really cool stuff. Looking forward to the series
Thanks for the guide! First year of trying it in Rust. Previous iterations completed in C++, however seeing your implementations from last year inspired me to become a fellow Rustacean this year! Wishing you to best of luck!
Thank you so much for such a detailed and instructive video. Although I am not smart enough to go through AoC, at least by following others journeys and learning from them I might get prepared enough to take on the challenge next year on my own. Subscribed, will try to follow through the whole series.
Late to the party but I am so excited to follow this in real time this year. Last year, or 6 months ago, I followed your 2022 rust advent of code to learn rust. It was super useful! Excited for all the new inclusions this year, best advent of code channel I have found regardless of language :) .
Thank you for this! I've been nervous about doing AoC in Rust, but knowing you're making these vids gives me great confidence that I'll at least be able to watch how you solved it!
Hi Cris, couldn't help myself and converted part of your setup into a cargo-generate template...you now have the first pull-request for your AoC repo if you like it.
Thanks for this content! I'm looking forward to finally learning some rust this year (I have been meaning to for a while now! 😅). Question: where are test modules normally kept in a Rust package? I assume putting the tests in the source code files was done just for convenience of Advent of Code, but I'm unsure. 🙂
tests being kept next to the source code is actually *not* an advent of code specific choice! This is a totally normal thing to do in regular projects for unit tests. Cargo supports unit tests, integration tests, examples, and doctests by default. unit tests are often handled like I have them here because they're meant to test isolated functions and such, while integration tests are typically in the tests/ directory. examples can live in the examples/ directory and even examples inside of documentation can be tested. * doc.rust-lang.org/cargo/reference/cargo-targets.html#tests * doc.rust-lang.org/book/ch11-03-test-organization.html * doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html * doc.rust-lang.org/cargo/reference/cargo-targets.html?highlight=bin#examples
I keep coming back to watch this video. It would be nice to explain some more of the context around your personal setup, why these are good things, using virtual workspaces, doing the debugging using dhat, etc. I see there is a video on using dhat,how to generate good benchmarks, but how it fits into the setup you chose 🤔
Yeah I could potentially do a recap video after Advent of Code about the setup, how it evolved and how different aspects worked out over the course of the days
That would be great if you could. This is very practical application of a complex setup, so seeing what worked as expected, or what you changed is useful to learn about too 👍
Hey hey, first of all thanks for the videos. I'm new to Rust and the AOC videos have helped me a lot accelerating my learning experience. I'm also using Linux for a while now and got very curious about the `ls`, `ps` and `where` you are using, since they are not the default. Could you give me a hint on whats going on there?
Great idea to have a setup lesson. Enjoyed it. Being a non-native speaker and a Rust beginner, you speak and act a bit fast for me. Pause and Repeat is my friend.
I'm sorry this is unrelated to the content of this video, but you seem to use MacOS and I don't know you you got this look (window disposition, no border, etc). Could you please explain it ? I have something like that with Hyprland on Linux and I wanted something similar on my Mac.
So excited by this. I had no intention of doing AoC this year. But I'm super interested to learn better profiling techniques and curious to see how miette shapes up!
Placing binaries in src/bin is a convention that is supported by cargo. It means that I can run them with `cargo run --bin part1` without any additional work because cargo will auto-discover them. If they weren't in src/bin (and weren't in main.rs, which is the primary default location), then I would have to configure their location. Basically, you can customize the location of any binaries but I chose to use the default locations. doc.rust-lang.org/cargo/reference/cargo-targets.html
06:40 There is only one input each day. There is never any input2. That being said, this looks a whole lot more involved than your setup last year. I'm kinda jealous.
I couldn't remember if there was an input2, so I set it up to work. Plus this means that I can drop random data into the two input files without messing up the other part if I'm debugging. Its definitely more involved than last year. I thought about it and felt that having it all set up was going to be better than doing the setup ad-hoc because people would be able to see the tools being used and have some more context before I explained them when they came up.
yes, I am focused on teaching Rust and not getting on the leaderboard or just solving the problems. I do feel that my personal setup is complicated but it doesn't feel over complicated for what I'm trying to do: which is to show how to use a variety of tools and language features both to solve the problems and gain insight into what a program is actually doing (runtime, heap usage, etc). On day 1 this will seem especially complicated because day 1 is usually close to a one-liner. It becomes more useful as the weeks go on. This setup does not suck the joy out of programming for me. I quite enjoy being able to use the additional information provided by these tools and tasks like writing tests doesn't feel like a chore to me. The part that I find tedious is, for example, when I went to set up the Tracy profiler this year. The documentation for Tracy comes as a PDF download, and none of the available client libraries seem to include documentation for how to use them. So now I have to read the whole PDF and understand a lot more before I'm even able to collect any profiling information using Tracy. That said, I know that if I ran into this problem, then other people will too, and if I found it tedious then a beginner will likely find it close to impossible... and something I *do* enjoy is figuring that tedious thing out and documenting it somewhere so people can use the tool.
I don't think he's expecting everyone to do what he's doing near the end of this video. The first part of this video has an appropriate amount of "complication" (it's really not that complicated). That looks like a very good setup if you want to use Rust to do the AoC problems. The 2nd part of this video will be interesting to look at later, and is more "software engineering" than "pure hacking fun". I can imagine him going back and showing algorithm improvements based upon issues identified in benchmarks, and it looks like he's setting it up for potential educational purposes later.
Thanks for putting together this video. I’m looking forward to improving my rust skills with AoC. The tech stack lineup you put together looks like you’ll be presenting so really cool stuff. Looking forward to the series
I was just looking into this yesterday. Thank you for the detailed guidance, really helpful!!!!!
Same here :)
Thanks for the guide! First year of trying it in Rust. Previous iterations completed in C++, however seeing your implementations from last year inspired me to become a fellow Rustacean this year! Wishing you to best of luck!
I just wanted to thank you for your effort, your time and dedication.
That's an epic setup! Thanks for showing it.
Thank you so much for such a detailed and instructive video. Although I am not smart enough to go through AoC, at least by following others journeys and learning from them I might get prepared enough to take on the challenge next year on my own. Subscribed, will try to follow through the whole series.
Cheers for the advanced guide, quite a few interesting tidbits in there!
New to rust, picking it up as a hobby. Cool to see how I could've done it better after I completed my daily. Great video!
Late to the party but I am so excited to follow this in real time this year. Last year, or 6 months ago, I followed your 2022 rust advent of code to learn rust. It was super useful! Excited for all the new inclusions this year, best advent of code channel I have found regardless of language :) .
literally exactly what i was looking for. love you man
Thank you, I trying to learing about rust lang and your video will help me a lot.
Thank you for this! I've been nervous about doing AoC in Rust, but knowing you're making these vids gives me great confidence that I'll at least be able to watch how you solved it!
Hi Cris, couldn't help myself and converted part of your setup into a cargo-generate template...you now have the first pull-request for your AoC repo if you like it.
wow, thanks! That's exactly what I wanted to do. Merged it in.
Awesome beginner advice for setting up for AoC, and I can't wait to look at your eventual "kitchen sink" workspace 👍
"..potentially do it in Rust. That means you have 25 problems.." you definitely have 26 problems right there :D
In Austria 24 problems + Rust...
Thanks for this content! I'm looking forward to finally learning some rust this year (I have been meaning to for a while now! 😅).
Question: where are test modules normally kept in a Rust package? I assume putting the tests in the source code files was done just for convenience of Advent of Code, but I'm unsure. 🙂
tests being kept next to the source code is actually *not* an advent of code specific choice! This is a totally normal thing to do in regular projects for unit tests.
Cargo supports unit tests, integration tests, examples, and doctests by default. unit tests are often handled like I have them here because they're meant to test isolated functions and such, while integration tests are typically in the tests/ directory. examples can live in the examples/ directory and even examples inside of documentation can be tested.
* doc.rust-lang.org/cargo/reference/cargo-targets.html#tests
* doc.rust-lang.org/book/ch11-03-test-organization.html
* doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html
* doc.rust-lang.org/cargo/reference/cargo-targets.html?highlight=bin#examples
Holy f, thats insane 😂 thanks for sharing
I keep coming back to watch this video. It would be nice to explain some more of the context around your personal setup, why these are good things, using virtual workspaces, doing the debugging using dhat, etc.
I see there is a video on using dhat,how to generate good benchmarks, but how it fits into the setup you chose 🤔
Yeah I could potentially do a recap video after Advent of Code about the setup, how it evolved and how different aspects worked out over the course of the days
That would be great if you could. This is very practical application of a complex setup, so seeing what worked as expected, or what you changed is useful to learn about too 👍
Holy, i woke up for this
Hey hey,
first of all thanks for the videos.
I'm new to Rust and the AOC videos have helped me a lot accelerating my learning experience.
I'm also using Linux for a while now and got very curious about the `ls`, `ps` and `where` you are using, since they are not the default.
Could you give me a hint on whats going on there?
I use nushell as my primary shell (instead of bash/zsh/etc) and the ls, etc are from there. www.nushell.sh/
Looks good! Did you consider putting your error definition and other boilerplate in a workspace-level library?
Yeah, I decided against it because I want an individual error for each day without needing to worry about breaking other days.
You read my mind
Thanks for this! What OS and Window Manager do you use? I really like the clean look you have setup.
Yabai on Mac
which editor are you using? It looks like VSCode but the theme is not familiar
its vscode with nightowl and a bunch of custom settings that modify the UI, mostly to just remove things.
Great idea to have a setup lesson. Enjoyed it. Being a non-native speaker and a Rust beginner, you speak and act a bit fast for me. Pause and Repeat is my friend.
I'm sorry this is unrelated to the content of this video, but you seem to use MacOS and I don't know you you got this look (window disposition, no border, etc). Could you please explain it ? I have something like that with Hyprland on Linux and I wanted something similar on my Mac.
I think he's using Yabai
I use yabai github.com/koekeishiya/yabai with the bsp layout and I turn window shadows off, etc.
Yabai seems really nice, thanks for the share !
Out of curiosity, why do you prefer vscode over vim? I see many Rust programmers using the latter.
more people use vscode, which makes my videos more accessible to more people.
So excited by this. I had no intention of doing AoC this year. But I'm super interested to learn better profiling techniques and curious to see how miette shapes up!
Why do part1.rs and part2.rs have to be in a bin directory?
Placing binaries in src/bin is a convention that is supported by cargo. It means that I can run them with `cargo run --bin part1` without any additional work because cargo will auto-discover them.
If they weren't in src/bin (and weren't in main.rs, which is the primary default location), then I would have to configure their location.
Basically, you can customize the location of any binaries but I chose to use the default locations.
doc.rust-lang.org/cargo/reference/cargo-targets.html
thank you!!
06:40 There is only one input each day. There is never any input2.
That being said, this looks a whole lot more involved than your setup last year. I'm kinda jealous.
I couldn't remember if there was an input2, so I set it up to work. Plus this means that I can drop random data into the two input files without messing up the other part if I'm debugging.
Its definitely more involved than last year. I thought about it and felt that having it all set up was going to be better than doing the setup ad-hoc because people would be able to see the tools being used and have some more context before I explained them when they came up.
Don't know why this kept bothering me, but line 6 in your justfile didn't have a space between +nightly and leptos
Yeah it's fixed already, but thanks for the heads up
I'm unsure if I wanna do it in Rust or Ocaml....
What color scheme are you using for VSCode?
nightowl
OP your _ls_ looks like an alias innit? Very cool looking output, what is the actual command? Not eza either I believe
I use nushell, which comes with a structured ls output that displays as a table
@@chrisbiscardi cool stuff thanks, cheereo
Should probably have spoken about how to install rust at the very start
I could have, but the instructions on the official rust site are good.
🎉
Damn what colorscheme is this? Looks like something I am looking for
The theme is Night Owl by sarah.drasner. I use it for vscode and iterm2.
What color theme are you using??
night owl
This year went away so fast.
1 file per 1 day!!
Which browser is that?
Arc
E
As a rustacean it saddens me that I didn't get a heart
Don’t you feel your setup is over complicated for something as simple as advent of code?
Sucks the joy out of programming
yes, I am focused on teaching Rust and not getting on the leaderboard or just solving the problems.
I do feel that my personal setup is complicated but it doesn't feel over complicated for what I'm trying to do: which is to show how to use a variety of tools and language features both to solve the problems and gain insight into what a program is actually doing (runtime, heap usage, etc). On day 1 this will seem especially complicated because day 1 is usually close to a one-liner. It becomes more useful as the weeks go on.
This setup does not suck the joy out of programming for me. I quite enjoy being able to use the additional information provided by these tools and tasks like writing tests doesn't feel like a chore to me.
The part that I find tedious is, for example, when I went to set up the Tracy profiler this year. The documentation for Tracy comes as a PDF download, and none of the available client libraries seem to include documentation for how to use them. So now I have to read the whole PDF and understand a lot more before I'm even able to collect any profiling information using Tracy. That said, I know that if I ran into this problem, then other people will too, and if I found it tedious then a beginner will likely find it close to impossible... and something I *do* enjoy is figuring that tedious thing out and documenting it somewhere so people can use the tool.
I don't think he's expecting everyone to do what he's doing near the end of this video. The first part of this video has an appropriate amount of "complication" (it's really not that complicated). That looks like a very good setup if you want to use Rust to do the AoC problems.
The 2nd part of this video will be interesting to look at later, and is more "software engineering" than "pure hacking fun". I can imagine him going back and showing algorithm improvements based upon issues identified in benchmarks, and it looks like he's setting it up for potential educational purposes later.