I've been building kuva, a scientific plotting library in Rust, and i'm looking for feedback.

What does it do:

• 25 plot types: scatter, line, bar, histogram, box, violin, heatmap, Manhattan, volcano, phylogenetic trees, Sankey, chord, UpSet, and more
• SVG output by default. Zero extra deps if you just want SVG
• PNG (via resvg) and PDF (via svg2pdf) as optional feature flags
• Builder pattern API [.with_data(data).with_trendline()...etc] with a prelude::* for ergonomic imports
• Multi-panel figures with merged cells, shared axes, and shared legends (that is logical and not insane)
• A kuva CLI binary that reads TSV/CSV files (or stdin) and renders any plot type, including directly to the terminal using ascii, utf-8 (braille ftw!) + ANSI for colour

Why I built it:

I'm a scientist and work in bioinformatics and had an...interesting?... time with some other libraries when used with high performance genome scale tools. I wanted something fast, zero-system-font-dependency!!!!, and useful for publication figures. I really only set out to build a couple of specialised plot types (like the brick plots for short tandem repeats), but got a little carried away.

Note: kuva was initially built by hand (tradcoder core), with a working library and several plot types already in place before AI tooling was introduced. From that point, Claude was used to accelerate adding more plot types, the CLI, and the docs. I have a page about this in the github docs and on the readme, but I like being up front about it.

Here's a quick code snippet:

use kuva::prelude::*;

let data = vec![(1.0_f64, 2.3), (2.1, 4.1), (3.4, 3.2), (4.2, 5.8)];

let plot = ScatterPlot::new() 
        .with_data(data)
        .with_color("steelblue")
        .with_trend_line()
        .with_legend("samples");

let plots = vec![plot.into()];
let layout = Layout::auto_from_plots(&plots)
                .with_title("Quick scatter")
                .with_x_label("X")
                .with_y_label("Y");

std::fs::write("plot.svg", render_to_svg(plots, layout)).unwrap();

Links:

• Crate: https://crates.io/crates/kuva
• Docs: https://psy-fer.github.io/kuva
• Repo: https://github.com/Psy-Fer/kuva

Still early (v0.1.2), so feedback on the API, missing plot types, or anything that seems weird is very welcome.

EDIT: removed some back slashes left over from markdown in code snippet

Hey everyone. I’m a web developer and I recently started learning rust to expand my skillset and knowledge of programming. I built this simple little calculator using Tauri. I used Rust/Tauri for the logic and SolidJS for the UI. I know it’s really simple but it was fun and a good learning experience.

Quite a few people have been asking me for this, now it's here!

Any feedback is greatly appreciated - see https://github.com/sxyazi/yazi/pull/4005 for more info!

After many weeks of learning, watching tutorials about Rust, and partaking in Rust exercises, I decided to port a small Go library into Rust. I do recognize I have a lot to learn but just getting out of my comfort zone and trying my hands at this has be rewarding and revealing.

Link: https://github.com/neneodonkor/asciigraph-rs

Crates: https://crates.io/crates/asciigraph-rs

PS. Making it work for real-time data was 🥵

Let me add that I only started learning Rust in February, so please forgive me, if everything is not idiomatic Rust.

Hey r/rust,

For the past two years, a few friends and I have been reverse-engineering Macromedia Shockwave: the closed-source, largely undocumented plugin that powered a huge chunk of early 2000s web games. When browsers killed NPAPI support, all of it became unplayable. We decided to fix that by rebuilding the Director runtime from scratch.

Today we're sharing dirplayer-rs: https://github.com/igorlira/dirplayer-rs

Rust was the obvious call for this project, as we're parsing decades-old untrusted binary blobs and undocumented bytecode from files we have zero control over. Memory safety wasn't optional. Beyond correctness, we needed predictable frame-rate performance in a browser context. Zero GC pauses matters a lot when you're trying to faithfully emulate a game engine. Rust gave us both without compromise.

