Posted by OlaProis 21 hours ago
Built a Markdown editor using Rust + egui. v0.2.1 just dropped with major Mermaid improvements:
→ Native Mermaid diagrams - Flowcharts, sequence, state, ER, git graphs - pure Rust, no JS
→ Split view - Raw + rendered side-by-side with sync scrolling
→ Syntax highlighting - 40+ languages with large file optimization
→ JSON/YAML/TOML tree viewer - Structured editing with expand/collapse
→ Git integration - File tree shows modified/staged/untracked status
Also: minimap, zen mode, auto-save, session restore, code folding indicators.
~15MB binary, instant startup. Windows/Linux/macOS.
GitHub: https://github.com/OlaProeis/Ferrite
v0.2.2 coming soon with performance improvements for large files. Looking for feedback!
>Now is the time for all good men to come to the aid of their party. >test
and selected the last and made it bold using the formatting bar.
I recently switched from Obsidian to Zettlr due to some rendering and performance issues on Linux, and it's been a great experience. However, I always like to see new entrants in the arena.
Options considered: - KaTeX/MathJax-style rendering (would need a Rust math renderer or JS bridge) - Typst integration (Rust-native, modern alternative to LaTeX) - External tool pipeline (render via pandoc/LaTeX CLI)
Typst is interesting since it's also Rust-based and simpler than full LaTeX. Would inline math ($x^2$) and display math ($$...$$) cover your use case, or do you need full document features?
Added to the roadmap consideration list. Thanks for the feedback!
For v0.3.0's standalone crate, I'm considering whether to expose layout hints. What specific use case do you have — documentation, architecture diagrams?
For privacy, you're in the right place — Ferrite's Mermaid rendering is 100% native Rust, no JavaScript, no external services, no network calls. All ~6000 lines of diagram rendering happen locally. We're even planning to extract this as a standalone crate so others can use it.
The name collision is unfortunate. We picked "Ferrite" for the magnetic/persistent storage connotation (ferrite cores were early computer memory). Different domain (text editor vs audio), different platforms (desktop vs iOS), but I understand the SEO/discoverability concern.
Open to suggestions if the community feels strongly about a rename! Though at this stage, with GitHub issues, releases, and now HN discussion, there's some established presence.
I love the new era of graphical applications in Rust.
A few thoughts: - Obsidian's plugin system is JavaScript-based, which makes sense for Electron. For a native Rust app, we'd likely want something like WASM plugins or Lua scripting. - v0.3.0 includes plans to extract the Mermaid renderer as a standalone crate and potentially the editor widget as a library — this modular architecture would be a foundation for future extensibility.
What kinds of plugins would you want? Knowing specific use cases would help prioritize. Custom renderers? File format converters? External tool integrations?
In the meantime, Ferrite has a "Live Pipeline" feature that lets you pipe JSON/YAML through shell commands (jq, yq, etc.) — not a full plugin system, but useful for custom transformations.
*Fix:* I've updated the CI to build on Ubuntu 22.04, which will make the .deb compatible with 22.04+.
This will be included in v0.2.2. For now, workarounds: 1. Use the `ferrite-linux-x64.tar.gz` (standalone binary) instead of .deb 2. Build from source: `cargo build --release`
Sorry for the inconvenience!
That said, to be fully transparent: as I disclosed elsewhere in this thread, the Ferrite codebase is 100% AI-generated (Claude via Cursor). I direct the development, test, and iterate, but I haven't written the Rust by hand for this project.
So my Rust experience is more "ecosystem familiarity + reading AI-generated code" than "battle-hardened Rustacean." This project is partly a learning exercise — seeing how far AI-assisted development can go while picking up Rust patterns along the way.
Thanks for posting the GitHub issue!