Advent of Code 2023 had 227 solutions published by 31 programmers. Anyone cool has moved to Uiua, and also Github's new search leaves out tons of repositories so I can't find them as well as I did before. Below, problems solved in BQN are shown in green, and problems solved in other languages in faint red. Each name links to the repository where these are published.
The number of BQN solutions for each of the 25 days is plotted below, along with totals from AoC's stats page. The BQN solutions are scaled to be visible here: there are 7931 times more valid AoC submissions than published BQN solutions overall.
Advent of Code 2022 was about twice the BQN event that 2021 was, with 406 solutions published by 46 programmers. Below, problems solved in BQN are shown in green, and problems solved in other languages in faint red. Each name links to the repository where these are published.
The number of BQN solutions for each of the 25 days is plotted below, along with totals from AoC's stats page. The BQN solutions are scaled to be visible here: there are 4842 times more valid AoC submissions than published BQN solutions overall.
Advent of Code 2021 saw great participation by the BQN community, with a total of 234 solutions published by 22 programmers. They can be found in these repositories:
dzaima • Hannu Hartikainen • Raghu Ranganathan • frasiyav • Leah Neukirchen • Antti Keränen • Caleb Quilley • Alvin Voo • Alex Dikelsky • Andrey Popp • Johnny • Josh Holland • Ben Dean • Alastair Williams • Olodus • Aren Windham • Dimitri Lozeve • Alexander Wood • Mathias Magnusson • m-lima • Dunya Kirkali • Benjamin Applegate
Below, problems solved in BQN are shown in green, and problems solved in other languages in faint red.
Some wrote about aspects of the Advent experience: Leah explained her solutions for day 6 and day 9, Hannu reflected on the choice of BQN, and Raghu commented on each problem.
The number of BQN solutions for each of the 25 days is plotted below, along with totals from AoC's stats page. The BQN solutions are scaled to be visible here: there are 6827 times more valid AoC submissions than published BQN solutions overall.
The BQN counts fall off much less than the average. Most likely this is because programmers who decide to try AoC in a crazy new language like BQN tend to be more committed to the task, but BQN also has to meet some minimum bar to enable these crazy people to continue.
Just how okay is BQN? Hannu made the case for optimism. Hannu writes that BQN's slogan "might be the best [further glowing praise/context]", in stark contrast to that time Bryce and Conor agreed that it was a bad slogan. And Andrey offers suspiciously positive comments as well. The list includes "good text editor support", but Johnny remarked on the forums that he didn't manage a good editor/REPL setup—a second contradiction, meaning that I can now prove the Riemann hypothesis in two independent ways. Johnny also cited little support for string handling and low-information error messages as obstacles. I like that these aren't tied to the core language, and can eventually be improved, even though it won't be easy. dzaima complained about frequent confusion between functions and immediate blocks, and right-to-left folds being the much less useful direction. I dislike that dzaima is right a lot.
All three non-dzaimas of the last paragraph are essentially array outsiders, with little or no experience with languages like J or APL. In fact I think this describes the majority of Adventurers in BQN (although the list also includes array junkies like Raghu and Leah, and they've predictably made it further than most participants). Reaching out to a general programming audience wasn't initially a goal of BQN because I didn't think it was within reach. I realized this was wrong, and began to adjust course, in the early days, but am pleased to continue getting even more wrong.
With all this said, a handful of reports about recreational programming is a pretty poor basis for judging a programming language. Advent of Code was more useful as a checkup on BQN and its environment, resulting in fixes to documentation and implementation. And dzaima improved various aspects of performance as a way to cheat in speed battles with ngn/k.
BQN did do okay in terms of performance. At times programmers on the forum commented about having slow solutions (tens of seconds) or having to rewrite an obviously unsatisfactory algorithm. I don't think anyone mentioned having to switch languages for performance reasons, which is good news for an implementation as young as CBQN. But also not a surprise, as it's pretty fast with scalar code for an interpreter: about 10 times slower than C when I've measured it. Array code is usually faster, but can be slower. A particular problem was that in-place mutation ⌾(i⊸⊑) is only fast for very simple cases. Of course, this problem only arises because BQN's arrays are immutable, highlighting that immutable arrays, despite being perfect in every way, can be a pain. In a serious application you might be willing to endure more pain and use a mutable array object, to ensure good performance.