Context
This came up while discussing whether notes should be ported from shell/mise tasks to Python, Node/TypeScript, Go, or Rust.
Current take: do not big-bang port notes right now. The language is not the hard part; preserving accumulated safety behavior is.
Assessment
notes is mostly:
- git / git-crypt / rudi subprocess orchestration
- manifest and local state-file logic
- hook templates
- dirty-worktree and post-merge safety behavior
- BATS coverage around odd repository states
That can be ported, but the risk is recreating all the small edge-case protections without regressions.
Rough fit by language:
- Python: easiest port; good subprocess/file handling, but still needs a runtime.
- Node/TypeScript: workable, but no obvious advantage unless future UI/TSX integration matters.
- Go: best simple compiled-binary candidate.
- Rust: strongest correctness story, but likely overkill unless the core grows substantially.
Parked recommendation
If this becomes worth doing, prefer incremental extraction:
- keep current mise tasks as the CLI/wrapper surface;
- extract one small core executable/library for manifest/state/conflict logic;
- keep existing BATS as black-box behavior tests;
- port task-by-task only where shell complexity is actively costing us.
Do not start with a full rewrite. The current shell implementation has hard-won behavior around encrypted notes and dirty readables, and that behavior matters more than implementation language.
When to revisit
Reopen this as active work if we repeatedly lose time to shell complexity in:
- manifest/state-file conflict logic;
- post-merge/post-rebase safety behavior;
- cross-platform bash limitations;
- test harness fragility;
- packaging/runtime friction for users or agents.
Context
This came up while discussing whether
notesshould be ported from shell/mise tasks to Python, Node/TypeScript, Go, or Rust.Current take: do not big-bang port
notesright now. The language is not the hard part; preserving accumulated safety behavior is.Assessment
notesis mostly:That can be ported, but the risk is recreating all the small edge-case protections without regressions.
Rough fit by language:
Parked recommendation
If this becomes worth doing, prefer incremental extraction:
Do not start with a full rewrite. The current shell implementation has hard-won behavior around encrypted notes and dirty readables, and that behavior matters more than implementation language.
When to revisit
Reopen this as active work if we repeatedly lose time to shell complexity in: