Re-implement ikiwiki, or something like it, in go. See how much the language's features and philosophy colour the design. In particular I'm wondering how much the first-class treatment of concurrency might change how you structure things: one thread per page, or hot pages... you'd want to approach it with lots of micro-locks rather than one big lock to rule them all. I can see some future ikiwiki refactoring work being a bit like the Linux Kernel's efforts to get rid of their big kernel lock.

See also: Joey's proposed Haskell ikiwiki rewrite. I may be remembering wrong, but I thought he had some beginning code up somewhere. Perhaps I'm conflating it with John Goerzen's one-time OfflineIMAP rewrite, which might also be lost to the sands of time...


comment 1
There is a big ikiwiki lock indeed, and it's increasingly grating, but I don't much fancy a BKL style removal.. too long and too much work. :)
Comment by Joey Hess,