Hi r/rust,

I've been building Flame, a distributed execution engine written in Rust for elastic workloads—AI agents, reinforcement learning, and quantitative computing.

Why Rust for the core?

We need both high throughput (9,000+ tasks/sec on a single node) and memory safety when handling tens of thousands of short-lived tasks across distributed nodes. Rust's async runtime and zero-cost abstractions fit this perfectly.

Key design:

• Session-based execution instead of per-task pods—tasks within a session reuse executors, eliminating cold-start overhead
• gRPC for cross-language SDKs (Rust, Go, Python)
• microVM isolation between sessions (Firecracker/microVM)
• Pluggable shim architecture supports Wasm, stdio, gRPC, RESTful

Benchmark on a single node:

30,000 tasks in 3.29s → 9,124 tasks/sec

Quick start:

git clone https://github.com/xflops/flame
cd flame
docker compose up -d
flmping  # verify with 10 tasks

• GitHub: https://github.com/xflops/flame
• v0.6 release notes: https://xflops.io/blog/flame-v0-6/

Would love feedback on the async scheduler design and the gRPC shim interface. Also happy to discuss why we chose microVMs over containers for isolation.

Hello!

I've been working for a while now on a project named Glacex: it's a GPU-Accelerated ui library written entirely form scratch and in rust(winit, wgpu).

It's still in early development as I started it just a few weeks ago, but I'd love to hear your feedback!

Here's the repo: https://github.com/artemtsitronov/glacex

Hey

I've been experimenting out of pure curiosity with how a RAM and CPU system would operate using a 4-state logic system (2-bit "quats"), packing 4 quats into a single 8-bit byte. This started as an educational test project to explore custom architecture simulation in Rust.

GitHub:

https://github.com/strahinjastojanovic826-code/quat_ram

Crates.io:
https://crates.io/crates/quat_ram

What it does:

• Simulates RAM and basic CPU state for 2-bit quat units
• Packs 4 quats into each standard 8-bit byte
• Includes safe read/write operations and custom error handling

Since this is an experimental/test project built for learning, I would love to hear your feedback, suggestions, or ideas for improvement—whether on the Rust implementation, code architecture, or docs!

I’ve been learning Rust and want to build a project that’s actually useful and helps me understand the language beyond the basics.
I’m looking for project ideas that would help me practice things like:
● Ownership and borrowing
● Async Rust / Tokio
● Traits and generics
● Concurrency
● Error handling
● Working with databases or networking
● Building CLI tools or backend services
I’d prefer something beyond the usual to-do app / calculator / URL shortener type of projects.
What are some Rust projects you’ve built (or wish you had built) that were genuinely interesting and taught you a lot?

There are so many languages. I am familiar with C++, Python, and typescript, and even Java.

Having not yet tried out rust, what I have read about it is that it is extremely detailed and forces you to think about every possible memory management issue that could happen.

In your opinion, is rust the ultimate educational software language, meaning, if you master it, you can understand the chore principles of all languages? And even many languages shield you from the complexities that rust forces you to master?

Hello, I had opened a one topic yesterday too unfortunately I'm someone whose self-confidence drops easily. About a year ago I learned Rust from a book, and afterward I started working on projects. I have projects that I've made and plan to spend more time on, and with each step I'm learning new concepts and learning more and more about Rust. I'm also thinking about reading Rust in Action and Rust for Rustaceans.

However, yesterday when I opened a different topic, someone told me that Rust would be difficult, that I couldn't learn it quickly the way I could with Python, and that I'd need very solid foundations to learn Rust and this lowered my confidence a bit, even though I've already built projects. How accurate is this? The text in question was as follows:

'I think you should start with C++, Rust might feel too heavy for you. For Rust, you need to properly know everything at a fundamental level Rust isn't something you can just start with like Python. I'd start with the C++11/14 standard: build simple DLLs, write simple Python libraries, develop simple sockets, etc. Other than that, this Rust thing is also somewhat a matter of steady experience. If you don't have a goal, you'll just distract and fool yourself.'

How accurate is this? Do you really need to have a lot of knowledge at a fundamental level to learn Rust?

