So, towards caring for those little details in a collaborative way, how do you feel about creating a new GitHub repo, say, beancount-vnext-rfc in the beancount organization? The intention being that developers wishing to gain some clarity on what to implement can create an issue, and interested parties can comment. That way we will collect the discussion in a central place which is searchable and contains the full history of comments on each topic. GitHub issues are quite good for this, as anyone can subscribe to an issue or to the whole repo.
We have seen two instances of this being required already, regarding the new approach to inventory being taken by TurboBean, and the false-start on plugins I was investigating. It is clear that this mailing list is not going to suffice, and trying to discuss all that here is only going to annoy people who aren't interested in alternative implementations (which I concede may be most people right now). If you created the repo and gave me write access, I could set up an RFC template to try to get things going in the right direction. On Wed, 4 Mar 2026 at 15:18, Martin Blais <[email protected]> wrote: > So long a thread. > I appreciate the flowers but let's not forget the original idea is a John > Wiegley creation, I merely copied and then iterated and recreated a few > times. Simon Michael also accumulated a following with his Haskell work. > Credit where credit is due. > > Re. BDFL indeed I don't have time. I'm giving all my cycles to someone > else at the moment. (Thankfully doing lots of agentic stuff so it's not > like I have FOMO.) > > I think the idea of having unified tests is a great one but it's unlikely > to happen, people enjoy the 0 to 1 feeling mostly and this won't change > with agents. Maybe you can extract all the tests from my source code and > find a way to them across equivalent systems (see how I assert some things > in the beancount syntax itself, you don't necessarily need code, you can > create a syntax). > > The main challenge to new implementors is going to be completeness. > With the AIs zero-to-0.8 is almost instant; your enemy will be 0.8 to 1.0. > Lots of little details to care for. > > > > > On Fri, Feb 27, 2026 at 9:51 PM Justus Pendleton <[email protected]> > wrote: > >> I think it is a great idea to encourage experimentation and evolution of >> the fileformat/featureset. >> >> My feeling is that Martin probably doesn't have the bandwidth to play any >> significant BDFL-type role commenting on various proposals or shepherding >> towards consensus. So the beancount family is probably better served with >> something a bit more free-form. I could see value in a centralised >> repository where alt-beancounts could post "hey, here's what I'm trying >> out", a bit like we've seen with the various flavours of markdown over the >> years which also don't have a BDFL but have evolved in a bit more chaotic >> fashion. >> >> I think the biggest value-add at the moment would simply be some kind of >> unique number for each change from vanilla-beancount so people could talk >> about "change #12 in limabean is easier to use but less powerful than the >> similar change #26 in prolog-bean" and provide a focus for discussions like >> RFCs do. I can't imagine trying to enforce too much structure on either the >> document or the process would be very useful, simply because I imagine most >> people writing alt-beancounts aren't terribly invested in writing long >> documents in prescribed formats for what is still largely a personal >> project. >> >> But if you have more lightweight examples from smaller projects (i.e. not >> rust or python which understandably have rigorous processes) it might help >> generate more ideas. >> >> On Thursday, February 26, 2026 at 11:25:49 AM UTC+10:30 Simon Guest wrote: >> >>> The Beancount developer landscape seems to be thriving at the moment >>> with several recent announcements about new implementations. This is >>> certainly exciting, and it's great to see such creativity. >>> >>> Martin has made a huge contribution to the plain text accounting >>> community, both with the very well designed original Beancount system which >>> we all love, and also the extensive documentation and test suite. Thank >>> you indeed! These were certainly enablers for my own limabean >>> <https://github.com/tesujimath/limabean>. >>> >>> And so now times are changing, and Beancount is in some ways being >>> liberated from its Python origins. We are seeing work in Rust, Zig, >>> Clojure, and who knows what to come. Exciting times indeed! But how will >>> we avoid fragmentation? >>> >>> It is clear that in future we will have multiple implementations of >>> Beancount-like systems. That is not what I am concerned about. My >>> concerns are: >>> >>> 1. Preserving a common file format >>> >>> 2. Preserving common core behaviour >>> >>> I expect and celebrate a varied approach to user interface (Beancount >>> Query Language, Fava, or Fava-like GUI, Clojure, whatever else). This is a >>> fruitful area for exploration. So too, the plugin ecosystem will surely >>> diverge. I agree with Moritz, the author of TurboBean >>> <https://github.com/themoritz/turbobean> (cool project!) that you >>> wouldn't want to embed a Python interpreter just for plugins if you don't >>> already need it. And with limabean I am exploring the idea of not needing >>> plugins at all. >>> >>> It should be easy for users to try out different implementations, which >>> requires (1) and (2) above, and perhaps more. >>> >>> The vNext document <https://beancount.github.io/docs/beancount_v3.html> >>> has some interesting ideas, which explains TurboBean diverging with a new >>> approach to inventory. Is this the future? I would like to know, as I >>> would then have to follow along with limabean! >>> >>> What I would really like to see is some kind of RFC process, like which >>> is used for evolution of the Rust language and ecosystem. I hope that >>> Martin would like to be the BDFL for some kind of RFC-like process which >>> unifies all these parallel developments, in terms of defining core >>> behaviour, *especially where this differs from OG Beancount* (in fact, >>> probably only where it differs). >>> >>> In summary, I think we should embrace and celebrate the current >>> divergence of implementation work in the Beancount ecosystem, but take some >>> steps to mitigate the otherwise inevitable fragmentation. >>> >>> All comments welcome! >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Beancount" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/beancount/3a441c4c-5e54-4ef0-bc6d-39f7bb683923n%40googlegroups.com >> <https://groups.google.com/d/msgid/beancount/3a441c4c-5e54-4ef0-bc6d-39f7bb683923n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/beancount/CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-iEg%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-iEg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/beancount/CAFhGSbt4fY0W6dX-Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%40mail.gmail.com.
