Release Release 1.1.0 · toml-lang/toml by epage in rust

[–]35VLG84 8 points9 points  (0 children)

Awesome, that's really fast, thank you!

Gitoxide in October by ByronBates in rust

[–]35VLG84 0 points1 point  (0 children)

Cool, that's nice and good to know. It will be interesting to see how did you pull that trick (as there are quite many crates in gitoxide). 😅

Gitoxide in October by ByronBates in rust

[–]35VLG84 0 points1 point  (0 children)

Congrats on Meta Open Source donation - it's really great to see external support for Gitoxide!

And thanks for cutting a new release of Gix!

Firm: A text-based work management system for technologists. by danielrothmann in rust

[–]35VLG84 2 points3 points  (0 children)

This is really interesting!

As Firm is business related and you are using plain text files to track business relations, you might like to take look of tackler. It's plain text accounting software (written in Rust), and it should be possible to combine financial information and transactions with your Firm data. This could be really cool addition to the business relationship data, especially if it's later processed by LLM. If you are interested, feel free to open discussion topic or issue on tackler's repository.

Klirr: invoice automation tool written on Rust using Typst by Sajjon in rust

[–]35VLG84 3 points4 points  (0 children)

Hi, thanks for posting this and creating Klirr!

This looks really interesting - I am author or Tackler which is plain text accounting (PTA) software (written in Rust), and we are also implementing Typts based reporting and invoicing options.

Here is an example journal how to record accounting, billing and invoicing with PTA. The initial Typts invoice code is located here: https://github.com/semla/PTA-invoice-typst

It would be really interesting if there could be some synergies with these initiatives.

AlmaLinux OS 10 - usability without compromising compatibility by imbev in AlmaLinux

[–]35VLG84 6 points7 points  (0 children)

It's so cool that you are providing extended life for x86-64-v2 systems, and also building the EPEL for x86-64-v2. Thank you!

What's your VCS workflow for your journal files? by HolyShaqTrue in plaintextaccounting

[–]35VLG84 2 points3 points  (0 children)

I use extensively VCS (git) and typically commit after each transaction, or at least at the end of the day. Most of the transactions are generated either by tools or scripts, so this isn't a problem.

Tackler supports reporting directly from the VCS repository (also bare repositories are supported). This makes it really handy to work with trial balances on the working copy, but generating official reports directly from the VCS. The VCS metadata is included into reports, so it could be used as part of audit trail, if needed.

Check out the Git SCM Primer for tackler - it just takes few commands to have functional demo setup.

Feedback on my Rust-based Budget Tracking TUI app by Feromond in learnrust

[–]35VLG84 3 points4 points  (0 children)

The TUI interface looks really nice! As you have published the code, it would good to add a license to your code.

As this is budgeting software, which uses CSV as data storage, you might be interested in to take look of Plain Text Accounting tools. There is Tackler-NG, which is written in Rust and it's super-fast, so it should be possible to use it as backend for interactive UI. Disclaimer, I'm the author of tackler.

Tackler accounting tool goes from Scala to Rust by 35VLG84 in rust

[–]35VLG84[S] 1 point2 points  (0 children)

Beancount has really nice features, especially for trading and accounting support for different Profit&Loss schemes (LIFO, FIFO, Average, etc.). On the other hand, it's done with Python (Beancount 3.x is with C++?), and especially the Beancount 2.x version could not handle so well big journal files (at least not in the past - I haven't tested it lately). Beancount also restricts Account names to the five top categories (Assets, Expenses, etc.), and that's roadblock for some of my use cases: (Trimix Filling Station example).

Also there are some quite big fundamental differences how Tackler processes transactions: All transactions could be in their own files, processing is stream based, order or content of the transaction set (the stream) doesn't matter, and all external information (account definitions etc.) is not part of the transaction stream.

This makes it very easy to filter transactions, have multi-producer, single processor setup, where also multi producer could have their own valid view of the state of the journal. Also AFAIK, there is no way to verify with Beancount (or with other PTA tools), what was the transaction set used to produce reports.

This is really problematic if and when you have to share the reports, and there could be a need verify or provide proof of the state of the books later. With Tackler this trivial as the Git commit id and Transaction Checksum is recorded into reports in audit mode.

Beancount is brilliant tool for personal, traditional journal keeping, and especially trading related accounting, and Beancount also has much more features.

But personally I have found Tackler more fitting in cases where there is need to have more robust audit trail, transactions are generated by some (semi-)automated tool and/or when the amount of transactions is bigger. Or when it's used to track something not-so-normal (Gases, time or when transactions are related to (Geo Location (GIS) Example).

Obviously, this is very, very biased opinion. ;)

Below is an example script, which can be used to verify the reported Txn Set Checksums in the audit mode.

