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>.
