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]> wrote: > On Tue, Mar 3, 2026 at 10:58 PM 'Simon Guest' via Beancount < > [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]> 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 >> <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]. > 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]. To view this discussion visit https://groups.google.com/d/msgid/beancount/CAFhGSbveq8AWX-SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%40mail.gmail.com.
