Stream: show and tell

Topic: Bliss Writer -- Screenwriting Software

ofekd (Oct 21 2026 at 16:08):

I have made the leap and dumped Bun. Bliss Writer, my TUI for screenwriting, is now completely Roc + a custom crossterm/ratatui platform.

https://blisswriter.app

The improvement is immense.

Installer size 50% down (this includes shipping Ghostty, so the actual binary got much smaller).

Performance is great. Memory usage is about 35MiB down from 350MiB. Pure UI frames render in about 1.3ms for 700-800 fps on my laptop, with typing currently at 120-180 fps. I expect those are modest numbers that can be greatly improved. If you download it you can use Ctrl+Alt+Shift+0 to see a frame-time monitor.

Last, the coding experience is so much better. The Bun-backed version was written in Gleam, which I love, but it used an FFI to OpenTUI which is far too ideologically stateful to my liking.

Pain points:

• Compiler is not even 0.1, so the usual stuff that come with it. LLMs allow me to mostly focus on app code. It does take a long time to link and uses 20-30 gigs of ram to type check
• App has many non-roc moving pieces that don't fit in the same platform (e.g it relies on Loro, which is Rust), so I didn't actually build a contained platform. There's a bespoke platform for the app, in Rust, which just pulls those pieces as crates (and Roc code imports the Roc counterparts). If I wanted to build another TUI I'll have to rebuild this plumbing

Good stuff:

• So nice to color effectful functions
• I didn't like the syntax at first but it's growing on me
• The ecosystem is very nice, even though it's small! The XML parser helped me a lot
• Platform abstraction is very nice to work with (except for that pain point above)
• After the LLM explained to me how Roc lays things in memory, decent performance was achieved with not much effort
• Cross platform, very nice

notramo (Oct 21 2026 at 17:22):

@ofekd, have you tried the latest nightly? A memory usage optimization was merged, but I don't know whether it's relevant for your use case:
https://github.com/roc-lang/roc/pull/12402

Richard Feldman (Oct 21 2026 at 17:49):

thanks for sharing, this is really cool! :smiley:

Richard Feldman (Oct 21 2026 at 17:51):

yeah I landed a few peak RSS improvements recently but 20-30gb still sounds super high...when you say that's to type check, do you mean roc check specifically?

Richard Feldman (Oct 21 2026 at 17:51):

or is that with the --timings flag breaking it down as being in the type checking phase

ofekd (Oct 21 2026 at 18:04):

notramo said:

ofekd, have you tried the latest nightly? A memory usage optimization was merged, but I don't know whether it's relevant for your use case:
https://github.com/roc-lang/roc/pull/12402

It's pinned to 73df27a5bb5507e174b7afe050a54b084efcba3b, which I believe does not have those changes

Richard Feldman said:

yeah I landed a few peak RSS improvements recently but 20-30gb still sounds super high...when you say that's to type check, do you mean roc check specifically?

Yes, plain roc check. Last CI build peaked 19.3gb. On my laptop it peaks at 30, no idea why. Maybe something with the kernel since the build is nix backed

ofekd (Oct 22 2026 at 11:26):

Put it up at HN:

https://news.ycombinator.com/item?id=50193901

Last updated: Nov 04 2026 at 18:54 UTC