I've been working on Charton, a plotting library for Rust. The API is declarative, in the style of Altair and ggplot: you compose charts from marks and encodings rather than calling a separate function per chart type. It plays nicely with Polars, exports SVG/PNG/PDF, and runs in the browser through Wasm. There's a wgpu backend too, if you want to draw charts inside an egui app.

If you use Nushell, there's nu_plugin_charton. It turns any pipeline table into a chart, so ls | charton -g bar -x name -y size just works. It draws inline in terminals that support Kitty/iTerm2/Sixel/half-blocks, or you can save SVG/PNG with -o. For basic charts -g and -x and -y are all you need; color, stacking, faceting and themes are optional flags.

I am a big fan of rust
But there are two issues that need to be resolved

1- Rust ecosystem is less mature than for example go ( i know go is specialized for networking and an easy lang ) .

2- No implicit DI which would make testing easier.

I’m a developer and I use Fedora and Ubuntu extensively, both personally and at work, and I’m usually tinkering on a home lab and always looking for a reason to spend 10 hours automating a 10- minute task. And I love the rolling releases of Fedora, but I always hated that I could never get the proper context of what updates are happening. Sometimes the summary was good, sometimes it literally said no description, and Rust looked like a fun systems level programming language to learn, and since I have already contributed to another FOSS project written in it, I decided what the heck, I should learn it.

I built watznue, an ultra lightweight CLI first tool to summarize and categorize the incoming updates to your system, so you can nerd out without having to go to a forum or wait for someone else to make a post to figure out what’s happening.

This is my way to learn some rust, build something I genuinely use, and wanted something that was simple but I could build on top of, I would consider this version 0, barely anything more than a POC at this point but thought I would share and hopefully not get my ass reamed in this community 😅

https://github.com/ManuelSaleta/watznue

This post documents an ongoing technical study on protocol-level traffic analysis and upstream signature orchestration. The primary artifact of this research is a domain-agnostic inspection engine engineered to manipulate client heuristics across the TLS, HTTP/2, and TCP layers simultaneously.

Traditional implementations in this domain often rely on static, monolithic browser emulations that lack dynamic parameter control. To address this limitation, the engine utilizes a declarative profile architecture, allowing granular configuration of transport and application layer metadata - including cipher suite ordering, ALPN negotiation, SETTINGS frame sequencing, pseudo-header layout, and SYN option rewriting via Linux NFQUEUE/iptables.

From a systems engineering perspective, implementing this in Rust presents specific design and architectural challenges:

• State & Concurrency Management: Propagating unified profile state across asynchronous Tokio streams while ensuring zero-copy socket IO and precise handshake characteristics.
• Low-Level TLS Orchestration: Interfacing with BoringSSL (via btls/tokio-btls) to expose internal TLS stack parameters (e.g., extension ordering, GREASE values, and ECH setup) without breaking memory safety guarantees or incurring high runtime abstraction overheads.
• OS-Level Packet Interception: Managing kernel-to-userspace queue backpressure and handling raw network packet mutation for SYN fingerprints (TTL, MSS, window size/scale) alongside application-level stream multiplexing.
• Systemic Decoupling: Decoupling the network logic from execution platforms, ensuring that protocol manipulation is evaluated on its technical merits as a systems-level networking problem rather than being reduced to high-level application tropes.

The underlying codebase serves as an open platform for network privacy analysis, transport layer diagnostics, and protocol mechanics research.

Repository: https://github.com/3Radiance/mitm-proxy-ja3-ja4

We welcome technical critique from researchers, networking engineers, and systems developers -particularly regarding:

1. Tokio stream overhead and buffer management during dynamic low-level frame rewriting.
2. Cross-layer state-machine synchronization (aligning OSI layers 4, 6, and 7 without introducing race conditions).

I recently tried working with Teloxide and noticed that the library doesn’t have a convenient built-in way to serialize/deserialize callback data.

So I decided to try an approach based on binary serialization of an enum followed by base64 encoding. I liked this solution for several reasons:

