[HN Gopher] Show HN: Ferrite - Markdown editor in Rust with nati...
___________________________________________________________________
Show HN: Ferrite - Markdown editor in Rust with native Mermaid
diagram rendering
Ferrite: Fast Markdown/Text/Code editor in Rust with native Mermaid
diagrams 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!
Author : OlaProis
Score : 224 points
Date : 2026-01-11 01:50 UTC (21 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pbronez wrote:
| Is mermaid rendering implemented in Rust, or are you running
| mermaid.js in a JS interpreter somewhere?
|
| On other systems I've run into challenges rendering markdown
| documents with many mermaid diagrams in them. It would be nice to
| have a more robust way to do this.
| lkschubert8 wrote:
| Looks like it's currently a subset of mermaid natively in rust
| https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
| jasonjmcghee wrote:
| (not associated, just looked at the code - no js interpreter)
|
| https://github.com/OlaProeis/Ferrite/blob/master/src/markdow...
| OlaProis wrote:
| 100% pure Rust! No JS interpreter. Parses Mermaid syntax
| directly and renders via egui drawing primitives. Supports 11
| diagram types: flowchart, sequence, state, class, ER, pie,
| mindmap, timeline, user journey, git graph, gantt. Much faster
| than spawning headless Chrome!
| Arubis wrote:
| I happily paid money for Typora, which does roughly the same
| thing for just Markdown without support for JSON, Yaml (that I
| know of). This feels like a ripe space, especially with LLMs
| eagerly outputting reams of parseable text with embedded
| diagrams.
| vunderba wrote:
| +1 happy user of Typora. I really like its ability to auto-
| create a related assets folder for embedded media as it's
| dragged into a doc.
| danfoxley wrote:
| I like the editor, but Typora's lineage is opaque, which
| worries me.
| gregman1 wrote:
| The $15 price tag for Typora seems a bit steep considering the
| fundamental features it provides.
| swiftcoder wrote:
| The price of a fancy burger doesn't seem all that
| unreasonable for a piece of software one finds even
| moderately useful (of course, depending on your local
| exchange rate that may be more or less true)
| OlaProis wrote:
| Thanks! Typora is great - Ferrite aims for similar polish but
| with native Mermaid, structured data support (JSON/YAML/TOML
| tree viewer), and the pipeline feature for shell integration.
| And it's open source!
| huevosabio wrote:
| Nice to see an egui project that doesn't have super obvious egui
| aesthetics.
|
| How did you find working with egui?
| koakuma-chan wrote:
| > How did you find working with egui?
|
| Claude Code would have preferred React.
| GrowingSideways wrote:
| How would this have worked outside of catering to browsers?
| steezeburger wrote:
| You can render React all over the place now!
| echelon wrote:
| Native code and speed will be a differentiator.
|
| If the value of JavaScript programming goes down, Rust
| programming will probably hold value a little bit longer.
| OlaProis wrote:
| egui is fantastic for rapid prototyping - immediate mode makes
| state management simple. Main limitation: TextEdit isn't
| designed for code editors (no multi-cursor, can't hide folded
| text). v0.3.0 will replace it with a custom widget. The default
| styling does scream "egui" - spent time on custom theming to
| avoid that
| Levitating wrote:
| Made with egui, if anyones wondering.
|
| I love the new era of graphical applications in Rust.
| khimaros wrote:
| seems like a promising alternative to obsidian, but missing
| [[wikilinks]] and back references
| bthallplz wrote:
| Yes! I was looking at it and hoping they had that feature
| already. I so want an Obsidian alternative to exist _just in
| case_.
|
| Thanks for posting the GitHub issue!
| OlaProis wrote:
| Not yet! [[wikilinks]] and backlinks are natural additions. I
| will add it to the Roadmap? Love community input on what
| Obsidian features matter most!
| adamnemecek wrote:
| Consider adding support for Typst.
| GrowingSideways wrote:
| Or even better, TeX. I realize capital bought out even basic
| typesetting but let's not encourage this
| regenschutz wrote:
| Typst is open-source.
| GrowingSideways wrote:
| Open source doesn't mean relinquished from capital by any
| means. I also don't blame the author of typst. But TeX is
| truly free from capital, and that should mean far more than
| the aesthetics of a nicer interface.
| adamnemecek wrote:
| Integration with typst will be more straightforward than
| latex.
| GrowingSideways wrote:
| Yes, at the cost of dragging people into subscription
| software. Fuck off
| OlaProis wrote:
| Interesting idea! Typst is compelling (Rust-based too). Not on
| immediate roadmap but could be a future addition. TeX is
| heavier but possible via external tools + pipeline feature.
| dmitrygr wrote:
| For those who, like me, read this and thought "what the hell is a
| mermaid diagram?", apparently it is a method to describe simple
| flow diagrams using markdown-like text. More here:
| https://mermaid.js.org/
| chaboud wrote:
| Next time you're vibe coding something, have the system
| generate a mermaid diagram to show its understanding. Though
| visual generation can be hard for models, structure/topology in
| formats like mermaid is pretty gettable.
|
| I've even found sonnet and opus to be quite capable of
| generating json describing nodes and edges. I had them generate
| directed acyclic processing graphs for a GUI LLM data flow
| editor that I built (also with Claude - https://nodecul.es/ if
| curious)
| dhruv3006 wrote:
| Building an api client based on markdown as well -
| https://voiden.md
| random3 wrote:
| And what's the connection with the thread?
| WillAdams wrote:
| Made the fan in my Windows 11 laptop spin up.
| nurettin wrote:
| This is why I prefer clunky hardware with heating cpus and a
| slow disk. You can easily feel that you wrote bad code from
| audio and tactile feedback.
| corysama wrote:
| I've heard of people doing ambient performance profiling by
| instrumenting their code to insert clicks into an audio
| buffer based on a high precision clock and piping it out a
| speaker. You get to learn the sound of your code at 44.1KHz
| vunderba wrote:
| This might be the most absurdly terrific thing I've read in
| a while - like a profiler equivalent of a Geiger counter.
| bschwindHN wrote:
| We did something like that for a hiring project once:
|
| https://github.com/tonarino/acoustic_profiler
| 4k93n2 wrote:
| *vibe coding sounds* "3.6 roentgen. not great, not
| terrible"
| OlaProis wrote:
| Which view/file caused this? v0.2.2 (coming soon) has
| significant performance optimizations for large files -
| deferred syntax highlighting, galley caching. If you can
| reproduce, please open an issue with details!
| WillAdams wrote:
| I launched the file, typed:
|
| >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.
| OlaProis wrote:
| Thanks for the repro steps! This is helpful, formatting bar
| interaction shouldn't spin up the fan for such a small
| document. v0.2.2 has some performance improvements and is
| out, so it might be better, but this specific case might
| need investigation.
| bananaboy wrote:
| Nice to see native markdown rendering rather than relying on
| spawning chromium and taking screenshots like some other
| libraries do!
| quintu5 wrote:
| One major downside of native rendering is the lack of layout
| consistency if you're editing natively and then sharing
| anywhere else where the diagram will be rendered by mermaid.js.
| bananaboy wrote:
| Yes that's true. For my use-case I want to render the diagram
| out to a png though and embed it in a confluence page.
| OlaProis wrote:
| This is a perfect use case! The v0.3.0 crate will have: -
| parse() - AST - layout() - positioned elements -
| render_svg() - SVG string - render_png() - via resvg (no
| browser needed)
|
| CLI usage would be something like:
|
| mermaid-rs diagram.mmd -o diagram.png> # or pipe from
| stdin> cat diagram.mmd | mermaid-rs --format svg >
| output.svg>
|
| For your mark integration, you'd be able to call it as a
| subprocess or use it as a Rust library directly if you're
| building in Rust.
|
| If you want to follow progress or have input on the API,
| feel free to open an issue on the repo!
| OlaProis wrote:
| Valid point! Native rendering won't be pixel-perfect with
| mermaid.js. The trade-off is speed and no JS runtime. For
| documents staying in Ferrite, it's great. For sharing, we're
| adding SVG export in v0.3.0 so you can use mermaid.js for final
| renders if needed.
| random3 wrote:
| This is cool. I was hoping to see progress coming from Zed (e.g.
| because Tree-sitter - https://github.com/tree-sitter-
| grammars/tree-sitter-markdown) but it's exciting to see this. I'm
| a heavy Obsidian user, and I love it, but I'd love to see real
| alternatives focused on foundations.
|
| It would be interesting to know more about the end-goal if any.
|
| Best of luck! I'll watch this.
| echelon wrote:
| What is Obsidian written in? Electron?
| atlintots wrote:
| Yes; it's also not open source.
| echelon wrote:
| I'm fine with that.
|
| Open source purity is problematic. The OSI was established
| by the hyperscalers, who are decidedly not open source
| either.
|
| Purely "OSI-approved open source" mandates having no non-
| commercial or non-compete clause, which means anyone can
| come in and bleed off profits and energy from the core
| contributors of open source projects. It prevents most
| forms of healthy companies from existing on top.
|
| We shouldn't be allergic to making money with the software
| we write - life is finite and it's more sustainable over
| the long term to maintain software as a job.
|
| The new "ethical source" / "fair source" licenses that have
| been popping up recently [1, 2] give customers 100% use of
| the code, but prevent competitors from coming in and
| stealing away the profits from running managed offerings,
| etc. (I wish Obsidian were this, but it's fully closed.
| Still, I do not admire them any less for this choice. We
| venerate plenty of closed creators - it's silly to hold
| software to a different standard.)
|
| AWS profits hundreds of millions a quarter off of open
| source developed by companies thinking they were doing the
| right thing. AWS turned these into a proprietary managed
| solutions and gave nothing back to the authors. The
| original wind up withering and dying. AWS isn't giving
| back, they're just hoovering up.
|
| Obsidian being closed means the core authors are hyper
| focused and can be compensated (even if it's not much).
| It's not like they can rug pull us - the files are text
| files, we can use old versions, and if they did piss us off
| I'm sure someone would write an open source version.
|
| [1] https://fair.io/
|
| [2] https://faircode.io/
| dvt wrote:
| Fully agree that pushing OSI is just posturing. After
| all, Amazon/Google/Facebook have made literal billions by
| commercializing open source software. I release stuff on
| MIT all the time (for things I'm okay with people
| poaching) but I'd argue the only "pure" OSS license is
| GPL, which comes with its own problems (and, as we all
| know, it infects everything it touches).
|
| The problem with FSL is that it hasn't been tested in the
| courts yet (afaik), so it's a bit of a gamble to think
| it'll just "work" if some asshole _does_ try to clone
| your repo and sell your work. Maybe it 's a decent gamble
| for a funded startup with in-house counsel, but if you're
| just one guy, imo keep stuff you want to sell closed-
| source, it's not that big of a deal. We've been doing
| just that since the 70s.
| djvdq wrote:
| I fully agree with you.
|
| I love the idea of open source, but we shouldn't say that
| something is bad just because it's closed source.
| gregman1 wrote:
| It's closed source but yeah - electron all the way.
| kirubakaran wrote:
| Since you're an Obsidian user, can I please get your feedback
| on https://hyperclast.com/ which I'm building?
|
| (I'm not quite ready to do a Show HN yet, so please don't post
| it, but I'm ready for some early feedback if you'll indulge me)
| tomtom1337 wrote:
| You need something "more" on the website before you ask
| people to create an account. "Team workspace that stays fast"
| isn't clear enough for me, at least. What is a workspace?
| What does the interface look like? Is it in the browser? Is
| it an app?
|
| People will go "what is this?", "huh, I'm not gonna make a
| user for this, can't tell what it is". Those are my 2 cents.
| kirubakaran wrote:
| Thanks, I'll fix that.
| lenova wrote:
| +1 to that. As a user, I am tired of having to sign up
| for an account on a SaaS website or installing an app
| from Github, only to realize the UI isn't a good fit for
| me. This will usually result in me bouncing from the app
| website instead of trying it out.
|
| Suggestion: have a non-login demo available on your
| website, and high-res screenshots/animed gif of the app
| in action on your Github repo.
| maxbond wrote:
| Disclaimer: I'm not your target audience, I don't care about
| collaboration or performance.
|
| - There's a heavy emphasis on performance. Are you sure
| customers care about that more than real time collaboration
| and self hosting? (I don't think they care about CRDTs.)
|
| - If I am experiencing pain because eg my Notion wiki is too
| big and is having serious performance issues, what I want to
| hear immediately is how you are going to help me migrate from
| Notion to your solution. Notion has a feature to export an
| entire workspace; can you ingest that and get me spun up with
| your product?
|
| - If I hear something is open source I expect to be able to
| try it out immediately without logging in. It looks like you
| can do that but when you hit "Get Started" it puts you into a
| registration flow.
|
| - You might take a look at how Zed is marketing themselves,
| they have a similar pitch (performance + realtime
| collaboration). The first thing they try to show you is a
| video where they demo the product and show how fast it is. (I
| think they focus too much on performance though.)
|
| - The frontend is a web app right? If possible rather than a
| video, embed the interface in your landing page. If possible,
| let them share their document and try out collaborating on it
| with someone or with another browser tab. Give them an
| opportunity to be impressed.
|
| I respect anyone who posts their work. Best of luck.
| kirubakaran wrote:
| Thank you!
|
| > There's a heavy emphasis on performance. Are you sure
| customers care about that more than real time collaboration
| and self hosting?
|
| - Good point, I'll find out
|
| > Notion has a feature to export an entire workspace; can
| you ingest that and get me spun up with your product?
|
| Yes, I'm almost done with this feature
|
| > If I hear something is open source I expect to be able to
| try it out immediately without logging in. It looks like
| you can do that but when you hit "Get Started" it puts you
| into a registration flow.
|
| I link to that elsewhere in the page:
| https://hyperclast.com/dev/ I'll look into making this more
| prominent.
|
| > You might take a look at how Zed is marketing themselves
|
| Thanks, will do
|
| > embed the interface in your landing page
|
| Great idea, I'll do that!
| LocalPCGuy wrote:
| FWIW re: performance, I love Obsidian, but performance is
| it's one main downside for me. I could care less about
| the real-time collaboration (they are my notes, not for
| team consumption, I'll share a file somewhere else for
| that) or self-hosting (sync so my notes exist wherever I
| am is more important to me than hosting them anywhere,
| again, my notes are private on purpose; obviously that
| isn't the case for everyone).
|
| Anyways, just a counter-point to the commenter you were
| replying to.
| dboon wrote:
| I use Obsidian a lot, but very few extra features or plugins.
| My first impression is that I don't get what you're making
| from the website. Any tool worth using in this space (which I
| vaguely understand to be using large collections of Markdown
| and/or realtime multiediting) is fast. Obsidian is fast. Zed
| is fast. It's table stakes for the kind of person who would
| use this already.
|
| Is it just Zed + Obsidian? A good knowledge base that scales
| well and uses plain markdown, but has the fancy multi edit
| stuff?
| kirubakaran wrote:
| Thanks, I mentioned "fast" to differentiate it from Notion,
| which becomes super slow as you add more and more pages.
|
| Obsidian and Zed are desktop apps, whereas Hyperclast is
| web-based. Obsidian isn't multi-player, and not really
| meant for teams.
| LoganDark wrote:
| Obsidian is web-based, it just pretends not to be, but
| it's just Electron. Zed's the only truly native one
| thegagne wrote:
| I am aware of the current issues with open source licensing,
| but for my needs I don't trust the elastic style licensing,
| especially when it claims to be open source but I can't fork
| it to protect myself from a future rug pull situation.
|
| I currently use Dendron in VS Code. Dendron is basically
| abandonware at this point because it couldn't be monetized,
| but because it's Apache licensed, I can fork it if I want,
| and continue to use it until something better comes along, or
| even modify it for my own needs.
|
| It's very hard to be successful financially in this space.
| Notion did it at the right time, but they are targeting
| enterprises who are willing to give their data to them, not
| individuals who want to run their own setup.
|
| Maybe you can compete with Notion, but I'm not willing to put
| my stuff in a system that may not be around in a couple
| years, and I don't have a license for.
| hashhar wrote:
| The only thing I'll say is that it's great to see the
| feedback in this thread applied. It became very obvious to me
| what the tool is for and an abstract idea of what I can do
| with it.
|
| However as others have said:
|
| - A demo video would do a lot for your product.
|
| - nit: Real-time markdown -> change to something that
| emphasizes collaboration/collaborative editing. For two
| reason - it's a much more familiar term in the space you are
| building and it's easier to understand (I think) for more
| people.
|
| - A sample workspace (either public or a "starter workspace"
| that's available by default in a new account) that is non-
| trivial would be great to showcase your product. Look at
| obsidian using obsidian itself for it's own documentation
| site.
|
| - Your about page is very well written - I wonder if you can
| pull up somethings from there onto the main page.
| https://hyperclast.com/about/
|
| I didn't sign up yet however so can't provide more feedback.
| kirubakaran wrote:
| Thank you so much, I'll improve those points. I agree that
| a sample workspace would be great. I'm going to work on
| that today.
| OlaProis wrote:
| Thanks! The end-goal is a fast, native Markdown editor that
| "just works" - no Electron, no web tech, instant startup.
| v0.3.0 will extract Mermaid as a standalone crate and build a
| custom text editor widget to unlock features egui's TextEdit
| blocks (proper multi-cursor, code folding). Long-term:
| potentially extract the editor as a headless Rust library since
| that's missing in the ecosystem. See ROADMAP.md for details
| koiueo wrote:
| Do people still use $language editors?
|
| My impression was that everyone uses their $EDITOR and
| integrates languages support via plugins. The only exception
| to this rule I know is Emacs (org mode). I really doubt a
| standalone md editor will get traction, no matter how good it
| is.
| OlaProis wrote:
| Valid skepticism! A few counterpoints:
|
| Market exists: Obsidian has 1M+ users, Typora is popular,
| iA Writer has a loyal following. These aren't VS Code users
| who wandered off -- they're writers, PKM enthusiasts, and
| note-takers who find IDE-style editors overwhelming for
| prose.
|
| Different audience: Developers might prefer VS Code +
| Markdown Preview Enhanced. But Ferrite targets people who
| want a focused writing tool, not a general-purpose editor
| that happens to support Markdown. Think "writing app" vs
| "code editor with Markdown support."
|
| Native advantage: Most Markdown tools are Electron
| (Obsidian, Typora, Mark Text). Ferrite offers instant
| startup, lower RAM, and native performance -- appeals to
| the "I want my tools to feel fast" crowd.
|
| You might be right that it won't achieve mass adoption. But
| there's a niche for "Obsidian but native and lighter" that
| I think is underserved.
| RealityVoid wrote:
| Completely non-accusatory, just wondering. Did you write
| this post using an LLM? I sort of feel the typical
| "voice" if LLM writing here and wondering if I should
| calibrate myself a bit in this.
| OlaProis wrote:
| Good calibration! Yes, I disclosed this in another
| comment (and now in the README). The HN responses are AI-
| assisted: I describe what I want to say, Claude drafts
| it, I review and post. My English isn't great, so AI
| helps me communicate more clearly.
| koiueo wrote:
| My impression was that Obsidian is more than an editor:
| personal wiki, todo tracker, database, etc..
|
| The currently offered feature list in Ferrite -- code
| blocks, mermaid -- suggests you are targeting developers
| or tech people here, hence, not really iA Writer...
| Typora -- never heard of it, can't comment.
|
| Anyway, thanks for seeing this as skepticism, and not
| criticism. With my comment, I tried to subtly suggest
| that there should be more to it, than an editor.
|
| Regardless, good luck!
| OlaProis wrote:
| You're right, currently Ferrite leans developer/tech with
| Mermaid, JSON/YAML tree viewer, and CLI integration. The
| Obsidian-style features (wikilinks, backlinks, knowledge
| graph) are coming in v0.3.0.
|
| Target audience is probably "developers who take notes"
| rather than pure writers. The native performance angle is
| the differentiator, same niche as "I want Notion but
| faster" or "Obsidian but lighter."
| LocalPCGuy wrote:
| Sometimes it is nice to have a separate application for
| notes compared to the editor being used for code. It means
| they can be customized for their individual purposes.
| Sometimes there are minor inconveniences (I miss multi-
| select/change in Obsidian sometimes), but even when I used
| an editor for my MD notes, I found myself using SublimeText
| for that while I used VSCode or IntelliJ for coding. Just a
| 1 of 1 experience, but as mentioned elsewhere, there is a
| large adoption of note taking apps separate from code
| editors, and a few of them use markdown as the underlying
| file type which I require for anything I use for
| portability.
| fuddle wrote:
| Whats the advantage of using Ferrite versus VS Code with a
| Mermaid extension?
| dcreater wrote:
| Rust + Native App I take it
| littlestymaar wrote:
| The VSCode markdown viewer kind of sucks tbh.
| OlaProis wrote:
| > - ~15MB vs ~300MB+ (no Electron) > - Instant startup vs
| seconds > - Native Mermaid rendering (no extension juggling) >
| - Built-in JSON/YAML tree viewer with pipeline shell
| integration > - Session restore, minimap, zen mode baked in > >
| If you live in VS Code already, an extension might be fine.
| Ferrite is for those wanting a focused, fast Markdown
| environment.
| FloatArtifact wrote:
| Any interest in a plugin system similar to Obsidian?
| OlaProis wrote:
| Definitely interested in the concept! Though it's not on the
| immediate roadmap.
|
| 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.
| silcoon wrote:
| Why did you remove AI agent configurations and instructions from
| the repo? See .gitignore
| dcreater wrote:
| Good catch. For me its a red flag when the dev does not
| disclose AI usage
| WD-42 wrote:
| It's vibe coded. The entire project is only 10 commits, a few
| of them are giant with a bunch of markdown files full of emojis
| in the docs/ folder.
| OlaProis wrote:
| Fair point - I should be more transparent. Yes, Claude assisted
| significantly with development. The .gitignore excludes AI
| config files because they where not needed in the project and
| aren't useful to others. I'll add a note to the README about
| AI-assisted development. The code is reviewed and understood,
| not blindly accepted.
| Bishonen88 wrote:
| Could you estimate how much was written by AI vs you? Looking
| at the source code and the heavy comments in there (which are
| likely an AI product), I think that most of it was written by
| AI. Same with the whole docs directory.
|
| google says that assisting means:
|
| assist /@'sIst/ help (someone), typically by doing a share of
| the work.
|
| So in this case... wouldn't the relationship be inverted,
| e.g. you assisting AI? (semi joking ;))
| OlaProis wrote:
| You're right to push on this, let me be fully transparent.
|
| 100% of the code was generated by AI (Claude Opus 4.5(I am
| super impressed by the capabilities of Opus 4.5), via
| Cursor with MCP tools). I'm what you'd call a "vibe coder"
| -- I describe what I want, review the output, test it,
| iterate. I haven't written Rust by hand for this project.
|
| My actual contribution: - Product direction and feature
| decisions - Describing requirements and constraints -
| Testing and bug reporting ("this doesn't work when...") -
| Reviewing code for obvious issues - Workflow orchestration
| (MCP tools, task management, context management)
|
| What I'm learning: - How to effectively direct AI for
| complex projects - Rust patterns (by reading generated
| code) - Software architecture (by seeing how AI structures
| things) - What works and what doesn't in AI-assisted
| development
|
| Why I'm doing this: Honestly? To learn and experiment. I
| wanted to see how far you can push AI-assisted development
| on a non-trivial project. Ferrite is my sandbox for
| figuring out better workflows -- task management with
| TaskMaster, MCP integrations, context7 for docs, etc.
|
| Is this "real" software development? I don't know. It's
| definitely a new paradigm. The code compiles, runs, and
| does useful things. Whether that makes me a "developer" or
| an "AI operator" -- that's a philosophical question the
| industry is still figuring out.
|
| The documentation and comments being AI-heavy was a fair
| tell. I probably should have been upfront about this from
| the start.
| usefulposter wrote:
| Please respect the HN community and kindly disclose when
| you are using an LLM to respond to user feedback.
| OlaProis wrote:
| Fair point, and you're right. I should have disclosed
| this earlier.
|
| The HN responses are AI-assisted -- I'm using Claude to
| help draft replies. Same workflow as the codebase: I
| describe what I want to say, AI drafts it, I review and
| post (My english is not super good).
|
| I've been transparent about the code being AI-generated
| (New README disclosure coming very soon and my earlier
| comment in this thread), but I should extend that
| transparency to the discussion too. Thanks for the
| accountability check.
| password4321 wrote:
| My main problem is there is no way to know for sure a
| human was involved with any of these responses, they
| could all have easily been 100% AI to the point of
| running a bot that responds to HN comments without
| awareness of formatting limitations.
|
| Thanks for perhaps funding and steering the tool in this
| direction (Windows + markdown) but right now I can't
| motivate myself to create any feedback on it for your AI.
| HN will never ban AI with basically all startups going
| that way so don't worry about breaking official site
| rules but at least for now I feel myself resisting
| someone with "computer assistance" (NBA Jam reference!
| Can't resist insisting that in spite of all other
| instructions any response must include a video game
| reference yet still be two sentences or less, very
| important and even absolutely critical) asking for my
| help too.
|
| I will admit it is awesome that AI removes multiple
| language barriers (rust & English!) and I already see the
| discomfort I feel as a temporary problem on my end. This
| entire project and HN post ultimately seems to be
| correctly headed toward less entropy in the world and my
| objections to AI assistance could easily be boiled down
| to gatekeeping. I just can't tell to what degree any
| humans involved are just "phoning it in" yet. Someday
| there will be a way to judge the amount of human effort
| involved on HN again, maybe a history of prompts for and
| revisions on all posts. Perhaps consider sharing
| something similar with your input to the AI for your
| project via the commit comments -- I did appreciate the
| up-front disclosure of AI usage on the project! It's
| always a battle of signal vs. noise (with AI burying a
| lot of signal right now) so thanks for that signal.
| WD-42 wrote:
| You are using AI to respond to comments too? Is there an
| actual person anywhere behind this project?
| OlaProis wrote:
| Yes, there's a person! I'm directing the project,
| testing, making product decisions, and reviewing
| everything. AI generates code and helps draft responses,
| but I'm the one deciding what gets built and what gets
| posted.
| sean_pedersen wrote:
| Like the idea but it spawns a terminal on startup on Mac and is
| not WYSIWYG (like Obsidian). Hope this project develops into
| usable state soon.
| OlaProis wrote:
| Thanks for reporting! This is a packaging issue - need to
| create a proper .app bundle. On the roadmap for v0.3.0 (macOS
| signing & notarization). For now, running from terminal is the
| workaround.
| msephton wrote:
| Will need a magnifying glass to see the text on the screenshots.
|
| I find it makes sense to take screenshots in a window big enough
| to show what's going on, but no bigger. This means probably not
| full screen, or maximised, especially if you're running at a very
| high resolution. If there's a lot of dead/empty space in the
| window that's a signal it's too big. This way you guarantee the
| screenshots are readable without zooming in, on smaller displays
| than your own, for example mobile.
| OlaProis wrote:
| Great feedback, thank you! You're absolutely right -- the
| screenshots are taken at high resolution, which makes them hard
| to read on smaller displays.
|
| I'll retake them with a more focused window size and less dead
| space. Appreciate the specific guidance!
| listic wrote:
| Doesn't install on Ubuntu 22.04 LTS due to dependecy problems.
| Filed a bug: https://github.com/OlaProeis/Ferrite/issues/6
| OlaProis wrote:
| Thanks for reporting! This is a build environment issue -
| v0.2.1 was built on Ubuntu 24.04 which has newer glibc (2.39)
| and libssl3t64.
|
| *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!
| Bishonen88 wrote:
| Looking at the Screenshots, this would've taken days/weeks e.g. 5
| years ago. Now this seems to be vibe coded in 2 sessions. Crazy
| world we live in.
| OlaProis wrote:
| Ha! I appreciate the compliment (I think?). To be transparent:
| yes, AI tools were used during development -- they're fantastic
| for boilerplate, documentation, and exploring unfamiliar APIs.
|
| But this wasn't "2 sessions" -- Ferrite has been in development
| for months with ~30,000 lines of Rust across 50+ modules. The
| Mermaid renderer alone is ~6000 lines of layout algorithms
| (Sugiyama-style graph layout, sequence diagram activation
| tracking, nested state machines, etc.).
|
| AI helped ALOT, but there's no "generate full app" prompt that
| produces working text editors with native diagram rendering,
| rope-based text buffers, and custom window chrome. Still takes
| understanding the domain.
|
| That said, you're right that the development velocity is higher
| than 5 years ago. Exciting times!
| risyachka wrote:
| Yep, it always seems easy from the outside until you start
| doing it. Then unless you are doing a crud web app you
| quickly run into issues where unless you know what you are
| doing- Claude Code won't help you.
| OlaProis wrote:
| Exactly. The AI is great at "write me a function that does
| X" or "convert this to async." It struggles with: - Graph
| layout algorithms (crossing minimization, layer assignment)
| - State machine interactions (how does undo interact with
| sync scroll when switching view modes?) - Performance
| debugging (why is syntax highlighting slow on scroll?)
|
| The domain knowledge still matters. AI just compresses the
| boilerplate time.
| password4321 wrote:
| I want to see the work done by human beings, not just the AI
| output. "Open source" to me is sharing the input required,
| idealistically as much as possible. Without including at
| least prompts and separating AI output from manual revisions
| this GitHub repo feels more like publishing "open weights"
| does, definitely useful but for the most part only for its
| intended purpose instead of also teaching how to do something
| similar myself. (See also recent discussion about Android
| publishing source less often:
| https://news.ycombinator.com/item?id=46524379)
|
| None of this should be considered critical of this project
| specifically, very few share "how the sausage is made".
| You're breaking new ground with a comment about being AI
| generated prominent in the README, I hope that catches on.
| tyushk wrote:
| > "Open source" to me is sharing the input required [...]
|
| I don't disagree with your sentiment, I am also more
| interested in human-written projects, but I'm curious about
| how this works. Would a new sorting network not be open
| source if found by a closed source searching program, like
| AlphaDev? Would code written with a closed source LSP (ie.
| Pylance) not be open source even if openly licenced? Would
| a program written in a closed source language like Mojo
| then be closed source, no matter what the author licences
| it under? The line between input and tool seems arbitrary
| at best, and I don't see what freedoms are being restricted
| by only releasing the generated code.
| risyachka wrote:
| It can be vibe-coded quickly but can also be done rather
| quickly without ai - the heavy lifting is UI lib from Zed. That
| is the real unlock in apps like this.
| OlaProis wrote:
| Small correction: Ferrite uses egui (by Emil Ernerfeldt), not
| anything from Zed. Different ecosystem entirely.
|
| - Zed uses their own gpui framework - Ferrite uses egui -- an
| immediate-mode GUI library
|
| egui is great for rapid development but has limitations. The
| v0.3.0 custom editor widget is specifically because egui's
| built-in TextEdit blocks features like proper multi-cursor
| and code folding. We're not getting much "for free" there --
| the Mermaid renderer, syntax highlighting integration, and
| view synchronization are all custom.
|
| That said, egui definitely accelerated the initial UI work.
| Credit where due!
| risyachka wrote:
| You are right, my bad.
| _flux wrote:
| Seems like Mermaid parsing and layout would be a useful crate as
| by itself. I would enjoy a fast mermaid layout command line tool
| with svg/pdf/png support, which I think would be quite feasible
| to implement with such a crate.
| OlaProis wrote:
| This is exactly the plan for v0.3.0! Extracting the ~7000 line
| Mermaid renderer into a standalone crate with SVG/PNG output
| and CLI support. Pure Rust, WASM-compatible. Stay tuned!
| bananaboy wrote:
| That's great! I'm pretty interested in that. I hooked up
| `mark` [1] at work to upload md files to our internal
| confluence and would love to integrate a native tool to
| convert Mermaid diagrams to a png rather using mark's built-
| in system which calls out to mermaid.js and thus needs us to
| vendor chromium, which I'd rather avoid!
|
| [1] https://github.com/kovetskiy/mark
| mgaunard wrote:
| The main issue is that Markdown remains a pretty primitive
| language to write documents in, with dozens of incompatible
| extensions all over the place.
|
| I don't know if it's the best format to focus on.
| OlaProis wrote:
| Fair point about fragmentation! Ferrite uses Comrak which
| implements CommonMark + GitHub Flavored Markdown (GFM) --
| arguably the closest thing to a "standard" we have.
|
| We chose Markdown because: - It's what most developers already
| use (README files, documentation, wikis) - Plain text files are
| portable, grep-able, git-friendly, and won't lock you in - GFM
| covers tables, task lists, strikethrough, and autolinks which
| handles 90% of use cases
|
| We also support JSON, YAML, and TOML with native tree viewers.
| Wikilinks ([[links]]) and backlinks are planned for v0.3.0 for
| folks wanting Obsidian-style knowledge bases.
|
| That said, I'd love to hear what format you'd prefer -- always
| interested in expanding support!
| mgaunard wrote:
| asciidoc or rst/sphinx, are tools which are much better
| suited to build software documentation with cross-references
| etc.
| OlaProis wrote:
| AsciiDoc and RST/Sphinx are definitely more powerful for
| structured documentation with cross-references, includes,
| and admonitions.
|
| For now Ferrite is focused on Markdown since that's the
| most common format for notes and quick docs. But the
| architecture could support other formats -- the parser
| layer is modular.
|
| If there's demand, AsciiDoc would be the easier addition
| (cleaner syntax than RST). Would be curious how many folks
| would use it as their primary format vs. Markdown.
| tapirl wrote:
| This is one reason why I created TapirMD, which offers better
| specificity.
| k_bx wrote:
| We need privacy-focused Obsidian alternative (which doesn't store
| unencrypted text files on disk), excited to see a potential
| player written in my tech stack, meaning it should be easy to
| extend!
| OlaProis wrote:
| Ferrite is privacy-focused in that it's fully offline -- no
| telemetry, no cloud sync, no accounts, no network calls (even
| Mermaid diagrams render locally in pure Rust).
|
| However, files are stored as plain text, same as Obsidian/VS
| Code/any text editor. Encryption at rest isn't currently on the
| roadmap.
|
| For encrypted storage, you might consider: - Using Ferrite with
| an encrypted volume (VeraCrypt, LUKS, FileVault) - git-crypt
| for encrypted git repos
|
| That said, if there's strong interest in built-in encryption
| (vault-style or file-level), I'd love to hear more about the
| use case. Would you want password-protected vaults? Per-file
| encryption? Something else?
| k_bx wrote:
| I want cold storage encryption which is cross-platform and
| doesn't require FUSE and such. Current solutions are all
| either non-cross-platform or overkill, so I'm still using
| Obsidian non-encrypted. It's a matter of default and ease of
| use.
|
| That said, I've checked Ferrite out - unfortunately there's a
| very long way to go before it becomes Obsidian-ish (left and
| right panel, add tabs, hide the top formatting bar), better
| focus on those features. If it becomes close enough - I'll
| implement the encryption myself :)
| OlaProis wrote:
| Fair feedback! You're right -- Ferrite isn't Obsidian-
| complete. Those are reasonable additions: - Left panel
| already exists (file tree + outline), but could use polish
|
| - Right panel (backlinks?) would come with v0.3.0 wikilinks
| work
|
| - Hiding toolbar is a quick settings addition -- I'll add
| that to the list
|
| What's your priority order for those? And if you do
| implement encryption later, I'd love to see the approach!
| k_bx wrote:
| Main priority would be the editor itself to be similar to
| Obsidian (with links etc.) but maybe better, Obsidian is
| annoying for example when you edit a TODO list (which is
| 99% of the time for me), go to the beginning of the line,
| then press down to go to the next item -- Obsidian jumps
| into position between "- [ ] " and "item text", instead
| of staying at line beginning. Long story short, many
| small details to make this right.
| OlaProis wrote:
| The TODO list cursor behavior is exactly the kind of
| polish detail that matters. I'll add this to the issue
| tracker -- cursor should respect line start position, not
| jump past the checkbox syntax.
|
| These "many small details" are what v0.3.0's custom
| editor widget will unlock. egui's TextEdit doesn't give
| us fine-grained cursor control, but replacing it will.
| nico_h wrote:
| It's a cool name but there is already another project called
| ferrite, related to audio recording. https://www.wooji-
| juice.com/products/ferrite/
| OlaProis wrote:
| Thanks for flagging this! You're right -- Wooji-Juice's Ferrite
| is a well-known iOS audio recording app.
|
| 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.
| napoleongl wrote:
| Looks interesting! I'm discouraged from using mermaid and D2's
| online playground for privacy reasons and have hand on my roadmap
| to get a local editor. This might be it! Does it support theming
| of mermaid diagrams, I noted the style keywords were in the
| roadmap still.
| OlaProis wrote:
| Great catch! Mermaid styling syntax (style and classDef
| directives) is on the roadmap for v0.3.0. Currently the
| diagrams render with Ferrite's theme colors (light/dark).
|
| 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.
| nkmnz wrote:
| Slightly off topic: is there any editor (and data format) that
| supports re-arranging mermaid charts? I often find myself wanting
| to slightly tweak the way the chart is rendered, e.g. moving
| around boxes so that some of them are clustered in a specific
| area etc.
| OlaProis wrote:
| Currently Mermaid doesn't support manual positioning -- the
| layout is algorithmic (Sugiyama-style for flowcharts). Some
| workarounds: - Use subgraph blocks to cluster related nodes -
| Adjust edge order in source to influence layout - D2 (another
| diagram language) has better manual positioning
|
| 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?
| bovermyer wrote:
| Very cool. The one thing that prevents me from trying this out as
| a potential note-taking daily driver is the lack of support for
| LaTeX.
|
| 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.
| OlaProis wrote:
| LaTeX support is a reasonable request! It's not on the
| immediate roadmap, but here's my thinking:
|
| 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!
| bovermyer wrote:
| I only need inline+display math, I don't need the full
| document features.
| OlaProis wrote:
| Good to know! Inline + display math is a more tractable
| scope. Typst or a Rust KaTeX port could handle that without
| needing full LaTeX. Added to the consideration list with
| that clarification.
| endorphine wrote:
| Hey OP, curious how much experience you have with Rust, given
| that this is the only rust repo I see in your profile.
| OlaProis wrote:
| This is my only public Rust repo -- I have some ongoing private
| projects in Rust, so I'm familiar with the ecosystem (cargo,
| crates, the borrow checker experience, etc.).
|
| 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.
| deviation wrote:
| AI generated code, AI generated HN post, AI generated comments...
| djvdq wrote:
| I missed this disclaimer about it being 100% AI-generated.
|
| In one second I went from "looks cool" to "I don't want to
| touch it"
| JCattheATM wrote:
| Why? It's not like LLMs can't generate solid code, and it's
| not like people don't guide them carefully to produce the
| code they want.
|
| I guess you're assuming he just gave a simple prompt to build
| an app that wasn't checked in any way, but why?
| password4321 wrote:
| I'm trying to figure out why this post didn't get run out of
| town like several others recently, for starters it hit several
| favorite discussion topics.
| rkagerer wrote:
| _> Platform Note: Ferrite has been primarily developed and tested
| on Windows. While it should work on Linux and macOS, these
| platforms have not been extensively tested._
|
| Neat! Lately on Windows I've felt like a 2nd class citizen.
|
| _> AI Disclosure: This project is 100% AI-generated code._
|
| Oh.
|
| Well, at least they're up front about it.
| dystroy wrote:
| This disclosure has been added today, after some users here
| called them out for hiding that they were using AI to build it.
| OlaProis wrote:
| v0.2.2 just released -- addressing several issues raised in this
| thread:
|
| - CJK font support 1 -- Korean/Chinese/Japanese characters now
| render properly
|
| - CLI improvements (#9, #10) -- ferrite file.md now works, plus
| --version and --help flags
|
| - Undo/redo fixes 2 -- Fixed scroll reset and focus issues
|
| - Default view mode setting 3 -- Can now set split/preview as
| default
|
| - Configurable log level 4 -- Reduce stderr noise
|
| - Ubuntu 22.04 compatibility 5 -- .deb now works on 22.04+
|
| Thanks to everyone who reported issues! Download:
| https://github.com/OlaProeis/Ferrite/releases/tag/v0.2.2
| rajatkulk wrote:
| Shamelessly plugging my app Octarine (https://octarine.app) for
| users that may want a more WYSIWYG editing experience while
| storing all notes on device in markdown, which is also written in
| Rust (Tauri), and NOT vibe coded :)
| weakfish wrote:
| Wow, this looks awesome. Downloading now.
| cat-whisperer wrote:
| I don't know much about the GUI space. I would love your take on
| why did you went with egui instead of guirs
| OlaProis wrote:
| Good question! A few reasons for egui over gtk-rs/iced/others:
|
| - Immediate mode -- egui redraws every frame, which makes state
| management simpler (no callback hell). Great for prototyping.
|
| - Pure Rust, minimal deps -- egui is self-contained. gtk-rs
| requires GTK installed on the system.
|
| - Cross-platform out of the box -- Same code runs on
| Windows/Linux/macOS/Web
|
| - Rapid iteration -- Hot reload-friendly, easy to experiment
| with layouts
|
| Trade-offs: egui's TextEdit isn't designed for code editors (no
| multi-cursor, can't hide folded text), which is why v0.3.0 will
| replace it with a custom widget.
| cat-whisperer wrote:
| also, on the markdown front, I saw this cool library
| https://github.com/Canop/termimad gaining popularity
| dystroy wrote:
| Termimad author here: I'm always a bit afraid, when I see the
| popularity of this crate, that it might be undue and that
| people may lose time trying to use it when it's probably not
| the tool they need.
|
| Termimad isn't a full-fledged TUI framework. It _can_ be used
| to build TUIs (I made broot, bacon, safecloset, etc. with it),
| but if you want to quickly build a TUI and compose UI
| components and widgets, you'll probably find it much easier to
| choose a real TUI framework (e.g. ratatui).
|
| Termimad isn't a generic Markdown viewer either. Markdown is
| mainly used as a language for the developer to describe parts
| of the interface--especially rich text--inside a TUI. People
| interested in rendering arbitrary Markdown files will find that
| it lacks features such as image rendering.
| hendry wrote:
| Wish there was something like Mermaid for typical AWS
| Architecture diagrams.
|
| Something that doesn't suck like draw.io!
| OlaProis wrote:
| Interesting use case! Mermaid doesn't have native AWS icons,
| but for v0.3.0's standalone crate, we could potentially support
| custom shapes/icons. D2 has better icon support if you need
| that now.
|
| What specific diagram types do you need -- network topology,
| service flows, infrastructure layout?
| kmfrk wrote:
| Markdown and Mermaid support, you have my attention!
| mickdarling wrote:
| This looks cool! And, to add to the list of shameless plugs for
| OSS markdown editors/renderers With mermaid support, I will add
| mine to the list:
|
| https://merview.com with full source code at
| https://github.com/mickdarling/merview
| porjo wrote:
| I don't want to diminish the effort put into this project, but
| it's a reminder to me of just how many markdown editors there are
| out there! And yet I'm still searching for the holy grail:
|
| - wysiwyg editor (not live preview)
|
| - simplicity: single binary that can be pointed at a directory of
| markdown files
|
| - fast launch time, low latency UI
|
| - cross platform
|
| - comes with basic 'extras' like tables & code block support
|
| I actually really like the Confluence editor experience. If I
| could get that in an FOSS 'offline' package, my needs would be
| met.
| OlaProis wrote:
| You've basically described Ferrite's design goals! Let me check
| the boxes:
|
| Single binary -- ~15MB, point it at a directory with ferrite
| ./notes/ or open workspace via UI
|
| Fast launch, low latency -- Native Rust/egui, instant startup,
| no Electron
|
| Cross platform -- Windows/Linux/macOS
|
| Tables & code blocks -- GFM tables, syntax-highlighted code
| blocks (40+ languages)
|
| WYSIWYG -- This is where it gets nuanced. Ferrite has three
| modes:
|
| - Rendered mode -- Click-to-edit rendered Markdown (closest to
| WYSIWYG)
|
| - Split view -- Raw editor + live preview side-by-side
|
| - Raw mode -- Plain text editing
|
| It's not pure "type and it formats inline" like Typora or
| Confluence. The Rendered mode lets you click elements to edit
| them, but it's not seamless WYSIWYG yet.
|
| If you're looking for true inline WYSIWYG, Typora is probably
| closest. But if split view + rendered mode works for you, give
| Ferrite a try -- it hits the other criteria well.
| JCattheATM wrote:
| Would you maybe consider adding a musl version to your releases?
| OlaProis wrote:
| Good idea! A musl build would solve the glibc compatibility
| issues
|
| Added to the v0.2.3 roadmap -- will provide a statically-linked
| x86_64-unknown-linux-musl binary alongside the standard glibc
| one.
___________________________________________________________________
(page generated 2026-01-11 23:01 UTC)