for now, my benchmark is a simple wrk test with varying connection counts (100, 256, 1000). Web server components like the parser, i/o, and the server itself have their own independent benchmarks (rust built-in), along with some e2e tests (mostly written in Bash).
We might be interested in the technology (not as a VC), if it shows meaningful improvement (>2x) over what we currently do.
If you could show how it compares with a simple replicable baseline, maybe something like C program that just accepts a connection? Lots of these things are hardware-dependent.
Right now we use monoio and have a draft benchmark with speed. Happy to continue talking over e-mail. Should I write to you?
Hi, nice motivation! I’ve built async runtime driven by clocks on top of monoio. You can drive each thread at different speed, to simulate a distributed system faster than real time. Our motivation is outlined here: https://minfx.ai/reliability.html
It’s not published yet, as it’s a bit wired to our internal systems at the moment. But happy to chat :)
Very cool! I’m exploring adding DICOM support to https://minfx.ai project. The idea is to better support machine learning in medical space and make DICOM viewing in web assembly. Not right now, but in next 2/3 months. What you’ve built looks very impressive! Are you planning to release Linux binaries?
Happy to collaborate!
Thanks! What are you building on the side? Would love to know what's janky about the existing tools, that's exactly the kind of feedback that shapes what I work on next.
I made bunch of linters/formatters for Rust specifically that try to make everything "look the same" in the monorepo. Especially as it is being generated by AI. It makes it easier to review the code.
The kind of things I added:
- Never use super:: or other relative references - always absolute. Within crate, always use the "private" paths, not the public API ones!
- Make sure there are no "cycles" in the code. I.e. if you follow-click on definitions, you get somewhere deeper/sibling node, you never go around in a cycle (the only cycles that are allowed are in the same module).
- Made a custom formatting tool, that always orders code in the same way: imports, constants, structs/enums, impl blocks, functions, macros, tests.
Things that would be nice:
- All errors should propagate to the crate top-level errors.rs via thiserror
- pub methods may not be marked as dead code, but they are dead within the monorepo (this annoys me now quite a lot now)
Probably more, just quickly from the top of my head.
This is super interesting. The “make everything look the same” angle is exactly what AI generated monorepos need if you want reviews to stay sane.
The absolute paths rule and the “no cycles unless same module” rule are both clean. I like that you’re optimizing for navigation too, not just style.
The two “would be nice” points hit hard:
A single crate level errors.rs with thiserror makes big repos feel way less messy.
The “pub but dead inside the monorepo” problem is real. Rust won’t flag it because it is public, but internally it is noise and people still spend time maintaining it.
How did you build these tools? Are you using rust-analyzer APIs, HIR, syn, or something else?
Also, if you have two minutes, can you try the dashboard and tell me what feels good or annoying about the workflow? for now login with github if possible. check it out.
It’s backed by Rust Monorepo Analyzer. Right now we focus on security and code intelligence, but your hygiene rules feel like a perfect “next layer” once the core analysis is solid.
What we do at https://minfx.ai (a Neptune/Wandb replacement) is we use TONS of custom lints. Anytime we see some undesireable repeatable agent behavior, we add it as a prompt modification and a lint. This is relatively easy to do in Rust. The kinds of things I did are:
- Specify maximum number of lines / tabs, otherwise code must be refactored.
- Do not use unsafe or RefCells.
- Do custom formatting, where all code looks the same: order by mods, uses, constants, structs/enums, impls, etc. In particular, I added topological ordering (DAG-ordering) of structs, so when I review code, I build up understanding of what the LLM actually did, which is faster than to read the intermediate outputs.
- Make sure there are no "depedency cycles": internal code does not use public re-exports, so whenever you click on definitions, you only go DEEPER in the code base or same file, you can't loop back.
- And more :-)
Generally I find that focusing on the code structure is super helpful for dev and for the LLM as well, it can find the relevant code to modify much faster.
Each struct and its referenced fields can be thought of as a graph which can be sorted.
Ideally, it is a DAG, but sometimes you can have recursive structures so it can be a cyclic graph.
By DAG-ordering a I meant a topological sorting such that you do it by layers of the graph.
Identifiers correspond to nodes and a mention of an identifier in the definition of another corresponds to a directed edge. The resulting graph won't necessarily be acyclic, but you can still use it to inform the order in which you present definitions, e.g. newspaper style starts with the most high-level function and puts the low-level details at the end: https://pypi.org/project/flake8-newspaper-style/
I feel like I'm somewhere on that Venn diagram O:-)
The specific examples in the article are about UI.
I agree that UI ecosystem is a big and slow mess, because there is actually a LOT of complexity in UIs.
I would even argue that there is often more complexity to be found in UIs than in backends (unless you are working on distributed systems, or writing your own database).
On backend, you usually just need paralellism (95% of jobs is just parallel for, map-reduce kind of thing).
But in UI, you need concurrency! You have tons of mutable STATE flying around that you need to synchronize - within UI, across threads or with the backend.
This is /hard/ - and to come back to the point of the article - the only low-level language that I'm familiar with that can do it well and reliably is Rust.
In Rust, my absolutely favorite UI framework is egui. It is based on immediate mode rendering (maybe you're familiar with dearimgui), rather than the old, familiar-but-complex retained mode. It's really interesting stuff, recommend studying on it!
Dearimgui has a wonderful quote that summarizes this well:
> "Give someone state and they'll have a bug one day, but teach them how to represent state in two separate locations that have to be kept in sync and they'll have bugs for a lifetime." -ryg
We use egui in https://minfx.ai (Neptune/Wandb alternative) and working with it is just a joy. Emilk did such a fantastic job bringing egui about! Of course it has its flaws (most painful is layouting), but other than that it's great!
reply