Something like this would be great to have! I am struggling a lot trying to evolve the file format and behavior along the lines of vNext while trying to keep things compatible. It would be good to have an evolving implementation-independent spec of the Beancount language that I could then just test against.
On Thursday, February 26, 2026 at 1:55:49 PM UTC+13 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/8571cc39-bf50-4b29-ba61-87a22c00cab6n%40googlegroups.com.
