I’ve considered Mercury and Picat this year but I don’t want to go without regex and/or associative arrays. Also Mercury seems moreso about performance than semantics.<p>I think it’s Prolog for me again this year but with an effort to complete the problems in a more “Prologesque” way.
Last year I had just started learning Rust so used that. That turned out to be a mistake, I was spending most of my time figuring out what the borrow checker was complaining about rather than looking at the actual problems.<p>Hopefully that's behind me now so I will use Rust again.
<a href="https://github.com/betaveros/noulith">https://github.com/betaveros/noulith</a><p>Designing a programming language to speedrun Advent of Code: <a href="https://hw.leftium.com/#/item/38255808" rel="nofollow">https://hw.leftium.com/#/item/38255808</a><p>> I did not design and implement a programming language for the sole or even primary purpose of leaderboarding on Advent of Code. It just turned out that the programming language I was working on fit the task remarkably well.<p>-- "betaveros, the guy who won 1st place in Advent of Code every single year since 2019"
I'm working on the Enso programming language (<a href="https://github.com/enso-org/enso">https://github.com/enso-org/enso</a>), so I will be trying to solve the challenges in the Enso Analytics tool, as our team has been doing for the last two years.<p>It's always fun to see how we progressed since the previous challenge, making it more pleasant to work with (and also see where the rough corners still are).
I’m ready to give zig another try.<p>gleam was a lot of fun last year, for those who are gleam curious.<p>For those who are doing something like protocol hackers, instead of adventure code, ocaml 5+ with effects was super fun
I didn't do it last year, but the years before I used Racket and Common Lisp. I might try Common Lisp again since I really want to rediscover the experience of programming w/ Sly (a fork of SLIME).<p>I'm also considering trying to solve everything with Z3.
I will this year try to be the "support team" for those that will try to do AoC in <a href="https://ryelang.org" rel="nofollow">https://ryelang.org</a>. At least one person said on X.com that he will use it, so we will see :)
I’ve been wanting to play with Kotlin or Ruby.<p>Kotlin/Closure are more attractive because of their multi-platform support, but Ruby has RoR, but the code looks cleaner which is nice.
I've experimented over time with the AoC with different languages, but I've found that it made the actual problem solving a lot more difficult for me.<p>I've done Rust, Go, Python, and TypeScript, and I've preferred Python and TS because I can just crank out some code and get something going. Rust was actually pretty good too, but Go was a bit more verbose than I wanted for something quick and dirty.
I used Common Lisp as my primary language for 2015-2022 and Python for 2023. I've used a few other languages along the way, in parallel to my main effort: Rust, Ada, Python, C++.<p>I'll probably just use Python this year, so many things are "baked in" to the language that it's the most straightforward. Only downside really is performance, but if you need high performance compiled code for Advent of Code problems you've generally not solved the problem efficiently.
Will be doing it in F# this year. Last year I did C#/Rust split until real life took over and they ended up being too similar to each other at solving AoC type of challenges.
I watched somebody on YouTube solve some AoC problems in Excel, so I’m going to try that this year. Not sure how far I’m going to get, but it’ll be a fun challenge!
Python. I like to code in Go, but I find Python the easiest for small things I'll only use once.<p>I used C to do some of the old ones. That was painful (I was a complete C beginner).