The biggest headache by far has been Lingo, Director's scripting language. It's massive. It heavily supports 3D graphics, embedded Flash content, and the worst part: Xtras. Xtras were external distributable plugins compiled from native C code. Getting those to play nicely inside a WASM sandbox has been the most architecturally interesting challenge of the project.

We've successfully implemented the Multiuser Xtra, which opens real socket connections. That's how Habbo Hotel is actually running multiplayer right now. Full support for 3D content and arbitrary third-party Xtras is still ahead of us, but we have a working model for the boundary.

After two years of development, we just released v0.4.1 with full hardware-accelerated graphics. A few proof points that are live and playable right now:

• Habbo Hotel: https://dirplayer.com/habbo
• LEGO Junkbot: https://dirplayer.com/junkbot
• LEGO Worldbuilder: https://dirplayer.com/worldbuilder

This project has been a Rust learning experience for all the contributors. None of us are masters of the language, so there's a few things we'd love feedback on:

• Our approach to the custom allocator we've built for creating and referencing scripting objects
• Architectural bottlenecks: we've made good progress on playback performance but there's still headroom
• Anything in the architecture that looks obviously wrong to more experienced Rust eyes

Happy to get into the weeds on the RE process, the Rust architecture, unsafe usage, or how we're handling the bytecode interpreter. Ask anything.

Hi, we are a group of students building Sonora. While it was initially intended as an extremely lightweight Spotify replacement, it has since grown far beyond that.

Current features include:

• Spotify, YouTube (optional login) support
• Local music library import, virtual playlists, favorites
• Synced/karaoke lyrics, including local music!
• Romanization
• Library management within supported providers
• Gapless playback
• Audio normalization
• Cross-platform support
• Custom themes

Inspired by Zed, which has proven excellent performance using their native cross-platform rendering stack, we have decided to use GPUI. Its awesome text rendering on every platform, ease of use in view composition, and, admittedly, TailwindCSS-like naming conventions all made a significant impact. We have found GPUI to perform extremely well when used and optimized with care. Quite a few patches were introduced to our fork of it to meet our needs in the effects and profiling departments. Thanks to that, I am not hesitant to call our lyrics the most beautiful you can currently get on desktop (Apple Music still beats us HARD on mobile). But despite blur and gradient opacity all looking great, my favorite addition has to be visual render highlighting. But this is too much to cover in a Reddit post, I'll have to write a proper blog post at some point...

What may come as a surprise to folks coming from something like Spotify Desktop is that Sonora actually does not need all of your RAM to function. Tested on linux-x86_64, after 5 minutes of playback it averaged around 173 MiB RSS as opposed to Spotify's ~2GiB. Note that 173MiB is still not a small footprint, but at least with Sonora you know it goes towards caching previews and views instead of feeding the Electron monster merely to keep it alive.

Looking forward to hearing your feedback!

Yes, we did use AI.

I'm sick of all the slop-projects in this subreddit.

Instead of just complaining, I've tried to identify common smells that could indicate the project is slop.

• Using Rust edition 2021
• Using workspace resolver version 2
• Using outdated dependencies

In the last two hours I whipped up a CLI tool that checks for these three smells on a given GitHub project.

It it understandably rough around the edges and I know there are way more smells, like using the words "Phase 0", "Phase 1", having HUGE markdown files, using em-dashes, etc, etc.

I would be very happy to get contributions from fellow flesh-and-blood developers!

Sorry for the negative post, but I'm happy I could at least do something creative with my frustration!

Hi, I’ve been working on Otterlang, a language that’s pythonic by design but compiled to native code with a Rust/LLVM backend.

I think in certain scenarios we beat nim!

Otterlang reads Rust crate metadata and auto generates the bridge layer, so you don’t need to do the bindings yourself

Unlike Nim, we compile directly to LLVM IR for native execution.

Indentation-based syntax, clean readability. But you also get compiled binaries, and full crate support!

Note: it’s experimental, not close to being finished, and many issues still

Thank you for your time feel free to open issues on our github, and provide feedback and suggestions.

repo: https://github.com/jonathanmagambo/otterlang

I started working on this little project on 9th March this year. It's been an incredible journey!

