it all fit in int64 tho, so could be worse
Advent Of Code
An unofficial home for the advent of code community on programming.dev! Other challenges are also welcome!
Advent of Code is an annual Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.
Everybody Codes is another collection of programming puzzles with seasonal events.
EC 2025
AoC 2025
Solution Threads
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 |
Rules/Guidelines
- Follow the programming.dev instance rules
- Keep all content related to advent of code in some way
- If what youre posting relates to a day, put in brackets the year and then day number in front of the post title (e.g. [2024 Day 10])
- When an event is running, keep solutions in the solution megathread to avoid the community getting spammed with posts
Relevant Communities
Relevant Links
Credits
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
console.log('Hello World')
I always have this thought. I'm doing it in Rust, so I check if there are negative numbers: if not, use usize. But I'm always terrified there will be an overflow somewhere.
If I were using Kotlin or Java, I might always use BigInteger just out of fear.
That’s a very interesting thought! I was thinking of writing my own Rust data type that would automatically upgrade to big integer, similarly to the int type in Python.
I am doing AOC in Kotlin. Longs are fine. I haven't encountered a puzzle that required ULong or BigInteger.
Considered sticking all the values in a set. Considered input. Coalesced the ranges instead. Ran both parts in 0.1 ms.
I'm actually looking forward a bit to 12 days this year. Previous AOC took a bit long to ramp up. Am expecting recursion imminently, dynamic programming next week, and complete head scratching bastardry to round out the week.