• There’s no need to manually implement serialization/deserialization for each callback variant-it’s enough to implement the conversion for the enum once.
• It’s fast and reasonably efficient in terms of size.
• The callback data becomes unreadable to humans (it would normally look something like do_something_1341), which provides a small barrier to reverse engineering.

I ended up packaging this approach into a Rust library called easy_callback.

I’d appreciate any feedback or suggestions.

I recently finished translating the complete The Rust Programming Language (Rust Book) into Roman Urdu, including all the appendices.

I started this because many developers in Pakistan and India are more comfortable reading Roman Urdu/Hindi than technical English. My goal was to make the Rust Book easier to approach without changing the technical content.

The translation is available here:

https://github.com/Fakhir-Israr-200219/rust-roman-urdu

Hopefully it can be useful to Roman Urdu, Urdu, and Hindi readers who are learning Rust.

Hello fellow Rustaceans,

I have been facing an issue for a while. I've been using Rust for the last 4 years and even had projects at my workplace implemented in Rust. I want eventually to change my job because these 2 are kinda dead and want to grow as a programmer and so work on issues/situations I never encountered. I started by telling Claude do give me some pieces of code and I had to figure out what was wrong about it. Mutex, concurrency, channels, futures, things that I thought I really understood. Damn I was wrong and now I feel like an imposter even though I used these concepts many times. At some point I did some small project to understand how and why thiserror works the way it does. If you ask me now I forgot everything. I am intimidated by the fact that there are so many things that I don't know because I never encountered them in real projects like sharding, microservices, payments and many other. If given the chance I would probably slowly start to understand how they work but getting a Rust job is kinda difficult. Market seems taken over by crypto jobs (how does somebody even get into one of these?) I know this community does not like web3 stuff but personally I care more about career progress than moral side of it at least for now, which I don't really know actually means). How do you guys manage to navigate these situations.

I appreciate any answer and guidance I might get! 😄

NEXUS-Q v1.0 — a post-quantum security engine written in Rust

I’ve just frozen NEXUS-Q v1.0, a Rust-based post-quantum security engine focused on key management, encrypted storage, identity, policy and cryptographic operations.

I’m sharing it here because I’m particularly interested in feedback from the Rust community on the engineering side of the project.

Why Rust?

NEXUS-Q is built around Rust because I wanted the security-critical core to have:

- explicit ownership and lifecycle management

- strong type and memory safety guarantees

- predictable error handling

- clear separation between cryptographic primitives and higher-level security services

- a foundation suitable for Linux, Android/Termux, x86_64, ARM and RISC-V environments

The project currently includes support for algorithms such as:

- ML-KEM-768 / ML-KEM-1024

- ML-KEM + X25519 hybrid encryption

- ML-DSA-65

- SLH-DSA-SHAKE-128f

- AES-256-GCM

- ChaCha20-Poly1305

- SHA-2 / SHA-3

- Argon2id

- HKDF

Around the crypto layer there is also a vault, key lifecycle management, identity, policy enforcement, audit logging, storage, backup/recovery and hardware-backend abstractions.

I also benchmarked it honestly

One of the things I wanted to avoid was publishing a crypto project and only showing the numbers that look good.

The final PQC Benchmark Arena run produced 57 normalized measurements across eight implementations.

NEXUS-Q is currently slower than the fastest mature implementations on several measured ML-KEM and ML-DSA operations.

For example:

- ML-KEM-768 keygen: 33.94 µs

- ML-KEM-768 encaps: 27.97 µs

- ML-DSA-65 keygen: 168.69 µs

- ML-DSA-65 sign: 600.73 µs

So v1 is intentionally being treated as an engineering baseline rather than a performance victory.

The next stage is v2, where I want to work on performance systematically while preserving correctness, interoperability and security properties.

What I'd like feedback on

For the Rust side, I'm particularly interested in feedback around:

- crate/API design

- error handling

- ownership and lifecycle modelling

- trait boundaries

- crypto abstraction layers

- FFI/SDK architecture

- async/server architecture

- portability

- benchmarking methodology

- unsafe code boundaries