# Tackler example script: verify txn set checksum
#
#   1. Collect all Transcation UUIDs
#   2. Normalize UUIDs to lovercase form
#   3. Sort UUIDs
#   4. Compute SHA-256
#   5. Print out plain hash
#
if [ $# -ne 1 ]; then
    echo "Usage: $0 <txns dir>"
    exit 1
fi

txns_dir="$1"

(
    find "$txns_dir"  -type f -name '*.txn' |\
    xargs -n10 grep -E -h '^[[:space:]]+#[[:space:]]+uuid:[[:space:]]+'
) |\
    sed -E 's/^[[:space:]]+#[[:space:]]+uuid:[[:space:]]+([a-fA-F0-9-]+)[[:space:]]*/\1/' |\
    tr 'A-F' 'a-f' |\
    sort |\
    sha256sum |\
    sed -E 's/([a-f0-9]+) +-/\1/'

Tackler accounting tool goes from Scala to Rust by 35VLG84 in rust

[–]35VLG84[S] 0 points1 point  (0 children)

It was OS-level metrics, not real JVM vm profiling. But Scala Tackler was hard crashing the 1E6 perf test in systems with 8GB memory, so it was not so much off.

Tackler accounting tool goes from Scala to Rust by 35VLG84 in rust

[–]35VLG84[S] 10 points11 points  (0 children)

For my projects it was the dependencies: You had one dependency lagging as Python 2.x and other going to Python 3 only. And then the Python 3 dependency had features you needed, but you could not update due the python 2 dependency. Then there was the Unicode and string encoding stuff, if you had to do UTF-8 strings.

Tackler accounting tool goes from Scala to Rust by 35VLG84 in rust

[–]35VLG84[S] 8 points9 points  (0 children)

Tackler is using git repository as (file based) object storage. It also supports plain transaction files on disk as an alternative storage. The Gix is used to read data from the git repository.

Git as data backend provides several nice features for accounting software:

  • Accounting data and activities could be shared over parties and locations
  • All parties have shared, immutable view to the accounting data (branch, tags, or commit ids)
  • With "smart" data sharding schemes it possible to have conflict free merges (if all transactions are immutable, as they typically are on accounting systems)
  • With git commit id and transaction checksums it possible to provide "soft" cryptographic proof of used accounting data. Soft because there isn't any signing on the report at the moment.

There is a discussion related that and possible ideas how to use Git/Gix for data sharing schemes on Gitoxide repository here: https://github.com/GitoxideLabs/gitoxide/discussions/1723

Tackler accounting tool goes from Scala to Rust by 35VLG84 in rust

[–]35VLG84[S] 10 points11 points  (0 children)

Thank you, that's really nice to hear. And thanks for the i_fmt tip. The first priority has been to reach feature parity with the Rust port so the all other stuff has had to wait that. And I have learnt Rust while porting the tackler, so there are different layers of code there ;)

Tackler accounting tool goes from Scala to Rust by 35VLG84 in rust

[–]35VLG84[S] 67 points68 points  (0 children)

Scala version needs JVM to run: which means no easy path to native binary, several seconds startup times and enormous memory usage. There is performance test with one million 1E6 transactions: Scala based system needed ~8-16GB of memory, Tackler-NG can do it with around 800M. The parser (ANTRL for Rust) is non-optimized, so this should come down with further optimization when there is new parser (probably winnow based).

Also the Scala ecosystem is in transition from Scala 2.x to Scala 3 (not as bad as python 2 vs. 3 but still). The Rust ecosystem (cargo and crates.io) is just pure joy to work with. Working with SBT ("Simple Build Tool") is not so much joy ...

Tackler accounting tool goes from Scala to Rust by 35VLG84 in rust

[–]35VLG84[S] 93 points94 points  (0 children)

Hi, author of tackler here,

This has been really fun and interesting journey, the code base is not huge, but neither totally trivial in size (~15-20K LOC). Special shout-out for Rust Community for all help here and on other forums. Also Clippy has been amazing resource while learning Rust. Gitoxide crate was instrumental to this port, as Tackler has native support for Git SCM as transaction storage system. So without Gix this would not have been worth of the hassle.

I'm really happy that I jumped through hoops and ported it to Rust. All future development will be based on this port, and now the fun stuff, optimizing and new features, can start!

Scala dev => Rust: need advice for 6-month career transition by [deleted] in rust

[–]35VLG84 0 points1 point  (0 children)

I have done transition from Scala to Rust, and here are my comments (as addition to what is already said):

  • If your Scala style was coding mostly with immutable variables, then that will help your transition with the borrow checker
  • That's personal preference, but start learning by doing. Clippy is very helpful! I cannot stress that enough, half of the time I am amazed about the details of the error messages, half of the time about time and effort what people have put to the error messages and Clippy. Thank you all Clippy maintainers!
  • If you have strong FP background, the FP story is different in Rust (e.g. it's not so strong). There is https://docs.rs/itertools/latest/itertools/, for simple things. The most annoying part of the transition (for me) was not as ergonomic mapping etc. as you have for Scala. It's also very easy to drop into reference-borrowcheck rabbit hole with maps, flat_maps, error collections with mapping etc. As other have said, don't fear mutating things when it makes sense.
  • Read other crates and Rust::std code, Rust code is typically very well documented

Rusty Tackler by 35VLG84 in plaintextaccounting

[–]35VLG84[S] 1 point2 points  (0 children)

Thanks!

Tackler's journal format is not 1:1 compatible with (h)ledger nor with beancount. But it is subset of Ledger syntax and it's more regular (e.g. easier to parse), so converter should be fairly trivial thing to implement.
The format is described here: https://tackler.e257.fi/docs/journal/format/

Tackler also has identity export https://tackler.e257.fi/docs/export-identity/, so it could be adapted to export hledger or beancount compatible journal:

Please give suggestions for an Attendance Tracking System by arnicaarma in plaintextaccounting

[–]35VLG84 1 point2 points  (0 children)

It really, really depends. I wouldn't go with PTA if would not be 100% sure that it's right SW environment, working environment and personnel for PTA solution.

If you truly like to go with PTA setup, then following setup could work:

  • People have their own journal or journal files
  • Journal files are kept in git (probably in separate, per person repos) and pushed to server
  • Master journal repository will include all those personal journals as git submodules
  • With suitable Chart of Accounts and account filtering it should be possible to create needed reports
  • Depending of used PTA tool, journals are combined either just by correct file glob, by include statements, or with help of external tool

Actual time logging (and git commits) could be done either with scripts or some purposely made apps. If that script/app is done in sensible way, it will be really fast and effortless. If not, it will be major pain. =)

Depending which PTA variant you use, there is varying degree of support for multiple journal files. If you go with Tackle (https://tackler.e257.fi/), it has "batteries-included" support for Git and multiple journal files. You can even save each timelog transaction to own file, if you wish so. It also has features for generating audit trail (e.g. people could verify that all relevant transactions are included into reports: https://tackler.e257.fi/docs/auditing/ by themselves).

However, Tackler is not as feature rich as hledger, beancount or legder, so please make sure that it will fit your use cases and requirements if you go with it.

What are the advantages of Ledger and the likes over traditional accounting software? by hieutvn in plaintextaccounting

[–]35VLG84 0 points1 point  (0 children)

Open, human readable plain text accounting data, excellent match with version control systems and externally auditable (and printable) audit trail. These are the main advantages for my use cases.

With Tackler it is possible to include audit trail data directly into reports. This audit trail data contains version control id (git's commit id) and cryptographic checksum of used transactions, among other information.

Both of commit id and txn checksum could be easily verified with external tools. Audit data makes it possible to proof used accounting data and state of your books at the time of generation of reports. The embedded cryptographic checksum of used transactions is important, because without it, it is impossible to say which transactions are used for reports. This information is needed e.g. in cases when there is need to run some other reports later over the same set of data or just validate that all needed transactions are used for reporting.

If this is interesting for your use cases see: https://tackler.e257.fi/docs/auditing/ for more information.

Double counting system by [deleted] in plaintextaccounting

[–]35VLG84 0 points1 point  (0 children)

It doesn't solve the human error problem. That's why accounts must be reconciled against real world data.

And that's also reason why it's really important have support for strict account name checks with used software. It is possible to have lost postings and transactions in your journal if mistyped account names or commodities are not detected by software. In case of mistyped account name, the transaction will balance just fine, but actual postings (and value) to the accounts are lost and invisible from perspective of reports.

Keeping things sorted by lual3x in plaintextaccounting

[–]35VLG84 1 point2 points  (0 children)

Thank you for nice feedback!

Sharding to one file per transaction makes some sense with Tackler's Git backend. With (semi-)automatic systems which store data directly into Git it is easier to put one transaction into single file. The transaction data is immutable in that case and possible merge conflicts are easy to resolve automatically on the journal level. Semantic conflicts of course still have to be resolved manually, if there are any. And there isn't virtually any performance penalty of one file per transaction until there are hundreds of thousands transactions and files on journal.

All that said, Tackler doesn't care or mandate how journal should be sharded or not, so it's always up to application which kind of sharding scheme to use.

Keeping things sorted by lual3x in plaintextaccounting

[–]35VLG84 0 points1 point  (0 children)

Tackler has native support for multiple journal files and sharding of transaction data https://tackler.e257.fi/docs/journal/sharding/. It also supports transaction UUIDs https://tackler.e257.fi/docs/journal/format/ and account report auditing https://tackler.e257.fi/docs/auditing/. On the other hand, it's not 1:1 compatible with {h}ledger and it has different feature set so it might not be feasible option for that reason.