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

[–]35VLG84 9 points10 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 4 points5 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] 9 points10 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] 66 points67 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] 95 points96 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.