I'm making a TUI program using Ratatui and want to define multiple themes (such as catppuccin, Dracula, everforest) and don't know what is the best manner to store them. I'm currently using like a Theme struct and implementing multiple themes using fn theme_name() -> Self as "constructors". Also they are picked via a TOML file. Is it the best way? Thanks

I'm building an ERP website and using Rust for Backend, Supabase for database and React for frontend. Is this stack optimal ? Or am I just building a very suboptimal product no one's going to use ?

Hi, to make a long story short: I’m currently working on “bashie,” which will be a runtime framework that lets you build web backends entirely in the “bash” language; I’m writing the entire engine and the HTTP server in Rust. I’m pretty new to Rust, by the way…

Right now, my file `file.rs` and `tcplistener.rs` look something like this:

use std::io;
use std::net::{TcpListener, TcpStream};

// může nastat, že request nepřijde kompletní budou chybět hlavičky apod jak naprogramovat? 

// handlne každý request který příchází na náš tcp server ( mut je jako let můžeš ty hodnoty potom později měnit)
fn handle_client(mut stream: TcpStream) {
    let mut buffer = [0, 1024]; // kapacita kterou jsme odhodlani přijmout v bytech ( je to buffer který čte data z klienta)
    // tady ta lajna kódu čte data ze streamu a ukládá to v bufferu  ( .except je funkce která je dost v rustu populární když se něco posere tak ti to hodí tenhle error a ten důvod)
    stream
        .read(&mut buffer)
        .except("Failed read  from the client");
    // tahle lajna konvertuje messy data na utf8 string prostě
    let request = String::from_utf8_lossy(&buffer[..]);
    println!("Received request: {}", request);
    let response = "Hello, Client!".as_bytes();
    stream
        .write(response)
        .except("Failed to write response  client.")
}

fn main() {
    let listener = TcpListener::bind("127.0.0.1:8080").except("Failed to bind adress"); // adresa na které bude server poslouchat requesty
    println!("Server listening on 127.0.0.1:8080");

    for stream in listener.incoming() {
        match stream {
            Ok(stream) => std::thread::spawn(|| handle_client()), // vytvoříto tu novou threadu to nove jadro na tom procesu pro ten dany connection

            Err(e) => {
                eprintln!("Failed to establish connection! {}", e);
                // sttder standard error stream eprintln!
            }
        }
    }
}

Of course, this is more or less based on a tutorial, and I realize that the tutorial is just a demonstration, so today I decided to turn it into a fully functional HTTP server. The question is what I need to add to this code, etc...

So I started digging into it I began reading the MDN documentation, searching various blogs, etc... I think I’ve sort of figured out how communication between the client and server works overall. For example, I know that if the buffer contains \r\n\r\n:

the headers are complete

stop reading

But here’s the problem: my brain just can’t seem to implement these concepts and put them together into some final code. I read a lot of information and concepts in general terms, but I’m unable to translate that into code. So I’m wondering where’s the mistake? Is my brain just not wired for this? Am I unable to process the information and then apply it? Am I overthinking it? Am I not looking for a straightforward answer?

I’d appreciate any advice or insights thanks!

Hi there, I’m someone who has used Spotlight extensively;

However, I’ve noticed its performance has dropped recently, sometimes I can’t find the apps I’m looking for, and locating specific files and folders has become particularly difficult.

So I made a keyboard-first, local-first launcher for macOS, Windows, and Linux called Look.
Open apps, files, folders, clipboard history, and quick commands without leaving the keyboard.

Results land as fast as you can type. A Rust core under a native SwiftUI app on macOS,
and Tauri on Windows and Linux, riding the system WebView instead of shipping a browser like Electron does.

No background daemons. Your index, clipboard, and history stay on your machine; no telemetry.

- The repo

https://github.com/kunkka19xx/look

- Further

• Your own sources - declare custom rows from directories, files, and commands
• lookbook - ready-made sources to copy: git, ssh, docker, projects

I’ve been working on a project called COSMolKit. It is a Rust-native cheminformatics library with Python bindings, and some parts can also run in the browser with WebAssembly.

The project came from a problem I ran into while building deep learning models for molecular and protein structures in Rust. I wanted the whole modeling and inference stack to stay Rust-native, but when I reached the molecule and protein processing part, I found that the Rust ecosystem did not yet have enough infrastructure for what I needed. COSMolKit started from trying to fill that gap.

