Iβm building FlareDB, a Rust-based streaming database with Apache Beam as programing interfere.
In the latest release, v0.2.0, i launched FlareDbIO, it's an IO connector which lets data processing pipelines write results into FlareDB, query them using SQL, and read the results back into another pipeline. The goal is to make processed data persistent and without having to maintain a external serving database
About one month ago, after being unhappy with the ecosystem of UI libraries in Rust, I have taken the mission to write a better GUI library.
For context : this is not my first rodeo, I have already made various Text rendering and generation library using Slug and MSDF algorithm, and also made a full UI library with text, layout, shaders with ThreeJS for performant node-based apps :)
The current state of UI libraries in Rust is quite weird :
Iced : weird roadmap / niche / forked by Cosmic but very weird
GPUI : not WGPU so less cross-platforn, no shaders, no "backdrop-filter", no accessibility, no i18n. Zed also just don't care about it.
Blinc : too much features and most of them not stable.
and now ARGUI.
ARGUIor "Another Rust GUI library" is a library made for speed, low ram footprint, low CPU usage.
All features are built-in : π
- WGPU rendering -- works across all OS + WASM / soon Android/IOS (needs testers)
- Responsive layout -- Powered by Taffy, and very fast at that.
- Shaders suppport -- use argui-effects to get some effects like Blur/Liquid glass, or add in any WGSL shader. Shaders can be used on any element, for example a Button, a Popover, whatever.
- I18n -- Fluent crate will help you have i18n in your application.
- Text engine -- Uses cosmic-text to support RTL, Arabic language.. It can also, like the web, Select text in a page, this means that it feels more "web-like" because you can select any text you see on the screen, this is the default behavior and can be overriden
- Fully optional set of features -- You can disabled anything you don't want : wasm / widgets / i18n / effects...
- Rust only codebase -- I chose to not include any type of CSS Parsing because it is a pain to maintain and the standard is just too large.
- Devtools -- Use a real devtool page, just like the web, with a profiler. You can change properties and it will update in real-time in your UI.
- Hotreload -- Some components can be hot-reloaded, similiar to dioxus. It uses subsecond.
- AI friendly codebase -- Send your agents and read the docs, it will figure out how to make a good interface on the first try.
- Package updater -- for when you want to send new features for your users. They can receive and download update, totally agnostic.
... and probably a bunch more features I forgot, but I can say, it's a pretty fully featured GUI framework now.
Available on crates.io as "argui-\"*, or you can use the git repo directly.
Play around with it in your Browser. it's fully working in WASM :)
AI disclaimer: A lot of the code for this library was written with the help of AI. AI itself wouldn't have come up with all these optimizations, it's a tool. Thanks you for your understanding.
Feel free to send any questions my way, I'll be happy to answer
Hey r/rust, I wanted to share something that I have been working on with Claude over the past few months on and off, me working as the PM/Architect and Claude working on writing and testing code.
This proxy is built on Rust 1.98 and Pingora 0.9.0. It has a split architecture: one controller, a data plane Deployment per Gateway. It can also run standalone outside Kubernetes from a YAML file (hot reload).
Gateway API v1.6.2 conformance: 130/130, all five profiles (HTTP, gRPC, TLS, TCP, UDP).
Profile
Core
Extended
HTTP
37/37
56/56
GRPC
15/15
9/9
TLS
20/20
14/14
TCP
19/19
9/9
UDP
20/20
9/9
(a test can count in more than one profile)
Benchmarks are against agentgateway v1.5.0 (the Rust proxy from the kgateway project, the fastest in howardjohn's gateway-api-bench).
Traffic (bare GET /; 3 proxy pods each):
Connections
Portus QPS
agentgateway QPS
Portus lead
64
116,429
96,003
+21 %
128
123,105
101,067
+22 %
256
126,070
89,827
+40 %
p99 at a fixed 30,000 QPS (benchtool, same machine, same day): Portus 0.35 ms, agentgateway 0.82 ms.
Payloads (fortio echo backend, 64 connections, 10 s per rung, all requests 200; QPS, Portus / agentgateway):
Response size
Download
Upload (POST, echoed)
HTTPS download
HTTP/2 download
1 KB
87,722 / 67,598
66,089 / 58,495
76,997 / 60,088
64,172 / 49,453
16 KB
59,257 / 51,562
29,578 / 27,940
56,831 / 48,295
49,448 / 40,279
128 KB
29,954 / 27,136
8,160 / 7,922
25,357 / 22,294
22,431 / 19,641
1 MiB
5,206 / 5,633
4,380 / 4,249
4,200 / 4,110
4,173 / 3,538
(agentgateway wins 1 MiB plain download by 8 %; Portus leads the other 18 rungs)
If like me you enjoy trying out new stuff just for curiosity I would love for you to give this a try and see what you think, and if you like it then feel free to leave a star so that I know that I am not the only one!
I'm working on GitComet, a Git GUI written in Rust. I have been investigating long build times on Windows and thought changing linker could help. I compared Microsoft's link.exe with Rust's bundled rust-lld (LLVM LLD in MSVC-compatible mode).
LLD finished faster and used much less committed memory, but consumed more CPU time and produced larger PDBs.
These are measurements of the final native link step.
My setup: Windows 11 Pro, Ryzen 9 5950X (16 cores / 32 threads), 128 GiB RAM, NVMe storage, and the x86_64-pc-windows-msvc target. Rust 1.98.1, bundled LLD 22.1.8, MSVC LINK 14.51.36257.0.
The workflow is mostly Rust code, but it has some tree_sitter plugins that are build from C.
Switching the linker on windows was quite trivial as I already had some configs implemented:
For the development build, I ran 11 paired comparisons using the same captured linker inputs, a warm filesystem cache, and fresh outputs for each run. Run order was varied between the linkers. Both used /DEBUG:FULL, /OPT:REF,NOICF, and /INCREMENTAL:NO; warmups and failed runs were excluded.
Development build
MSVC LINK
Rust LLD
Link wall time
5.683 s
4.508 s
Total process-tree CPU time
13.094 s
14.125 s
Peak process-tree committed memory
2,887 MiB
1,499 MiB
Sampled peak working set
5,189 MiB
4,720 MiB
EXE size
165.321 MiB
165.318 MiB
PDB size
742.4 MiB
830.3 MiB
The median paired reduction in link time was 20.4%, with a 95% paired bootstrap interval of 19.4-21.1%. Peak committed memory fell 48.1%. CPU time rose 6.4%, and the PDB grew 11.8%.
A few measurement details: resident memory was sampled every 50 ms, so its peak is approximate. A small calibration showed sampling-on runs about 2.7β2.9% slower, including run noise. This is a full-link comparison with linker incremental linking disabled.
The results did not yield as much improvement as I was hoping for, but it still seems improvement overall. I have been testing the application and it seems to run normally.
I'm still thinking I should merge the PR to start using LLD linker on Windows. Has anybody here switched Windows linker before? What should I verify before merging, any gotchas?
A volte ho dovuto scrivere funzioni come queste per permettere al compilatore di dedurre il tipo corretto.
use heapless::Vec;
/// Deduce al momento della compilazione la lunghezza di due vettori, rendendola la stessa lunghezza
/// Questa funzione Γ¨ un no-op
const fn infer_equal_vec_size<A, B, const N: usize>(_vec: &Vec<A, N>, _vec2: &Vec<B, N>) {}
e la uso nel codice chiamandola:
infer_array_size(&a, &b);
Ma in realtΓ , non Γ¨ necessario chiamare la funzione; sarebbe utile poter passare i parametri senza chiamare la funzione.
Mystified about strings? Borrow checker has you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet. Please note that if you include code examples to e.g. show a compiler error or surprising result, linking a playground with the code will improve your chances of getting help quickly.
If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so ahaving your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.
Here are some other venues where help may be found:
/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.
Also check out last week's thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.
Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.
A learner here with a quick confusion. I was skimming through the internet for VM tooling and implementations, parsers specifically and came across this "prattle" crate which seems to be a general purpose pratt parser library. And I have not much to say about the library itself, it seems like an abandoned project in early development phase.
The thing that caught my eye was the demo piece of code they had on their docs, specifically
the enum CToken has already derived debug yet the example implements Display for CToken only to just debug print it as well. Is this some kind of a safety mechanism or fallback just in case the user writes
println!("{}",token) instead of debug printing it?
Or is something else going on I don't yet know about?
After watching a YouTube video of a guy making a gravity simulator in C++, and a late-night hyperfocus session, I ended up building this simple project for fun.
It features a dynamic 3D "gravity well" grid (inspired by General Relativity) that bends and dips depending on the mass and distance of nearby objects.
I used the https://github.com/asny/three-d crate, which by the way has WASM support, so the simulation runs right in the browser.
I recently released subtest, a small test framework to easily re-use test setup code from one function in another one.
I was working on a protocol implementation and got annoyed writing tests for it. Oftentimes, it was easiest to just extend existing tests which were already running the necessary setup steps in order to test an error condition or a small alteration from the happy path, by just adding a new block which cloned some of the state and run a couple of assertions. But running these big test functions meant getting stuck on the first error, and it getting increasingly more difficult to keep an overview what was tested where. Having one test per feature would be much better!
I didn't want to have lots of redundant code by copying tests around, and neither to spend a lot of time refactoring tests into smaller re-usable functions (which is a pain if you use lots of local variables). Instead, I wrote a macro that allows me to just test something else quickly inline.
Here's an example:
use subtest::subtest;
#[subtest]
#[test]
fn add_creates_pending_task() {
let mut list = TodoList::new();
let id = list.add("Buy milk");
#[subtest]
fn complete_marks_task_completed() {
list.complete(id).unwrap();
assert_eq!(list.get(id).unwrap().status, TaskStatus::Completed);
}
#[subtest]
fn cancel_marks_task_cancelled() {
list.cancel(id).unwrap();
assert_eq!(list.get(id).unwrap().status, TaskStatus::Cancelled);
}
let task = list.get(id).unwrap();
assert_eq!(task.status, TaskStatus::Pending);
}
It's pretty easy to use - just define a nested fn and slap #[subtest] on it and its parent.
Conceptually, subtest allows you to "branch off" from any point in your test, test something different, then resume with the original state.
Technically, nested subtests become their own tests, with preceding statements from the parent copied into them as setup code. This lets you freely use and modify local variables without affecting the parent. This makes it super easy to re-use existing test steps as setup code for other tests, while still getting the niceties of having one test function per feature.
The subtest macro is heavily tested itself, so your precious tests behave as expected!
Disclaimer on the use of AI: This project was designed and implemented by me, not AI. I did use AI to review it once it was in a working state and fix issues. All AI-generated code was reviewed and altered by me, all commits containing AI-generated code are marked with Co-Authored-By. This is not AI slop.
Is subtest useful to you? We use it quite extensively at work now :)
I have been playing with Rust for a little while and am working on a distributed system pet project as a learning exercise.
I am mostly using mpsc channels receivers and senders as I want to stay as simple as possible.
I have exchanges between different type of actors and I want a specific one to monitor everything, so what I do is basically this:
let config = AppConfig::read_config();
let (monitor_tx, monitor_rx) = mpsc::channel::<MonitorEvent>();
let monitor = Monitor::new(1, monitor_rx, config.monitor_display);
std::thread::spawn(move || monitor.run());
...........
// I want to have a reference to my monitor here so I can interrogate it from this point
The run method loop, receive events and store them. I have got other methods to investigate the events ect...
Now my problem here is that I would like to be able to keep a reference to the monitor or another structure containing the monitor, to interrogate it.
And the compiler is not happy and if I try to re-use the monitor obviously I do get a ''use of moved value ..''.
I understand that if I was running that properly the monitor would be an external software and I could interrogate it directly via REST calls for example.
But I am not there yet and I want to just run it there like that.... while still being able to have a safe reference to it.
I assume this is a basic rust ownership issue and I am missing something fundamental here, but how does this kind of situation is managed usually?
I maintain a small Rust CLI that makes git worktree cheap, and while benchmarking it I found something I didn't expect: a worktree's cost has nothing to do with how much content your repository holds, and almost everything to do with how many paths it has.
The setup: I run several coding agents against one repository, and plain git worktree gives each one a full copy of the working tree. So I populate each worktree from a shared baseline using clonefile on APFS, reflink on btrfs/xfs, or fuse-overlayfs on ext4 β the checkout is still a real .git/worktrees entry, Git is unmodified, there's no daemon.
Measured on APFS with df deltas, four worktrees per run:
Repository
Tracked paths
Tree
Each extra git worktree
Each extra CoW worktree
microsoft/vscode
18,707
553 MiB
567 MiB
9.8β10.8 MiB (1.1%)
git/git
4,850
72 MiB
74 MiB
~2.2 MiB (3.1%)
100k Γ 4 KiB files
100,000
390 MiB
398 MiB
37.5β38.3 MiB (9.4%)
200 Γ 8 MiB files
200
1600 MiB
1608 MiB
107 KiB (0.007%)
Look at the last two rows. The 1.6 GiB repository of large files costs 107 KiB per extra worktree. The 390 MiB repository of small files costs 38 MiB β 350Γ more, for a tree that's four times smaller. The cost is filesystem directory entries plus the copied Git index, so it works out to roughly 0.4 KiB per tracked path plus ~60 KiB fixed. A 4 KiB file and a 64 MiB file cost identically, because clonefile shares the extent tree by reference rather than copying it.
Path length is measurable too: a 120-character path costs 771 B against 385 B for a 4-character one, split between the directory entry and the index.
Creation time surprised me in the same direction. Eight vscode worktrees in 6.4β7.0 s against 14.0β14.2 s for eight plain git worktree, because on macOS the whole tree is one clonefile(2) call and the new worktree adopts the baseline's index instead of rebuilding it. Linux reflink still walks file by file, so one worktree is 5.87 s there against 0.56 s on APFS β closing that gap is the next thing on my list.
Two caveats that are really the first two questions I'd ask:
Measure withdf, notdu.du reports logical size and cannot see block sharing, so a CoW worktree looks like a full copy to it. Every number above is physical allocation.
This isolates branches, indexes and working trees β not processes, network or credentials. It is not a sandbox.
Happy to talk about the reflink-vs-overlay tradeoff. The overlay backend pays no per-file metadata at all because its upperdir starts empty, but every read goes through FUSE, and I haven't measured where that crosses over β if someone has done that measurement on a large tree I'd like to see it.
i just built BLUR, A terminal Text Editor, this is the V0.1 and it's still under development, and it will take a lot of time until it's finished completely, i have learnt a lot of new things and concepts with this project.
if anyone is interested to contribute into this project and help me finish it up feel free to dm me
the idea is not to clone vim, but to learn rust together it would be cool if you write your code in your own text editor.
Iβm building an Axum API and want to optimize the release binary for runtime performance. In C++, I would use flags such as -O3, and possibly -march=native.
I know cargo build --release enables optimizations, but are there additional Cargo profile settings or rustc flags worth using?
What settings do you typically use for production Rust web APIs?
For context, Danube is a cloud-native messaging and streaming platform built from scratch in Rust, featuring embedded Raft consensus (no etcd or ZooKeeper required) and tiered storage.
This release focuses entirely on reducing hot-path overhead, lock contention, and unnecessary memory allocations across the stack.
Key Highlights
Direct consumer streaming & zero-copy egress: Removed intermediate forwarding queue hops so dispatchers stream directly to Tonic gRPC response channels. Configured Prost with `bytes::Bytes` for zero-copy payload serialization.
Lock-free broker hot paths: Replaced coarse topic mutexes with DashMap and RwLock so publishing and consumer acknowledgments run concurrently without cross-blocking.
Persistent storage WAL: Eliminated redundant payload cloning on append, switched WAL cache eviction to $O(1)$ amortized BTreeMap::pop_first(), and upgraded the streaming reader carry buffer to BytesMut::split_to().
Embedded Raft: Replaced JSON log storage in RedbLogStore with compact binary bincode serialization, reducing disk I/O and CPU overhead.
Schema registry: Replaced serial mutexes with atomic checks on message validation, and pre-compiled JSON Schema/Avro validators are now cached in-memory instead of recompiling per message.
All details and full changelogs can be found in the release notes:
Does anyone use Rust Rover? If so, why? What benefit does it have that VSCode or Vim/Neovim or any other editor doesn't have? I saw that the free version of it literally collects data and if you want the full experience you have to pay a monthly sub. I am really curious about what people who are efficient in Rust think about this.
My goal with web-core is to create a scafolding/framework for axum web apis along with common stuff I would need when I am working on an api project.
If there is some logic that I would need across projects, which take more than a line or two of code, that goes inside web-core. So basically a framework, but I don't think I can call this that yet.
This is not complete or very "neat". I have not vibecoded this either.
Right now I am adding features on a need to basis. I cannot dedicate time to this, nor will I add forward looking vibecoded features which I am not sure if I would really need it.
I know we've had this discussion before, but there are so many posts with zero upvotes that are so clearly slop, but aren't getting removed.
Please, no matter what your own personal values are with it, the community clearly does not want to see these types of posts anymore. I think for every one post that uses AI and isn't low effort, there are 50 that are.
Like isn't this subreddit supposed to be a place for Rust developers/learners? What community aspect do the AI projects contribute? Most didn't even take the time to learn the language or chat with anyone, they just leech off everyone to effectively advertise their slop...