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.
