Hayashi – an open-source DSL for applied econometrics (with a 307-page book, free)
▲ 13 r/econometrics+2 crossposts

Hayashi – an open-source DSL for applied econometrics (with a 307-page book, free)

I've been building Hayashi, a domain-specific language for applied econometrics, for the past year. It's a solo project, open-source (GPL v3), written in Rust.

The goal is a language where econometric intent reads directly from the code — no boilerplate, no package hunting, no version conflicts. Something between Stata's expressiveness and a proper programming language.

What it covers so far:

OLS, IV/2SLS, panel data (FE/RE/FD), DiD, RDD, GMM, quantile regression, logit/probit, Poisson/NB, Tobit, survival analysis (Cox/KM), PSM, synthetic control, ARMA/ARIMA, VAR, cointegration/VECM, GARCH, ARDL/ECM, Kalman filter, SUR, Lasso/Ridge, bootstrap, PCA, structural breaks, regime switching, and more.

Book: a 307-page reference manual is available in both English and Portuguese (PT-BR), covering the full language and all estimators with worked examples.

GitHub: https://github.com/sheep-farm/hayashi

Still early — v0.2.4. I'm especially looking for people willing to test it on real datasets and report what breaks. The book has a whole section on this, but real-data testers are the biggest gap right now.

Happy to answer questions about design decisions, what's planned, or why I built this instead of just writing an R package.

One practical note: Hayashi ships as a single binary — no installation wizard, no external libraries, no dependency management. Just download and run. Works on Windows, macOS, and Linux. The only exception is ODBC connectivity, which requires the system ODBC driver if you need it.

u/UnlikelyFuel5610 — 9 days ago

limine-snapper-sync corrupts default_entry in limine.conf after snapper-cleanup, causing unbootable system

Package: limine-snapper-sync (AUR)

System: Arch Linux, Omarchy setup, Btrfs + LUKS, Limine bootloader

What happened:

After a batch of package removals via pacman, the system became unbootable on next reboot. The kernel was loading a read-only Btrfs snapshot instead of the main /@ subvolume, causing systemd-remount-fs to fail with:

mount: /: fsconfig() failed: overlay: No changes allowed in reconfigure.

Root cause:

snapper-cleanup.service has a drop-in override (/usr/lib/systemd/system/snapper-cleanup.service.d/limine-snapper-override.conf) that calls limine-snapper-sync --no-force-save via ExecStopPost. After one of these cleanup runs, limine-snapper-sync rewrote /boot/limine.conf with default_entry pointing to a snapshot sub-entry instead of the main OS entry. On next boot, Limine loaded the snapshot directly — a read-only Btrfs subvolume — breaking systemd-remount-fs.

Contributing factor:

inotify-tools is not listed as a dependency of limine-snapper-sync. Without it, limine-snapper-watcher exits immediately on every boot (WARNING: inotifywait is not installed), leaving snapper-cleanup as the only trigger for syncing — a coarser, less controlled mechanism more likely to expose the bug.

Reproduction conditions:

  • Many snapshots created/removed in a short period (e.g., mass package removals triggering pre/post snapper snapshots)
  • snapper-cleanup runs afterward and calls limine-snapper-sync
  • inotifywait not installed (watcher not running persistently)
  • Expected behavior: default_entry should never be changed to point to a snapshot entry. The main OS entry must always remain the default.

Workaround:

Install inotify-tools so the watcher runs persistently and handles snapshot events in real time, reducing dependence on the cleanup-triggered sync path.

Recovery:

Manually select the correct boot entry from the Limine menu, then restore from a Btrfs snapshot.

reddit.com
u/UnlikelyFuel5610 — 26 days ago