It started with a question of "how hard could it be?" and just yesterday I finally hit the ultimate milestone: IT RUNS DOOM!

Details:

• Github repo: https://github.com/thatmagicalcat/magicalos
• Architecture: x86_64
• Language: Rust (with two C dependencies)
• Bootloader: Limine (initially i was using GRUB/multiboot2 and later i realized it is such a pain in the back)
• C standard Library: mlibc

link to YouTube video: https://youtu.be/xVSqd90Xpos?si=mXFQHOzxMLhDzwFY

building an OS in Rust feels like having a superpower, cargo is so awesome! and the amount of "stupid" bugs the compiler caught before i even hit the metal is probably the only reason i haven't lost all of my hair yet :p

i even wrote a little async runtime in MagicalOS and the way rust handles concurrency is honestly mind-blowing for me

I already loved rust, but this project made me love rust even more!

I would love to hear your thoughts or answers any questions!

Hey everyone,

I'm a 4th year CS undergrad, I've been learning about databases since the last year as I eventually wanted to build one. After giving the build several attempts by sometimes building just the storage engine, or the front-end, etc., I finally did complete the build last week. I felt like its ready to share, so I'm making this post here.

Repo: https://github.com/pixelooz/hinder-db

Its called HinderDb. It's a cli only (for now) database with a custom slotted page B+Tree storage engine, buffer pool, secondary indexes, wal, volcano style execution pipeline, etc.

I wrote it in rust as I like writing rust and this would be another way to get better at it, plus the domain just seemed like a good fit.

It was mostly a learning project for me, but ended up better than I had orginally planned for, so I'm quite happy with that. I originally got interested in databases and stuff through Designing Data Intensive Applications book, and since then always wanted to build one. I had already given the storage engine a couple of tries, by reading some already existing material (Writing your own database type of books) and codebases, but this was the first time writing it complete, and its works quite nice.

I am keeping this as my main portfolio project as well since I'll be applying for jobs/intenships. So, if any working professionals can offer any feedback - something I should improve, any apparent flaws, or the next thing I should look into. I'll really appreciate it.

P.S: I have solid knowledge in backend as well and I'll be applying for on-site (in India) as well as global remote positions, so if you can offer any advice regarding navigating the job market rn, it'd be much appreciated.

Made 3d tetris in ascii using crossterm.
Im currently trying to learn rust, so feedbacks are welcome.

Github repo:- https://github.com/ab-dek/ascii-tris

I kept reinventing tools that already existed, so I built patent which is a prior-art search for code ideas. You give it a plain-English idea; it fans out concurrently to 11 ecosystems, ranks results by cosine similarity using local fastembed embeddings, and asks a local Ollama model for a scoped verdict (Open/Crowded/Saturated + gaps). Output is a ratatui TUI (detail view, sort, filter, mouse) or --json.

Rust-specific notes: clean lib/bin split (testable core + thin CLI/TUI shell), every source is best-effort (one failing never fails the run, "not reached" is surfaced), and the integrity rule "can prove something exists, never that it doesn't" is enforced in verdict.rs (it floors the saturation level against the embeddings and scrubs any absence-claiming copy), not just trusted to the prompt.

• Repo: https://github.com/r14dd/patent
• API Docs: https://docs.rs/patent/latest/patent/
• Crate: https://crates.io/crates/patent

I've spent the last few months building RMUX, a terminal multiplexer written from scratch in Rust.

What it is

A tmux-compatible multiplexer with about 90 command snapshots covered in the docs, plus a second surface: a typed async Rust SDK talking to the same local daemon. Many tmux-style workflows, keybindings, and scripts should feel familiar, but RMUX also exposes structured automation primitives instead of only terminal text scraping.

Architecture

• One local daemon and one wire protocol behind the public surfaces: a tmux-style CLI, a typed SDK, and a ratatui integration crate.
• Native PTY/runtime handling per platform: Unix PTYs + Unix domain sockets on Linux/macOS, real ConPTY + Named Pipes on Windows. No WSL required. Getting ConPTY to behave was one of the hardest parts. And Tokio for async ofc
• The SDK exposes typed handles for `Session` / `Window` / `Pane`, with stable pane IDs, structured snapshots, output streams, and locator-style waits.

