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 guys, I'm a high schooler. I was getting really frustrated with standard prep tools (which are mostly just Python wrappers around old C++ code). They are super slow, eat up way too much RAM, and sometimes they just randomly segfault when you feed them a messy PDB file.

So obviously, I decided to rewrite it in Rust lol.

It’s called BioForge. As far as I know, it's the first pure-Rust open-source structure preparation crate and CLI for preparing proteins and DNA/RNA. It basically takes raw experimental structures, cleans them, repairs missing heavy atoms, adds hydrogens based on pH, and builds water boxes around them.

Because it's Rust, the performance is honestly insane compared to what biologists normally use. I used rayon for the multithreading and nalgebra for the math. There are zero memory leaks and it literally never OOMs, even on massive systems. If you look at the benchmark in the second picture, the scaling is strictly O(n). It chews through a 3-million atom virus capsid in about 600 milliseconds.

Also, the best part about having no weird C-bindings is WASM. I compiled the entire processing pipeline to WebAssembly and built a Web-GLU frontend for it. You can actually run this whole engine directly in your browser here: bio-forge.app.

The crate is up on crates.io (cargo add bio-forge) and the repo is here: github.com/TKanX/bio-forge.

I'm still learning, so if any senior Rustaceans want to look at the repo and roast my code structure or tell me how to optimize it further, I'd really appreciate it!

EDIT: A huge shoutout to the maintainers of rayon and nalgebra.

Especially rayon—Rust’s ownership model is basically a cheat code for concurrency. BioForge’s O(n) scaling relies on splitting massive proteins across threads without any global locks.

Achieving 100% lock-free concurrency while keeping it memory-safe is something I can’t imagine doing easily in any other language. Rust made the hard part of systems programming feel like high-level logic. BioForge simply wouldn't be this fast without this ecosystem. 🦀🦾

EDIT: Glad to see so much interest! Just to add some context I missed in the original post: This project is part of my ongoing work at the Materials and Process Simulation Center (Caltech). Huge thanks to Prof. William A. Goddard III, Dr. Ted Yu, and the rest of the team for their incredible guidance on the chemical logic and test feedback.

We will make more Rust crates/projects in the future. 🚀

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.

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!

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.

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.

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!

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.

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/

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'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 :)

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 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.

I made a tiny crate so you can write 5.minutes() instead of Duration::from_secs(300)

I kept copy-pasting this trait into my projects, so I finally published it as a crate.

Before:

let timeout = Duration::from_secs(30);

let delay = Duration::from_secs(5 * 60);

let cache_ttl = Duration::from_secs(24 * 60 * 60);

After:

use duration_extender::DurationExt;

let timeout = 30.seconds();

let delay = 5.minutes();

let cache_ttl = 1.days();

Features:

- Zero dependencies

- Works with u64, u32, i64, i32

- Never panics (saturating arithmetic)

- Supports seconds, minutes, hours, days, weeks, milliseconds, microseconds, nanoseconds

Crates.io: https://crates.io/crates/duration-extender

GitHub: https://github.com/durationextender/duration-extender-rs

This is my first published crate, so any feedback is appreciated!

Working and researching on a CLI tool that diffs code at the entity level (functions, classes, structs) instead of raw lines.

Line-level diffs are optimized for human eyes scanning a terminal. But when you feed a git diff to an LLM, most of those tokens are context lines, hunk headers, and unchanged code. The model has to figure out what actually changed from the noise. I did some attention score calculations as well, and it increases significantly in the model when you feed semantic diffs instead of git diffs.

sem extracts entities using tree-sitter and diffs at that level. Instead of number of lines with +/- noise, you get exact number of entity changes: which struct changed, which function was added, which ones were modified. Fewer tokens, more signal, better reasoning.

It also does impact analysis. sem impact match_entities shows everything that depends on that function, transitively, across the whole repo. Useful when you're about to change something and want to know what might break.

Commands:

• sem diff - entity-level diff with word-level inline highlights
• sem entities - list all entities in a file with their line ranges
• sem impact - show what breaks if an entity changes
• sem blame - git blame at the entity level
• sem log - track how an entity evolved over time
• sem context - token-budgeted context for LLMs

