[abound]

It's usually not concurrency FWIW, it's almost always algorithmic in nature. On a modern machine, even highly concurrent* code would only execute 10-20x as fast and you could just wait a bit.

One common AoC trick is that you can brute-force part one (e.g. O(n^2) complexity or worse), but part two scales up `n` to make that intractable.

*ignore my sloppy conflating of concurrency and parallelism

[Jtsummers]

I agree with you. I don't think either concurrency or parallelism have ever been necessary. In 2019 with Intcode, it was the simplest approach (use multiple threads, one per VM) for a couple days, but it was never actually necessary. You could do the same thing with purely sequential code, but you had to juggle the state of multiple running systems yourself then. Threads were much easier (or coroutines, go routines, processes, etc.; some concurrency system).

And by design, every problem is solvable on decade old computers in a reasonable amount of time (seconds) so parallelism is great if you're looking to minimize the runtime, but it's never necessary.

[codr7]

I very much enjoy the cat and mouse game of assumptions regarding part 2, it always makes me happy when the second part is just a simple adaptation of the existing solution.