Example:

pane.get_by_text("Ready").wait_for().await?;
pane.keyboard().type_text("hello").await?;
pane.wait_for_load_state(TerminalLoadState::Quiet).await?;
pane.expect_visible_text().to_contain("hello").await?;

The public SDK/protocol/render crates use `#![forbid(unsafe_code)]`; unsafe code is isolated in the low-level platform crates that need OS/PTY/IPC FFI.

Why I built it

I've been using tmux for a long time and grew tired of having to do grep every now and since. I then thought that adding playwright capabilities and rewriting everything in Rust would be a game changer. I hope you will like it :) You can do so much: ci, agents orchestration, testing TUIs, building custom dashboards... and it includes natively ratatui.

Repo: https://github.com/Helvesec/rmux

Docs + demos: https://rmux.io

Install: cargo install rmux --locked

 It's a v0.2 preview. Very open to feedback on the architecture, the async API design, or how I'm handling ConPTY. Happy to answer anything.

Hi - this is the rust to C compiler guy!

I compiled the rust compiler to C - thought this would be sth cool to share.

I will gladly answer any questions people have!

Hey all, I've been working on a new type of QR code format that aims to increase the storage capacity.

The concept is pretty simple: traditional qr codes use black & white, whereas qrism uses 8 colors: black white, blue, yellow, red, green, magenta & cyan. Each color represents 3 bits, which gives the format 3× the capacity of a standard QR code.

One thing I wanted to preserve was compatibility with the existing QR ecosystem and standards. The ISO QR specification already defines things like codeword structure, error correction blocks, masking, alignment patterns, etc., and I didn’t want to reinvent all of that. So a large part of the project was designing the encoding system around those existing standards rather than replacing them.

Beyond capacity improvements, I’ve also spent a lot of time improving the reader implementation. Performance and reliability are currently better than libraries like rqrr in my testing, and the decoder fulfils benchmark quality of zxing.

I don’t mean any criticism toward rqrr, in fact I learned a lot by studying it alongside zbar and zxing while building this project.

This is also my first library I've ever published, so open to any feedback, criticism or ideas.

AI was mainly used for understanding concepts & generating docs. The implementation itself, including algorithm and test cases, was handwritten.

DISCLAIMER: The qr code in the image is an experimental QR and will not scan with a regular qr scanner or mobile camera

Github link

Crates link

I love Rust, but async web frameworks feel like overkill for most apps. Too much boilerplate, too many .awaits, too many traits, lifetimes just to return "Hello, world".

So I built Feather — a tiny, middleware-first web framework inspired by Express.js:

• ✅ No async — just plain threads(Still Very performant tho)
• ✅ Everything is middleware (even routes)
• ✅ Dead-simple state management
• ✅ Built-in JWT auth
• ✅ Static file serving, JSON parsing, hot reload via CLI

Sane defaults, fast dev experience, and no Tokio required.

If you’ve ever thought "why does this need to be async?", Feather might be for you.

Update: After great community feedback (including a rename and better practices), I’ve moved the project to the JetCrabCollab org!
New home: github.com/JetCrabCollab/JetCrab

I was working on a project for Node in C++, trying to build a native multithreading manager, when I ran into a few (okay, a lot of) issues. To make sense of things, I decided to study V8 a bit. Since I was also learning Rust (because why not make life more interesting?), I thought: “What if I try porting this idea to Rust?” And that’s how I started the journey of writing this engine in Rust. Below is the repository and the progress I’ve made so far: https://github.com/wendelmax/v8-rust

Note: This isn’t a rewrite or port of V8 itself. It’s a brand new JavaScript engine, built from scratch in Rust, but inspired by V8’s architecture and ideas. All the code is original, so if you spot any bugs, you know exactly who to blame!

Last update:

I wanted to make a dashboard for Home Assistant on my Kindle, and since I know Slint from a previous project I was curious to see if I could use that. This resulted in a slint-backend for kindles (probably not a lot of them for now, as I only have the one device to test on).
https://github.com/sverrejb/slint-kindle-backend