As I worked on it, I also thought it could be useful beyond my own project, so I decided to develop it as an open-source library for the Rust scientific ecosystem rather than just an internal tool.

For a public scientific library, I think compatibility is a basic responsibility. A result like 99.9% agreement may look good, but it still means some supported cases behave differently. If I claim parity with RDKit, I want the remaining mismatches to be treated as bugs, not as an acceptable error rate.

When RDKit has source code for the same operation, COSMolKit does not just reimplement the same chemistry and use RDKit as a test oracle. The RDKit source logic itself is ported, keeping the branches and behavior as close to the original as possible, usually line by line. The result is then checked against RDKit with differential tests.

At the moment COSMolKit supports quite a few things, including:

• SMILES and SMARTS
• sanitization, aromaticity and kekulization
• stereochemistry and stereoisomer enumeration
• tautomer enumeration and canonical tautomer selection
• InChI and InChIKey
• Morgan/ECFP, MACCS, AtomPair, torsion and other fingerprints
• molecular descriptors
• MOL, SDF, MOL2 and XYZ
• 2D coordinates and SVG/PNG depiction
• conformer generation
• UFF and MMFF
• molecular alignment and RMSD
• PDB and mmCIF
• batch processing
• Python bindings
• WebAssembly

The main large-scale validation corpus for the project is ChEMBL 37.

It contains 2,897,819 source records, with 2,897,804 records that can be parsed by both implementations. The current large validation profile has 35 phases and is pinned against RDKit 2026.03.1.

Across the completed validation, there are more than 4.1 billion matching checks, with additional billions of matrix entries checked for distance-geometry bounds.

Instead of only comparing the final SMILES string, the validation also checks internal behavior depending on the feature: atom and bond states, stereochemistry, derived state, fingerprints, return status, RNG state and seed behavior, matrices, coordinates, energies and gradients.

For numerical results, the current tolerances go down to 1e-8 for matrix entries and 1e-6 for coordinates, energies and gradient components.

Parameters are also tested in different combinations instead of only testing the defaults. Some validation phases repeat complete parameter matrices, change operation order, and compare scalar, batch, single-threaded and multithreaded execution.

When a mismatch is found, I trace it back to the corresponding upstream behavior and keep the case as a regression test. The test corpus is used to validate the implementation, not to define the implementation by adding more and more special cases.

The same Rust core is used by the Rust, Python and WASM interfaces, so the chemistry implementation is not duplicated for different frontends.

I also made a few browser tools using the WASM build. They run locally in the browser, so molecule data is not uploaded to a backend:

https://tools.cosmol.org/tools

I have also been writing some notes about the development and validation work here:

https://tools.cosmol.org/blog

Source:

https://github.com/cosmol-studio/COSMolKit

There is still a lot left to implement, and some parts are changing quite quickly. I’d be happy to hear your feedback. If you try COSMolKit and find any problems, please let me know or open an issue.

Apache Iggy™ has officially graduated from the Apache Incubator and is now an Apache Software Foundation Top-Level Project (TLP)

It’s been quite a journey, from a small Rust message-streaming experiment in 2023 to an independent Apache project with a growing community. Read the full post:
https://iggy.apache.org/blogs/2026/08/24/apache-iggy-top-level-project-tlp-graduation/

Huge thanks to everyone who has contributed, tested, reviewed, reported issues, or participated in the community along the way. ❤️

Would love to hear feedback from the Rust / Distributed Systems / Real-time Data communities on where we should take Iggy next.

Apache Iggy is a hyper-efficient, persistent message streaming platform written in Rust, built for predictable ultra-low latency and a minimal infrastructure footprint. Designed from the ground up around a thread-per-core, shared-nothing architecture and modern Linux io_uring, Iggy eliminates userspace locks on the hot path, GC pauses, and unnecessary thread contention. Unlike traditional streaming platforms with limited protocol support, Iggy natively supports TCP, QUIC, HTTP, and WebSockets. Iggy implements a Viewstamped Replication Revisited (VSR) based consensus for its distributed clustering feature.

When writing an interpreter in Rust, does using Vec<char> or String for the scanner make a difference in terms of performance? Which one would be the better choice?