multiple language parsers (Rust, Python, TypeScript, Go, Java, C, C++, C#, Ruby, Bash, Swift, Kotlin) plus JSON, YAML, TOML, Markdown CSV.

Written in Rust. Open source.

GitHub: https://github.com/Ataraxy-Labs/sem

I'm here to present "Gecko" a new, cross-platform and modern GameCube and Wii emulator written in Rust! It's been a work-in-progress project for a while now and I'm extremely happy to finally share it publicly :)

In case you don't care about my ramblings, here's a link to the GitHub repository!

Here's also a 15min video of me playing Final Fantasy Crystal Chronicals: The Crystal Bearers on my Wii emulator!

Many games already work extremely well, but it's very far from being on Dolphin's level! GameCube games tend to work better than Wii games currently, but I know of at least one game that is perfectly playable even on the Wii. More to this a bit later!

Here are some highlighted features:

• GameCube & Wii support
• Cranelift based JIT recompiler (PPC, DSP, vertex parser)
• WGPU based renderer supporting all major platforms
• Modular audio backend
• ISO, RVZ, ZIP support
• Frame pacing
• and much more!

Gecko aims to offer a playable and accurate experience for the average user. However, Gecko is also tailored to reverse engineers and homebrew developers. It's packed with tons of goodies that aren't mentioned in the above list! To name a few more (if you're not interested skip ahead!):

• Lua scripting
• An advanced yet beautiful debugger
• Rich logging system
• Symbol parsing from ELFs and IDA Pro databases
• RenderDoc captures with tons of debug markers
• Multitool to decode/encode IPLs, extract DVD filesystems, disassemble PPC/DSP code
• Recording audio to .wav files
• Built-in diagnostics for JIT and GX (GPU)

The emulator runs on all major platforms, it has been tested on: Windows, Linux, macOS and the browser (incl. the debugger). Here's also an old YouTube video of it (poorly) running on an iPad: https://www.youtube.com/watch?v=ACW36TXlUhM, because why not?

I also automated screenshot gathering over a selection of games, these are hosted here (mainly used to catch regressions/improvements, but also useful to gauge compatibility):

• GameCube
• Wii

I'd be more than happy to see people try it out, share their experience and perhaps even contribute!!

To finish up the post I'd like to also share the "Why?". Why does this emulator even exist? I've always been very interested in low level stuff and figured I could do something to make 12yo me proud: Create an emulator that can play my childhood favorite game (Final Fantasy Crystal Chronicles: The Crystal Bearers on the Wii). I ended up going on a multi-year journey learning about emulator development, with the goal to improve my skills and ultimately do Wii.

I mentioned earlier that a game is already perfectly playable on the Wii... That is my childhood game, so to me, this project is already a huge success despite it not being anywhere as mature as Dolphin! :)

hi! for the past 6 months, i've been working on a GameCube emulator all by myself on my free time. it's called lazuli.

while far from perfect, it is able to boot multiple games and homebrew. the compatibility list keeps growing :)

here's a video of me messing around in Super Mario Sunshine.

this has been the most fun personal project i've ever worked on, full of interesting problems and opportunities for fun stuff. here's some of the cool things the project has:

• a PowerPC JIT using cranelift
• a vertex parser JIT, also using cranelift
• wgpu based renderer
• wesl based shader generator
• cpal based audio backend

if you think this is an interesting project, consider trying it out and sharing your opinion, or even contributing!

here's a link to to the repo (which also contains prebuilt binaries for linux and windows).

https://github.com/jams246/i-built-i-built-builder

I've been seeing a lot of:

I built ...

posts here recently and I realized that the real missing piece was not another CLI tool, but a tool for building tools that are built to be posted as "I built" posts here on reddit.

So what is this tool? I'm glad you asked!

I built I built builder is a CLI that scaffolds Rust CLI tools whose natural end state is an "I built" post. With I built I built builder, you can build a tool, build the README, build the release workflow, and build the post explaining that you built the thing that I built I built builder helped you build.

