It’s random. I emailed to submit a patch ordering by popularity and adding caching, but got no answer.

EDIT: You can see for yourself how it's ordered here: https://github.com/shawwn/arc/blob/arc3.1/news.arc#L2611-L26...

This is the original code, which survived untouched till at least 2019 or so. I've wondered if they changed it since then.

The key is the (users) function:

https://github.com/shawwn/arc/blob/arc3.1/news.arc#L144-L145

This returns the keys of the profs* hash table (short for "profiles"). At the time, profs was populated each time the server restarts:

https://github.com/shawwn/arc/blob/arc3.1/news.arc#L88-L91

(dir profdir*) essentially returns an `ls` of the directory in which user profiles are stored. (Yes, they are (or were) stored to disk, not a database.) This was one reason it was hard to add a feature to rename users, which Dan somehow figured out.

So it takes the `ls` of that directory, giving a list in mostly random order, and loads them one by one, putting them into a hash table, whose iteration order is also random.

In modern times, profs* is populated in a lazy fashion whenever users post after a server reboot.

Arc uses "maptable" to iterate over a hash table, which under the hood used hash-table-for-each: https://github.com/shawwn/arc/blob/arc3.1/ac.scm#L1082

Nowadays in Racket, it probably uses hash-for-each: https://docs.racket-lang.org/reference/hashtables.html#%28de...

It does have a "try-order?" option, which gives a deterministic ordering if set. But whenever I set it, I sometimes get strange errors, at least on MacOS. Since it's disabled by default, I doubt they set it. Even if they did, it would be ordered alphabetically, which means your topcolor wouldn't be anywhere close to the top unless someone else whose name starts with "a" also set it.

I only know all this because I've spent five years updating Arc for the modern era over at https://github.com/shawwn/sparc

Past discussion: https://news.ycombinator.com/item?id=38586832