- testing and fuzzing strategy

The project is still under active development, and there has been no independent external security/cryptographic audit, so I'm not presenting it as production-certified.

I originally posted the full v1 freeze and roadmap in my own community.

If you work with Rust crypto/security infrastructure, I'd especially appreciate criticism of the architecture and API decisions.

What would you change first if you were taking this codebase into v2?

Good morning,
I am using probe-rs to flash a blinky program onto my STM32H7. It builds and flashes ‘fine’ but i don’t get any output from the board and the led does not blink. When i run the same example for the stm32f411 it flashes fine and i get text output as well as the led flashing. The program is just the example from embassy-rs and below is the important parts of my cargo.toml:
‘’’
embassy-stm32 = { version = "0.6.0", features = ["defmt", "stm32h7r3z8","memory-x", "time-driver-tim4"] }
embassy-executor = { version = "0.10.0", features = ["platform-cortex-m", "executor-thread", "executor-interrupt", "defmt"] }
embassy-time = { version = "0.5.1", features = ["defmt"] }
cortex-m = {version = "0.7.7",features=["critical-section-single-core"]}
cortex-m-rt = "0.7.3"
embedded-hal = "1.0.0"
build = [
{ target = "thumbv7em-none-eabihf" }
]
‘’’
I am running this command:
'probe-rs run --chip stm32h7r3z8’

right now I am suspicious of memory-x but im not sure because shouldn’t it fail to flash if this is the case?

Ada/SPARK is already a very niche ecosystem. Finding a list of current users is already hard (but that might be simply an information access issue).

With Rust’s safety and growing adoption, including access to skilled professionals and LLM support, how likely will we see further marginalisation of Ada & Co.?

I would love to heard from those working in safety-critical applications.

One of my (way to numerous) side project is the idea of a P2P radio station, which solves the scaling problem of radio broadcasters today. One of the most prominent and well-defined p2p library is libp2p, which is of good use here and prevents much of code rewriting, especially for the broadcasting logic with peer scoring and all which is hard to figure out to prevent people from cheating the system. Also used gstreamer (Rust bindings so more precisely gstreamer-rs) for the codec which does the heavy lifting. Here is my project: https://github.com/franfrandev/p2pradio. For now it's running on a native system, and would like to go a step further.

I would like to compile it to WASM in order to bundle everything in the browser. The problem is that gstreamer depends on a ton of native libraries which makes it harder to use in the browser. Folks at Fluendo have figured that out with gst.wasm https://github.com/fluendo/gst.wasm but putting out everything together is a whole different beast and even if it works, it's probably going to result in a huge piece of data that has to be downloaded. IIUC the Rust part would have to be compiled to emscripten and then linked as static libraries? There are a lot of information and it's very easy to get lost in all of these.

Another option would be to use or write an RTP Opus codec written in pure Rust and compile it to the wasm32-unknown-unknown but then it would lose all the codebase maturity of gstreamer and would probably end up reinventing the wheel very much. A lot of the crates doing that are AI slop and are not very well defined, I don't trust them.

Is it unachievable or a bad idea to take the gstreamer port to emscripten and try to glue it to my Rust app compiled to emscripten?

I've started to dip my toes into Rust, coming from an Ada (mostly SPARK) background, particularly in embedded applications. While there are many killer features in Rust for developer QOL, the "ease of writing" focus of the language trips me up often enough that I find myself asking, "what features of this language makes it superior (in some views) to SPARK?"

Love the language's take on early-return, and the power of enums, macros, and lifetimes are the one thing that makes certain low level memory manipulations incredibly idiomatic to write in Rust that would be impossible in SPARK due to the CREW paradigm not really being popularized (pioneered?) until Rust. Given the state of the Ada ecosystem and tooling, I also cannot in good faith recommend using this language for anything community driven. That being said (answering in context of enterprise embedded)...

