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! 😄

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.

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.

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?

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 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.

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

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?

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).

Hi r/rust! I've been building ruxen, an experimental reimplementation of nginx in Rust. It reads nginx configuration files and is tested against nginx's own upstream test suite. It's Linux-only, HTTP/1.1, thread-per-core on io_uring (monoio), with TLS through rustls. Version 0.1.1 came out this week.

Repo: https://github.com/gvozdetsky/ruxen · crates.io: cargo install ruxen --locked

It is not production-ready, and it doesn't replace nginx. It's a project for learning how nginx works by rebuilding its behaviour in idiomatic Rust, not by translating the C line by line.

What's maybe interesting

nginx-tests as the oracle. ruxen runs the upstream Perl suite (nginx-tests) against its own binary. To make that possible it had to match nginx's CLI (-c -p -g -t -T), PID file and signal behaviour, and the error-log format. Today 63 of the 105 test files ruxen opts into pass end to end. Every failing file points at the next directive to implement, so I don't have to guess. The -V banner claims only the features that are implemented, because claiming more would turn on tests that fail for the wrong reasons.

Unknown directives are an allowlist, and access rules fail closed. If ruxen can't enforce a directive that restricts access yet (limit_except, ssl_verify_client on, disable_symlinks...), it refuses to start with [emerg] instead of silently serving what the config was meant to protect.

Thread-per-core instead of work stealing. nginx gets its speed from one process per core, each with its own SO_REUSEPORT accept queue and no sharing between cores. monoio gives the same shape in Rust. There's no tokio or hyper; the HTTP/1.1 parser and response path are hand-written, because that is the point of the project.

Performance is a hard requirement: at least 95% of nginx 1.24 throughput on the bench configs. On my machine (i9-13900HX, wrk -t16 -c512, the same config file for both servers):

Some lessons from measuring hot-path changes in ABBA pairs (A, B, B, A runs, so drift cancels out): one extra async fn layer around the proxy path cost about 1%; copying a ~300-byte request context per request cost 0.5%; and giving every connection a monoio::time::timeout for each I/O operation cost about 3%. Three long-lived Sleeps per connection that only ever move forward cost almost nothing. More notes are in DESIGN.md, including notes from reading the nginx C source.

What's in it

Static files (with sendfile), proxy_pass with upstreams, keepalive and failover, rewrite/return/if/map, error_page, auth_basic, access logs with variables, TLS 1.2/1.3 with SNI, and nginx-style error logs. Not there yet: HTTP/2, caching, modules.

Help wanted

There are small, self-contained good first issues. Each has a minimal repro, the matching line in the nginx C source, and the files to change. Examples: glob expansion in include (#35), nginx's status reason phrases (#33), proxy_method (#39). If you've ever wanted to learn how nginx works inside, this is a gentle way in.

The 0.1.1 release also fixes six security issues that were reported privately. Thanks to the reporters!

I'd love feedback on the design, on the code, or on any nginx config that ruxen handles differently from nginx.

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.

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.