Yes indeed, there have been a whole host of Beancount-like systems appearing recently. Here's to a good collaboration over the nuances of how they should behave! 🍻
On Thu, 5 Mar 2026 at 15:15, Simon Guest <[email protected]> wrote: > OK, let's not do that then. Sadly I do think you're both right. > > It seems like the best we can do is for all the next-generation Beancount > developers to pay attention here and discuss their ideas on this list. > Hopefully this won't be too annoying for the majority of people who may not > be that interested. But I suspect the volume will be quite low. And at > least anything contentious will get the opportunity of feedback from a > wider audience. > > cheers, > Simon > > On Thu, 5 Mar 2026 at 14:53, Simon Michael <[email protected]> wrote: > >> I also think it won't work, if the idea is for everyone to work together >> in that repo. There just isn't enough incentive to get people >> consistently allocating time to that. >> >> If there's one rather active person absorbing and curating and editing >> ideas from the ecosystem, that might work. Or possible 2-3 active >> people. What would help sustain the motivation for this ? >> >> >> >> On 2026-03-04 14:17, 'Simon Guest' via Beancount wrote: >> > Well, if you think it won't work then perhaps it's not a good idea! >> > >> > Are you thinking there is insufficient interest in the community for >> > refining such ideas collaboratively? If that really is the case then I >> > fear we are doomed to suffer from fragmentation, as different people go >> > off with their own ideas in different directions, and we lose a >> coherent >> > vision for what it means to be a Beancount implementation. >> > >> > Or did you see a different problem? >> > >> > On Thu, 5 Mar 2026, 2:10 am Martin Blais, <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > On Tue, Mar 3, 2026 at 10:58 PM 'Simon Guest' via Beancount >> > <[email protected] <mailto:[email protected]>> >> wrote: >> > >> > 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. >> > >> > >> > I don't mind creating beancount-rfc but I think it won't work. >> > >> > >> > 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. >> > >> > >> > Sure, I can do this over the weekend >> > >> > >> > >> > On Wed, 4 Mar 2026 at 15:18, Martin Blais <[email protected] >> > <mailto:[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] <mailto:[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] >> > <mailto:[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] >> > <mailto:[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] >> > <mailto:[email protected]>. >> > To view this discussion visit >> https://groups.google.com/d/msgid/ >> > beancount/CAFhGSbt4fY0W6dX- >> > Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%40mail.gmail.com <https:// >> > groups.google.com/d/msgid/beancount/CAFhGSbt4fY0W6dX- >> > Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%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] >> > <mailto:[email protected]>. >> > To view this discussion visit https://groups.google.com/d/msgid/ >> > beancount/CAK21%2BhN33-5u0hb8d7%3DVOo- >> > LXczMHjV59GzDb03S6gajze2CWw%40mail.gmail.com <https:// >> > groups.google.com/d/msgid/beancount/CAK21%2BhN33-5u0hb8d7%3DVOo- >> > LXczMHjV59GzDb03S6gajze2CWw%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] >> > <mailto:[email protected]>. >> > To view this discussion visit https://groups.google.com/d/msgid/ >> > beancount/CAFhGSbveq8AWX- >> > SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%40mail.gmail.com <https:// >> > groups.google.com/d/msgid/beancount/CAFhGSbveq8AWX- >> > SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%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/0ce244dd-6b4f-454c-aa58-d6dd1bc92448%40joyful.com >> . >> > -- 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/CAFhGSbtAK-sAD6tPsU-H0-gbKcnW_-N9e4c3ff0UOn1BMjgAwg%40mail.gmail.com.