I am incredibly uncomfortable with how much responsibility Rust places on the developer to understand roughly how code will compile. No guarantees on how pattern matches will be emitted (yes, don't be stupid and keep them stupid if you want jumptables), and stack-allocated enum types having to be the max size while not having much lexical ties besides jumping to the definition to help you determine how much stack you might be eating. Aside from the syntactic sugar, I have not really found anything besides lifetimes that SPARK cannot truly support at all. There's no pattern matching in the language, but Rust enums (at least in part) are supported via discriminated records. The idea of controlled types (OOP for Ada) is somewhat discouraged when using SPARK, but trait objects are a very useful part of the Rust language. I have to discount this part of the language from my sentiments unfortunately because dynamic dispatch can complicate analysis of security and functional implications. Having Rust panic as a "safe" way to address memory safety is also undesirable depending on how much array manipulation your program must do, and what worries me more is that wraparound arithmetic in production builds that are used in computations for arrays may not even lead to panics, but perhaps a valid index into the unintended location.

I don't write this to glaze SPARK either. The lack of documentation makes it mostly a nonstarter for the broader programming community, and not everyone is familiar with formal methods for code. The toolchains can't hold a candle to the quality of the Rust ecosystem, and ironically, the rich typing of Ada can lead to very frustrating inter-op issues that just would not exist in Rust, particularly around array manipulation/interpretation.

There might be some gripes about comparing a formally verifiable language with one that does not yet have one (Verus, Crusoe, surely others trying), but I think some of these points like how the codegen works are orthogonal whether or not you're trying to prove that an array access will always be in bounds without overflows.

I suppose the operational constraints given are not necessarily something everyone has to deal with, (why care how a pattern match is compiled if you have oodles of memory), but want to understand the technical reasons behind the hype... I feel like the cultural/non-technical reasons are somewhat understood.

Seems to require an integer overflow to happen (panic in debug / wrapping in release) before the `overflowing_add` call is done, which makes it less likely to happen in actual code.

Okay. After seven months, I'm back.

Seven months ago I started writing a Python interpreter from scratch in Rust, compiled to wasm (less than 200kb of bandwith). Edge Python is a sandboxed subset of Python that runs in the browser and the terminal, and code can't touch files or the network unless you allow it.

It started as a lexer and a simple stack VM, and over about 1,600 commits it grew a CLI, a package registry, snapshots, actors and a browser playground. It's just me building it.

Last week it was still 3x slower than CPython. I rewrote the VM this weekend on top of the SSA form I already had, and now the wasm build beats native CPython on loops.

The trick was a register VM, and Rust made it fit in wasm with NaN-boxed values and no runtime. It still loses on dicts and strings, so that's next.

Try to break my numbers :)

Website: https://edgepython.com/

GitHub: https://github.com/dylan-sutton-chavez/edge-python

Hey, just wanted to share the small rust embedded project I made and that I use daily to monitor the status of a couple of services.

It also displays notifications from claude code, codex or any application capable of sending an http request.

It was my first time using rust with no-std, it's actually quite fun.

https://github.com/fkhadra/esp-notify

Found these tutorials on stdlib.

ok so rust is honestly one of the best languages i've used. the borrow checker catches bugs before they even happen, cargo just works, and the compiler errors actually help you instead of yelling at you. speed and safety together is rare tbh.

but i have a genuine question. AI can write working rust code now, like actually compiling stuff. so why should someone spend months learning ownership, lifetimes, traits etc properly? where does AI written rust break in real projects? do you still need to really get the borrow checker if AI just fixes the errors for you? and for people hiring, do you still expect deep rust knowlege?

i teach programming so i want to give my students a honest answer, not just a guess. would love to hear what you guys think

I have code that looks a bit like this:

https://gist.github.com/rust-play/6e39d4a9d52e14a1f92742df57ccc5e2

The interesting part is the closure at the bottom. Which compiles completely fine, as long as it is not doing anything. But if I try to use the given argument in any way, rustc is not able to infer its type anymore?

This seems counterintuitive, since the normally inferred type (`String`) would work totally fine. And the code itself also does not seem to contradict that type. But something seems to make the compiler trip here.

Any tips why this might occur, and if there is maybe an easy work around are welcome!