New week, new Rust! What are you folks up to?
(PS.: Sorry for the delay, I had a flight from San Francisco to Frankfurt for most of the day).
I've been doing more work on my vaguely DCE-inspired middleware.
I have posts (unidirectional messages), and requests (request/reply), put stream (upload a stream a data to server), get stream (get a stream of data from server) and io stream (combined get and put stream) working.
I have both plain TCP and TLS (using rustls) connections working. I usually make the TLS library an implementation detail, but this time I tried something new: I'm intentionally leaking the TLS implementation to the application. Not sure how I feel about it yet, but I'll give it a chance.
Currently working on graceful shutdown of connections.
I've been doing some benchmarking, and the core communication library is pretty fast for large frames, but many tiny ones are abysmally slow. I think I know why, but I need to verify my hypothesis. If the reason is what I think it is, then I have a solution for it.
Actually got far enough to be able to start writing applications for it, which is quite neat. I don't have authentication and authorization implemented yet. My goal is to allow application-defined schemes, and I've sketched on a solution that I think will be able to cover most schemes out there.
Also realized how I could massively optimize a deduplication storage library I've been working on. It's not often I can make an algorithm simpler, use far less ram, avoid using the filesystem for temporary storage, and also be much faster -- all at the same time. Although I haven't actually implemented it yet, I'm certain it will work.
Last week was good, and it's looking pretty good for this one as well.
Still working on uutils AWK, a modern gawk reimplementation as a performant bytecode, register VM. It is human code and blazing fast. We'd like some new hands! Let me know if you'd like to contribute 
This week we tackled the rest of array operations, and I'd like to finish our regex layer over BurntSushi's excellent regex-* crates. Getting our sans-io layer fully sketched out and prototyped is next, as well as cheap, concurrent reentrancy on the VM via bespoke hacks of the AWK language.
Let me know if you want me to rant about any details!
Been working on agentflow — an AgentOps stack for Rust agents built on top of graph-flow. It's nine independent crates bundled under one, each covering a different piece of running agent graphs in production:
- orchestrate — token-level streaming, dynamic map/ensemble tasks for graph-flow
- guard — validators + retry-until-valid on LLM output
- act-guard — policy-as-code for what an agent is about to do
- validate — schema validation for Polars DataFrames
- evaluate — graded-score eval suites
- checkpoint — snapshot/rollback a task's Context
- trace — latency/tokens/cost per task, no OTel needed
- cache — exact + semantic response caching
- remember — long-term memory (retrieve/inject/extract/resolve)
Each works standalone via cargo add, and a few of them (checkpoint/trace/cache/memory) are plain graph_flow::Task wrappers so they just stack by nesting.
Would love feedback from anyone building agents in Rust.
I added a small optimisation to pstd ( Crate with parts of Rust std library ( different implementations, features not yet stabilised etc )) to eliminate panic-handling code when panic is set to abort.
e.g. here
Today, I continued my Rust learning journey by working on an Inventory Management System. The goal is to build something practical while strengthening my understanding of core Rust concepts such as structs, enums, Vec, HashMap, file handling, and Serde JSON.
One challenge I encountered was managing data ownership while reading, updating, and persisting inventory records. Coming from Python and Django, where memory management is largely abstracted away, Rust's ownership and borrowing rules require a different way of thinking. While it can be challenging at times, I'm starting to appreciate how these rules help prevent entire classes of bugs before the code even runs.
A key lesson from today's work is that Rust encourages you to think carefully about data flow and state management. The compiler may be strict, but it's becoming clear that this strictness leads to safer and more predictable software.
My next goal is to improve the project by implementing better error handling, refining the data persistence layer, and exploring more efficient ways to manage inventory operations.
For those who have built CLI applications or business systems in Rust, what concepts or patterns made the biggest difference in your learning journey? Any advice for someone transitioning from web development into systems programming?
Some quick concepts you might want to take a look that will have a big impact in the way you reason about modelling:
- Newtype pattern
- Typestate pattern
- Algebraic Data Types (ADTs)
- Pattern matching
Thanks for the suggestions! I really appreciate it.
The Newtype pattern, Typestate pattern, ADTs, and Pattern Matching are concepts I keep seeing experienced Rust developers mention, so I'll definitely add them to my learning roadmap.
Do you have any resources you'd recommend for learning these properly? Blog posts, videos, or GitHub projects that helped you understand them would be greatly appreciated.
Also, as I'm transitioning from Django/Python into Rust, I'm trying to develop good Rust habits early. If you don't mind, would you be open to occasionally reviewing or vetting some of my code and giving feedback on my approach? I'd really value insights from someone with more Rust experience.
Thanks again for taking the time to point me in the right direction!
It's hard for me to say if I have any learning resources for these concepts. I only picked them based on what I thought you might be interested in learning given where in your learning journey I inferred you are at.
You could take a look at the resources I have saved about Rust in general, to see if there's anything that might help you: Firebits - Your online hub for building and sharing knowledge
Thanks so much, the link is a very good resource.
About what I said in the last paragraph of my reply. Is it possible for you to hold my hand in this my learning journey so that I can share my code with you for review
I personally don't think I have the time right now to dedicate to this, but you can ask for code reviews here in the community. You'll have bigger chances to get a code review this way.
Ok Thanks
Spent the day working on this, and it turned out better than I had imagined.
For whatever reason, I have - over the years - managed to convince myself that multi-pass systems are slower (in general), but are more readable/maintainable -- and I really need this code to be maintainable.
The new design is single-pass, and it's better in every way (including being far easier to read/follow). To be honest, I still think there may still be some truth to the single-pass vs multi-pass generalization, but I just proved to myself that it is not always the case.
It's much faster, the library is far less cumbersome to use -- but the biggest win is that it uses just a fraction of the amount of memory it used to, and the developer doesn't need to set up a temporary directory to store intermediate files in. Now everything can be done in process memory.
When the implementation was complete, I ran clippy on the project and started fixing its suggestions; it taught me about as_chunks() (as an alternative to chunks_exact(), when the size is fixed).
Key insights:
- Don't always assume that multi-pass solutions are more readable/maintainable.
- clippy is as much a teacher as it is a linter (well; I already knew this, but it was a nice reminder that clippy is kept up to date with what has been stabilized recently in Rust).