In other words, I built I built builder to help people say "I built" with more consistency, velocity, and mechanical sympathy.

The idea is simple: instead of building a tool and then separately writing about how you built it, I built I built builder helps you build the thing and the "I built" around the thing you built.

Example:

i-built-i-built-builder --name tomlshave --solves "trimming whitespace in embedded TOML snippets"

That command lets I built I built builder scaffold the tool, build the docs, and build the "I built" narrative around why the built tool needed to be built.

Anyway, I built I built I built builder, and now I’m posting that I built I built I built builder so that other people who build tools can use I built I built builder to build better “I built” tools and better “I built” posts about the tools they built.

Feedback welcome. Validation preferred.

About 7 months ago, I started working on Mellow, using GTK and Rust. The goal was to create a music player with a simple and minimal interface, while also having all of the features that a local music player is expected to have, as well as to try some new ideas and attempt to innovate. It was something that I've been tossing around my mind for years, but never really had the motivation to work on until now.

Having had no prior experience with GStreamer or GTK, and being fairly new to Rust, I am very proud of how this project has so far turned out. The beginning was quite rough, and working with GTK has at times been a bit frustrating, but overall, it has been a very rewarding experience. There is always something new to learn about Rust, which I really enjoy. This project has also taught me the importance of defining your vision and scope early on.

Despite the player still having issues and missing certain features (both of which you can read more about on GitHub), I've decided that it is time to publish the first pre-release, and made the GitHub page public. I believe that the player is already a stable and pleasant experience; however, I do still occasionally discover new issues while using it. If you decide to give it a try, please report any issues you may encounter.

Disclaimer: I do not use AI for any of my projects (or otherwise).

I've improved the implementation behind all the string formatting macros in Rust: println!(), panic!(), format!(), write!(), log::info!(), and so on. (That is, everything based on format_args!().) They will compile a bit faster, use a bit less memory while compiling, result in smaller binaries, and produce more efficient code.

'Hello world' compiles 3% faster and a few bigger projects like Ripgrep and Cargo compile 1.5% to 2% faster. And those binaries are roughly 2% smaller.

This change will be available in Rust Nightly tomorrow, and should ship as part of Rust 1.93.0 in January.

Note that there are also lots of programs where this change makes very little difference. Many benchmarks show just 0.5% or 0.1% improvement, or simply zero difference.

The most extreme case is the large-workspace benchmark, which is a generated benchmark with hundreds of crates that each just have a few println!() statements. That one now compiles 38% faster and produces a 22% smaller binary.

Hi,

I’ve been working on a Rust plotting library called Charton. I wanted to bring a true "Grammar of Graphics" experience to Rust, similar to what Altair does for Python or ggplot2 for R.

I’ve always felt that many Rust plotting tools are either too low-level—where you have to write dozens of lines just for a simple chart—or they’re just too rigid. To fix this, I built Charton with a custom Dataset engine that feels a lot like Polars. You can feed it native arrays, vectors, or Polars DataFrames directly, and it handles the data very efficiently.

The API is minimal by design. In most cases, you can get a plot done in a single line. It uses a layered approach, so you can stack different marks to build complex visualizations. Right now, it supports 9 core types: points, bars, lines, area, rect, boxplots, rules, ticks, and text.

Here’s a quick look at how you’d use it:

```rust let height = vec![160.0, 170.0, 180.0]; let weight = vec![60.0, 75.0, 85.0];

chart!(height, weight)? .mark_point()? .encode((alt::x("height"), alt::y("weight")))? .save("out.svg")?; ```

And for layered chart:

```rust // Create individual layers let line = chart!(height, weight)?.mark_line()?.encode((alt::x("height"), alt::y("weight")))?; let point = chart!(height, weight)?.mark_point()?.encode((alt::x("height"), alt::y("weight")))?;

// Combine into a composite chart line.and(point).save("layered.svg")?; ```

Next on my list is adding a WGPU backend for hardware acceleration and integrating with Nushell for terminal-based plotting.

However, I’m curious to hear from the community: What are you looking for in a Rust plotting library? In what direction should Charton evolve to best fit the current trends in the Rust ecosystem?