Edit: I wrote a blog post about the project: https://sverre.me/blog/rust-on-kindle/

I've been using mpv-paper on Hyprland for a couple months but ran into really high CPU usage, so I decided to write my own solution.

Phonto uses GStreamer and EGL to keep the entire decoding and rendering pipeline on the GPU, making much better use of resources compared to CPU-based approaches.

A friend also jumped in and added MacOS support, including playing live wallpapers on the lock screen which was a nice bonus.

Still missing a few things like multi-monitor support but that's coming soon. Other feature requests and contributions are welcome!

GitHub: https://github.com/museslabs/phonto

I would like to share with you a project that I've been cooking for some time, a cosy place for devs to hang out :)

https://github.com/mpiorowski/late-sh

Stack: Rust workspace with 4 crates, russh for the SSH server, ratatui for the TUI, axum for the HTTP/WS side, Postgres, testcontainers for integration tests.

License is FSL-1.1-MIT (source-available now, flips to MIT after 2 years), wanted to be upfront about that since it's not classic OSS.

ssh late.sh

That's all, no passwords. no OAuth, no accounts, your ssh key is your identity.

Connect, chat, listen to some vibes and play some GAMES! Right now supporting: 2048, tetris, sudoku, nonograms, minesweeper, solitaire. Leaderboards, badges, streaks, everything with sweet ASCII ;) Multiplayer games coming after! Poker, chess, so much cool stuff :)

Imagine sitting at the blackjack table for a few minutes between your coding sessions, lofi music in the background, chat with people all around the globe, and just throw some chips....

A few things I learned building this in Rust:

- russh render loop backpressure is real, handle.data needs a short timeout (50ms) or a slow client will block your whole render task. Took me a while to figure out why some sessions felt laggy for everyone.

- since the ssh don't allow streaming music, I had to come up with a solution. Paired-client WS state sync (browser/CLI controlling audio from the TUI), a token-keyed registry with mpsc channels into the app, and the TUI sends control events back over the same WS. Keeping the two sides from drifting was harder than I expected.

- ratatui + a 15fps render loop is shockingly comfortable to work with once you stop fighting it. AND I WANTED A VISUALIZER :D

How to listen to music?

Trickier than you would have expected ;p, As I've mentioned, ssh doesn't allow streaming music, so here are your options:

• CLI: recommended, a small companion CLI that connects to the music stream and the app in one go, with a working audio visualizer. Just run:curl -fsSL https://cli.late.sh/install.sh | bash
• WEB: secondary option, a link to open in your browser that will play the music.

(did I mention you can control the music from within the app)

What's more?

• voting system for the next coding music session, everyone decide what will be played in the next 1h (lofi, ambient, classic, jazz)
• fully working chat, create new rooms, dm people. A lot of QOL, multi-line input, up/down navigation, replies, mentions, all the goodies
• news sections! share a link, youtube, twitter, whatever you want app will process it and share with everyone
• BONSAI tree! A cozy ASCII plant on your dashboard that grows while you're connected. If you lose your daily streak, it withers! Water it and watch it grow! Cut to change shape :)
• an actual audio visualizer right in the terminal that syncs up with the beats!

A landing page: https://late.sh

Code (source-available, FSL-1.1-MIT): https://github.com/mpiorowski/late-sh

Looking for contributors! Jump, chill and take a break. Have a good day everyone :)

After getting too annoyed by Spotify's offficial electron client for hogging memory/vram while still not supporting fractional scaling on wayland (by default), I decided to build a fast, native client myself: canora

It it build using my highly experimental UI framework.

AI disclosure: not slop, not low effort, but did use some LLM coding assistance.

Small update on Darkly, an open source photoshop alternative I'm building in Rust + Webassembly. Original post.

Features are coming along nicely and I'm now getting to make the brushes, which is the funnest part 🙏

Can't wait to get this to 1.0!

Website / Demo: https://darkly.art
Github: https://github.com/darkly-art/darkly