logoalt Hacker News

fainpultoday at 1:59 PM35 repliesview on HN

Opinion poll:

Python is extremely suitable for these kind of problems. C++ is also often used, especially by competitive programmers.

Which "non-mainstream" or even obscure languages are also well suited for AoC? Please list your weapon of choice and a short statement why it's well suited (not why you like it, why it's good for AoC).


Replies

sunrunnertoday at 2:13 PM

My favourite "non-mainstream" languages are, depending on my mood at the time, either:

- Array languages such as K or Uiua. Why they're good for AoC: Great for showing off, no-one else can read your solution (including yourself a few days later), good for earlier days that might not feel as challenging

- Raw-dogging it by creating a Game Boy ROM in ASM (for the Game Boy's 'Z80-ish' Sharp LR35902). Why it's good for AoC: All of the above, you've got too much free time on your hands

Just kidding, I use Clojure or Python, and you can pry itertools from my cold, dead hands.

nemo1618today at 3:18 PM

I made my own, with a Haskell+Bash flavor and a REPL that reloads with each keystroke: https://www.youtube.com/watch?v=r99-nzGDapg

This year I've been working on a bytecode compiler for it, which has been a nice challenge. :)

When I want to get on the leaderboard, though, I use Go. I definitely felt a bit handicapped by the extra typing and lack of 'import solution' (compared to Python), but with an ever-growing 'utils' package and Go's fast compile times, you can still be competitive. I am very proud of my 1st place finish on Day 19 2022, and I credit it to Go's execution speed, which made my brute-force-with-heuristics approach just fast enough to be viable.

show 1 reply
WJWtoday at 2:51 PM

I like to use Haskell, because parser combinators usually make the input parsing aspect of the puzzles extremely straightforward. In addition, the focus of the language on laziness and recursion can lead to some very concise yet idiomatic solutions.

Example: find the first example for when this "game of life" variant has more than 1000 cells in the "alive" state.

Solution: generate infinite list of all states and iterate over them until you find one with >= 1000 alive cells.

    let allStates = iterate nextState beginState # infinite list of consecutive solutions
    let solution = head $ dropWhile (\currentState -> numAliveCells currentState < 1000) allStates
show 3 replies
shaknatoday at 2:06 PM

I've always done it in a Scheme. Generally to learn a new compiler and its quirks.

Scheme is fairly well suited to both general programming, and abstract math, which tends to be a good fit for AoC.

encomiasttoday at 2:05 PM

It was mind-boggling to see SQL solutions last year: https://news.ycombinator.com/item?id=42577736

show 1 reply
matsemanntoday at 4:31 PM

I use python at work but code these in kotlin. The stdlib for lists is very comprehensive, and the syntax is sweet. So easy to make a chain of map, filter and some reduction or nice util (foldr, zipwithnext, windowed etc). Flows very well with my thought process, where in python I feel list comprehensions are the wrong order, lambdas are weak etc.

I write most as pure functional/immutable code unless a problem calls for speed. And with extension functions I've made over the years and a small library (like 2d vectors or grid utils) it's quite nice to work with. Like, if I have a 2D list (List<List<E>>), and my 2d vec, like a = IntVec(5,3), I can do myList[a] and get the element due to an operator overload extension on list-lists.

and with my own utils and extension functions added over years of competitive programming (like it's very fluent

auxymtoday at 5:28 PM

I've had a lot of fun using Nim for AOC for many years. Once you're familiar with the language and std lib, its almost as fast to write as python, but much faster (Nim compiles to C, which then gets compiled to your executable). This means that sometimes, if your solution isn't perfect in terms of algorithmic complexity, waiting a few minutes can still save you (waiting 5 mins for your slow Nim code is OK, waiting 5 hours for your slow Python isn't really, for me). Of course all problems have a solution that can run in seconds even in Python, but sometimes it's not the one I figure out first try.

Downsides: The debugging situation is pretty bad (hope you like printf debugging), smaller community means smaller package ecosystem and fewer reference solutions to look up if you're stuck or looking for interesting alternative ideas after solving a problem on your own, but there's still quality stuff out there.

Though personally I'm thinking of trying Go this year, just for fun and learning something new.

Edit: also a static type system can save you from a few stupid bugs that you then spend 15 minutes tracking down because you added a "15" to your list without converting it to an int first or something like that.

jlouistoday at 2:27 PM

Go is strong. You get something where writing a solution doesn't take too much time, you get a type system, you can brute-force problems, and the usual mind-numbing boring data-manipulation handling fits well into the standard tools.

OCaml is strong too. Stellar type system, fast execution and sane semantics unlike like 99% of all programming languages. If you want to create elegant solutions to problems, it's a good language.

For both, I recommend coming prepared. Set up a scaffold and create a toolbox which matches the typical problems you see in AoC. There's bound to be a 2d grid among the problems, and you need an implementation. If it can handle out-of-bounds access gracefully, things are often much easier, and so on. You don't want to hammer the head against the wall not solving the problem, but solving parsing problems. Having a combinator-parser library already in the project will help, for instance.

show 1 reply
andriamanitratoday at 5:37 PM

I think Ruby is the ideal language for AoC:

* The expressive syntax helps keep the solutions short.

* It has extensive standard library with tons of handy methods for AoC style problems: Enumerable#each_cons, Enumerable#each_slice, Array#transpose, Array#permutation, ...

* The bundled "prime" gem (for generating primes, checking primality, and prime factorization) comes in handy for at least a few of problems each year.

* The tools for parsing inputs and string manipulation are a bit more ergonomic than what you get even in Python: first class regular expression syntax, String#scan, String#[], Regexp::union, ...

* You can easily build your solution step-by-step by chaining method calls. I would typically start with `p File.readlines("input.txt")` and keep executing the script after adding each new method call so I can inspect the intermediate results.

AstroBentoday at 5:32 PM

This question is really confusing to me because the point of AoC is the fun and experience of it

So.. a language that you're interested in or like?

Reminds me of "gamers will optimize the fun out of a game"

I'm pretty clojure-curious so might mess around with doing it in that

marc_omoraintoday at 2:30 PM

Clojure works really well for AOC.

A lot of the problems involve manipulating sets and maps, which Clojure makes really straightforward.

show 1 reply
bhollantoday at 2:37 PM

I used MATLAB last year while I was re-learning it for work. It did okay, but we didn't have a license for the Image Processing Toolbox, which has a boatload of tools for the grid based problems.

infamousclydetoday at 2:15 PM

I’ve always used AoC as my jump-off point for new languages. I was thinking about using Gleam this year! I wish I had more profound reasons, but the pipeline syntax is intriguing and I just want to give it a whirl.

show 1 reply
rootnod3today at 2:38 PM

My personal choice is always Common Lisp. Absolute swiss army knife.

show 1 reply
incognito124today at 3:55 PM

If I remember correctly, one of the competitive programming experts from the global leaderboard made his own language, specifically tailored to help solve AoC problems:

https://github.com/betaveros/noulith

show 1 reply
taolsontoday at 4:09 PM

AoC has been a highlight of the season for me since the beginning in 2015. I experimented with many languages over the years, zeroing in on Haskell, then Miranda as my language of choice. Finally, I decided to write my own language to do AoC, and created Admiran (based upon Miranda and other lazy, pure, functional languages) with its own self-hosted compiler and library of functional data structures that are useful in AoC puzzles:

https://github.com/taolson/Admiran https://github.com/taolson/advent-of-code

mrkaye97today at 4:16 PM

I've been using Elixir, which has been wonderful, mostly because of how amazing the built in `Enum` library is for working on lists and maps (since the majority of AoC problems are list / map processing problems, at least for the first while)

show 1 reply
andrelaszlotoday at 5:59 PM

I think Crystal, Nim, Julia and F# were my favorites from last year's AoC

I wrote a bit more about it here https://laszlo.nu/blog/advent-of-code-2024.html

AoC is a great opportunity for exploring languages!

tonyedgecombetoday at 7:34 PM

I think that whatever you know well is the best choice.

natrystoday at 3:19 PM

I am going to try and stick with Prolog as much as I can this year. Plenty of problems involve a lot of parsing and searching, both could be expressed declaratively in Prolog and it just works (though you do have to keep the execution model in mind).

makerofthingstoday at 6:00 PM

Another vote for Haskell. It’s fun and the parsing bit is easy. I do struggle with some of the 2d map style questions which are simpler in a mutable 2d array in c++. It’s sometimes hard to write throwaway code in Haskell!

fainpultoday at 2:08 PM

For some grid based problems, I think spreadsheets are very powerful and under-appreciated.

The spatial and functional problem solving makes it easy to reason about how a single cell is calculated. Then simply apply that logic to all cells to come up with the solution.

sevenseacattoday at 2:56 PM

I've been using Elixir since day one, and it works pretty well :)

show 1 reply
vharucktoday at 4:45 PM

I've done some of the problems in R. Vectorized-by-default can avoid a lot of boilerplate. And for problems that aren't in R's happy path, I learn how to optimize in the language. And then I try to make those optimizations non-hideous to read.

show 1 reply
keithlfrosttoday at 3:39 PM

Elixir Livebook is my tool of choice for Advent of Code. The language is well-suited for the puzzles, I can write some Markdown if I need to record some algebra or my thought process, the notebook format serves as a REPL for instant code testing, and if the solution doesn't fit neatly into an executable form, I can write up my manual steps as well.

riffrafftoday at 2:29 PM

I usually do it with ruby with is well suite just like python, but last year I did it with Elixir.

I think it lends itself very well to the problem set, the language is very expressive, the standard library is extensive, you can solve most things functionally with no state at all. Yet, you can use global state for things like memoization without having to rewrite all your functions so that's nice too.

Alex_L_Woodtoday at 5:14 PM

Not sure if Kotlin is non-mainstream, but being able to use the vast Java libraries choice and a much nicer syntax are great boons.

christophilustoday at 5:44 PM

I’d say Clojure because it has great data manipulation utilities baked into the standard library.

azkalamtoday at 4:47 PM

Terse languages with great collection functions in the standard libraries and tail call optimization. Haskell, OCaml, F# ...

4pkjaitoday at 2:05 PM

Kotlin, because it’s a language I like

show 1 reply
yxhuvudtoday at 4:52 PM

Crystal. Expressiveness and get-shit-done ability similar to the one of Ruby while being way faster in execution.

yoyohello13today at 4:24 PM

Haskell is my favorite for advent of code. Finally give me an opportunity to think in a pure functional way.

f1shytoday at 2:04 PM

I’ve been doing them is JS and Common Lisp. I recommend the problems to help learning new languages.

show 1 reply