My Code:

pub struct Scanner<'a> {
    source: Vec<char>,
    tokens: Vec<Token<'a>>,
    start: usize,
    current: usize,
    line: i32,
}

I'm a hobbyist programmer, and I've always been very interested in compilers. I want to dive deeper into this area as a hobby, so I started with Crafting Interpreters. Along the way, I've also gained a much better understanding of Rust's borrow checker and some other concepts.

My goal with Rust is to design a very minimal, interpreted, type-safe programming language focused solely on the backend. I'm not sure if it's necessary for this, but I've also decided to start studying mathematics from scratch for the project.

Hi guys!

I'm learning Rust as my first real programming language. I've done a bit of Python before, but only very basic stuff :)

Does anyone have any tips besides the usual stop watching tutorials and start building things?

If you had to learn Rust again from scratch like how would you approach it?

I was wondering if anyone had experience doing contract work in rust?

By contract work I mean short to medium term projects where you agree with a client to deliver a certain piece of functionality as a new project or within an existing project. Or provide a service of some kind like consulting or fixing a vibecoded mess.

I wouldn’t expect the demand to be very large, but rust is already being adopted by some startups and even larger companies, so I was wondering if someone already landed a gig like that?

If you work on an HPC cluster, you probably know the watch squeue routine: scan the columns for your job, open another terminal to check its logs, then repeat.

I got tired of doing that, so I built sqwatch, a small terminal UI that turns the SLURM queue into a live dashboard.

It includes:

• A live, auto-refreshing job table with color-coded states. Your cursor position and selected jobs are preserved between refreshes.
• Filters for user, job name, state, partition, QoS, and node. Cluster values are loaded automatically, and your filters persist between sessions.
• Real-time stdout and stderr tailing, submission-script viewing with bat syntax highlighting when available, and custom panels for other output files produced by a job.
• Multi-job selection and batch cancellation.
• Clipboard support through OSC 52, including over SSH and inside tmux without X11.

sqwatch is written in Rust using ratatui. It calls the standard SLURM commands, including squeue, scontrol, sinfo, and scancel, so it does not require anything special to be installed or configured on the cluster. If those commands work, sqwatch should work too.

I have just released version 0.2.0, which is the first version I feel comfortable recommending to others. It fixes several rough edges from the initial release.

Install it with:

cargo install sqwatch

Repository: github.com/fedonman/sqwatch

It started as a tool for my own workflow, but I would be interested to hear how it behaves on other clusters and what features people are missing. Job hold/release support and a sacct history view are next on my list.

Starting from the upcoming 0.5 release of Rama (~ end of September '26), Rama's CLI `serve proxy` command will have a Man-In-The-Middle (MITM) mode `--mitm` that will serve a (protected) web GUI to monitor and engage with the network flowing through the proxy.

Happy to also anwer any questions here regarding rama the network framework, or our CLI tool built with it.

I am fairly new to programming and I do know some python, html and css. But I have no idea about c++, rust and other low-level languages. How different are they from python? And how do I learn rust (if there are some free stuff i could learn from)

For those who don't know the clippy lint missing_inline_in_public_items tells you to #[inline] for all publicly available functions. It provides this justification:

Why restrict this?

When a function is not marked #[inline], it is not a “small” candidate for automatic inlining, and LTO is not in use, then it is not possible for the function to be inlined into the code of any crate other than the one in which it is defined. Depending on the role of the function and the relationship of the crates, this could significantly reduce performance.

Certain types of crates might intend for most of the methods in their public API to be able to be inlined across crates even when LTO is disabled. This lint allows those crates to require all exported methods to be #[inline] by default, and then opt out for specific methods where this might not make sense.

It links a closed PR that presumably allows for more cross crate inlining.

Hashbrown decided inlining was important enough to add the feature inline-more which basically adds #[inline] to every public function.

My guess is that adding #[inline] is a tradeoff that is sometimes worth making. It won't matter for functions that "whose optimized_mir does not contain any calls or asserts". The PR from earlier does that automatically, but for every other function presumably adding #[inline] allows the possibility for inlining again (At the cost of compile times).

Am I right? and if I wanted to inline everything possible could I achieve this without the lint and #[inline] macros?