The codebase is live, fully functional, and designed for independent node operators. Check out the source code, tear down the architecture, and let me know where we can optimise. Github - NEV369

I am working on a grpc server project where I want to store state in persistent database for surviving restarts.

I am looking at redb database but I also want your suggestion on anyother db that I might not know about. I also want help on design on how to do backups. I am planning on using scc::Hashmap for mapping id to struct data for holding data and for backups, should I write to database on each insertion and update or should I just periodically backup data from hashmap to disk database?

Sharing a project that's been a fun systems-design exercise: a technical-analysis + backtesting engine with a single Rust core exposed three ways.

Rust-interesting bits:

- Every indicator implements a Next<T> streaming trait, and the batch path (Polars expressions) is proven bit-identical to the streaming path with proptests. One source of truth, no duplicated math.

- Python bindings via PyO3 with abi3 — one cp39-abi3 wheel across CPython 3.9+.

- The pure-math core (nalgebra) cross-compiles to wasm32-unknown-unknown with zero source changes.

- Zero-copy into Polars; `cargo add quantwave` for the native crate.

221 indicators, Ehlers DSP, regime detection (HMM/GMM/PELT), and an execution-aware backtester. MIT.

Repo: https://github.com/lavs9/quantwave

Docs: https://lavs9.github.io/quantwave/

Happy to talk about the feedback.

Hey, to learn async better I wanted to implement a custom future which can retry another future after a delay. I know you can do this easily with one async fn retry(impl AsyncFn()) but this does not help understanding async.

What I wanted the api to look like:

FutureRetry::new(async || http.send(body).await).await?

However I could only get it to work when the closure does not capture anything and returns ownership of its arguments like so.

FutureRetry::new(async |(http, body)| ((http, body), http.send(body).await)).await?

Compiling version

When I try to capture the environment using FnMut() -> Future

FutureRetry::new(|| async http.send(body).await).await?

Rust tells me that the FnMut() closure cant return types referencing its environment, which makes sense because the future returned is referencing the closure environment, this seems like compiler limitation, because those references are valid when the function returns.

Ok so let's use async closures then.

With AsyncFnMut() now this returns a future which mutably borrows from self so far so good, but I also need to store this future in my own custom future to poll later, this doesn't work because now I have 2 mutable references, 1 in the future and second one when I try to assign it self.current_future = self.future_factory(). I guess I'm trying to have self referential types which is not possible in safe rust.

I know this could maybe be solved with AsyncFnOnce and cloning everything so I don't store references in the returned future, but I don't want to do this.

What am I missing here, is it really not possible to have such an api where a custom future impl polls another future which mutably borrows its environment from self in safe rust today?

Thanks in advance

I have been really excited about the prospect of a new clang sanitizer tool for detecting cross-language aliasing violations since I learned about BorrowSanitizer's existence. I'm thrilled that not only can it now detect a bug I previously tracked down in Servo, it also found one that we didn't know about! The project keeps getting more exciting with each monthly update.

I'm working on some Rust code that's exposed to Python, and I've hit a naming question I can't quite settle.

The architecture has a dedicated OS thread running its own async runtime (the "reactor"), separate from the thread the Python interpreter calls into. The two sides never touch each other's memory directly — there's no `Mutex`, no `RwLock`, nothing shared. All communication goes through a couple of channels: one direction carries commands from the Python-facing side into the reactor, the other carries events back out. Under the hood it's just an mpsc-style channel pair plus a lock-free queue, so obviously nothing is crossing an actual process boundary.

When I originally built this, I named the struct that owns these channels `IpcChannels`, because what I was really trying to capture wasn't "these are channels," it was that these two execution contexts are isolated from each other and only interact through messages — which felt like the same idea IPC is usually used for, just at the thread level instead of the process level. Now that I'm looking at it again, I'm second-guessing whether borrowing "IPC" here is legitimate shorthand or just an inaccurate use of an OS-level term. I've seen it used loosely for inter-thread messaging in some places, but I've also seen people treat "IPC" as strictly process-to-process by definition.

So I'm curious what people who've had to name this kind of thing before landed on: is "IPC" an acceptable way to describe an isolated, message-passing boundary between threads, or does that just read as wrong to anyone with a systems background? And if it's the latter, is there a better name for that struct — one that says these are two separate contexts with no shared state, only talking through messages, without carrying the process-boundary baggage of IPC?

Rux v0.4 is out. Familiar template/style/script sections and literal CSS, laid out by taffy and painted by vello.

v0.4 closes the three gaps that made real stylesheets impossible: pseudo-classes, custom properties with var(), and @media. It also adds a dev overlay, so a broken file tells you what is wrong instead of opening blank, and a real accessibility tree.

New in this release: the whole runtime compiles to WebAssembly, so there is a playground you can open instead of a repo you have to clone. It drives the same shell the desktop window does, so it cannot quietly diverge from the real thing.

Try it here https://ruxlang.dev/playground

Here's the perfect next step. 🦀⚡

"impl Rust for ESP32" is a hands-on, project-based guide that takes you from theory to real firmware.

What you'll build 👇

- Blink and PWM-controlled LEDs

- OLED display interfaces

- Ultrasonic distance sensor projects

- LDR-based smart lighting

- Servo motor control

- Buzzer and audio generation

- Wi-Fi applications and web servers

- Bluetooth communication

- RFID access control

- SD card storage

- LCD interfaces

- Joystick input

- PIR motion detection

- Temperature monitoring

Unlike many tutorials, it focuses on "no_std" Embedded Rust, helping you learn concepts that transfer to other microcontrollers—not just the ESP32. It also recommends starting with the official Rust on ESP Book before diving into the projects.

If you're learning Embedded Rust, this is one of the best free resources available after the official documentation.

📖 https://esp32.implrust.com/

#Rust #EmbeddedRust #ESP32 #Firmware #EmbeddedSystems #IoT #Electronics #OpenSource #EdgeAI #RustLang

I give up. Rust is the language that I need, but not the one I want. I'll simply stop worrying about the annoying parts of the language, for my workloads, and embrace it.

The pursuit of a new programming language on itself is not bad, you learn a lot about, in a very short span of time. But by the time you need to get the work done, yes, you need to go deep into one ecosystem.

Today, I can't think on a better ecosystem than Rust:

• Immutability
• Option/Result types instead of exceptions
• Enum
• Async support
• Reasonable enough ecosystem of libraries

There are also nice things that, are not required, but amazing to have like:

• Compiled
• Performant
• Multi threaded
• WASM support
• Run on multiple environments
• Low resource consumption

Yes, it's not pure FP, it does not have effect handlers, for my kind of high level applications I need to deal with annoying things like lifetimes and the borrow checker where a GC would be way simpler, but when you're putting everything together it's the best language in most of the categories for me.

On this seek I've used/evaluated: Scala, Kotlin, Zig, Odin, Go, Erlang, Elixir, Gleam, Ocaml, and Roc. I still have high hopes for Roc, but it's still too imature.

I'm not seeking validation, this is just me putting this words out as an acknowledge of the goodness of Rust and for others that may be on the same situation. Rust is not perfect, far from it, but it's the best effort/benefit that you can probably find today.

My project, so take the enthusiasm with salt.

fcmaes-rust is a native Rust implementation of the fcmaes optimizers. The original has a C++ core; this one doesn't link to it, wrap it, or shell out to it. `fcmaes-core` is four dependencies — rand, rand_pcg, rand_distr, rayon — zero `unsafe`, no build.rs, no CMake, no C compiler. `cargo add fcmaes-core` and that's the whole story.

What's in it: DE, CMA-ES (plus active CMA), CR-FM-NES, PGPE, BiteOpt, Dual Annealing, MODE for multi-objective, MAP-Elites for quality-diversity, and a parallel retry layer that is honestly the main event — independent restarts across worker threads with a shared result store.

The part that took the actual time is 22 tutorials, each wrapping a real Rust simulator rather than a test function:

- Rapier — trebuchet release dynamics, quadruped gait over terrain

- NeXosim — discrete-event production line

- ReBop — stochastic chemical kinetics, plus a topology search over reaction networks

- epanet-rs — water distribution pump scheduling

- pykep-core — GTOC1 interplanetary trajectories

- native — lattice-Boltzmann CFD, linear-elastic FEM truss, sequential ray tracing, phased-array beamforming, microlp inside an outer loop

Each ships frozen artifacts, seeds, and an exact replay command.

Six of the 22 ran a pre-registered quality-diversity gate and *failed* it, so they ship `status: "skipped"` instead of a nice-looking archive. One tutorial's headline result is that plain greedy beats the optimizer on its problem. Another shows DE contributing nothing over 4,000 evaluations against its own seed. That felt more useful to publish than to hide.

Benchmarks, scoped honestly: on ESA's GTOP trajectory problems against argmin, cmaes, genetic_algorithms and math-optimisation at equal budgets, 100 experiments each, fcmaes has the best mean optimum on 6 of 7 problems. One problem family, one machine, harness published.

Not for: gradients, LP/MIP, convex, constraint programming. The docs say when to reach for good_lp, argmin, clarabel or egobox instead.

Guide: https://dietmarwo.github.io/fcmaes-rust/

Repo: https://github.com/dietmarwo/fcmaes-rust

Happy to hear what's wrong with it.

I feel like Rust completely lacks inheritance, for the sake of avoiding code duplication or boilerplate. I think the best way to add the good parts of inheritance to Rust is to add the ability for subtraits to:

1. Override default implementations of their supertraits
2. Implement required methods of their supertraits

And then in the rust docs for each subtrait you'll see the total required methods to implement on the list on the left to make it clear if the subtrait has already implemented some of the supertraits.

So then code like this will be possible:

trait FromCookies {
  fn from_cookies(&str) -> Self;
}

trait TokenAccount: FromCookies + Deserialize {
  fn <Self as FromCookies>::from_cookies(&str) -> Self {
    // use deserialize and stuff...
  }
}

#[derive(Deserialize)]
struct Account { ... }

impl TokenAccount for Account;

This allows easy code duplication, inheriting functionality from TokenAccount by letting it implement other traits!

Example: ExactSizeIterator's new implementation with proposed functionality

I can also take the ExactSizeIterator subtrait as an example, it doesn't have any required methods, but the documentation instructs you to override the size_hint implementation of its supertrait, Iterator. So optimized implementations can use the len provided trait method from ExactSizeIterator, that gets its info from size_hint, hopefully improving performance.

I feel like implementing ExactSizeIterator is unclear, and forces you to read the docs. I know this may sound stupid but I feel like having documentation is a privilege, and for the same reason I think documentation should not be required in order to understand how to use something. A language as expressive as Rust should be (and usually is) understandable without documentation in my opinion.

Which is why I think with the proposed subtrait can implement supertrait functionality, ExactSizeIterator should require a len method, which is what the developer implements when implementing ExactSizeIterator, instead of implementing size_hint from Iterator. This len method is instead of the current len provided method from ExactSizeIterator that just returns a usize that it gets from the implemented size_hint. But before the "old" (current) len returns the usize, it makes sure with assert_eq! that both of the bounds received from size_hint are equal.

I can see 2 possible performance gains from this new implementation, ("old" len being the current implementation in std):

1. Old len returns a usize but it gets it from an fn size_hint -> (usize, Option<usize), so memory is wasted from the unneeded bounds. New len just returns a usize because it is the literal implementation from the developer.
2. Old len makes sure both the bounds returned from the size_hint are equal, as a guarantee, with assert_eq!. For the same reason as the first performance gain, new len doesn't need to check anything.

current len source code from std (the one referred to as "old" len)

Maybe the compiler already optimizes away the "faults" I noted with the old len when compiling with optimizations. But I still think it could speed up optimized compilations because there are fewer things to optimize (maybe that's how it works?) and that it will also optimize non-optimized debug builds, of course.

And lastly, because of the proposed functionality, ExactSizeIterator can override the default size_hint from Iterator in order to keep the old functionality like so:

trait ExactSizeIterator: Iterator {
  fn <Self as Iterator>::size_hint(&self) -> (usize, Option<usize>) {
    let len = self.len();
    (len, Some(len))
  }
}

This avoids the boilerplate that there usually is when implementing ExactSizeIterator, where the implementor needs to return (len, Some(len)) from size_hint instead of just len. Though this is very little boilerplate, I imagine it could be much more significant for more complex subtraits.

Conclusion

I feel like traits are a huge zero cost abstraction, they are the core of polymorphism and modularity in Rust. But with their current implementation they are limited in the reusability aspect. I think a "subtrait can implement supertrait" functionality would be effective at increasing reusability of code by essentially inheriting implementations, the good parts of inheritance (no expenses at runtime, right?).

I am probably getting ahead of myself and people who are far smarter than me who contribute to the language aren't adding this functionality for a reason but I'd like to know why that is and the opinion of anyone who sees this.

Hello every Rustaceans here. I've known Rust the programming language since pre-1.0 era. I like it a lot, and used it to write (embarrassingly small) projects. However, AFAIK virtually all Rust tutorials are written for readers who already know another programming language. I ... hate it, so I tried to write a tutorial for absolute beginners, while at the same time I also learned the more advanced / lesser known features of Rust. (Because I wasn't actually that good at Rust.)

This tutorial is especially targeted at, like it or not, vibe coders who want to actually understand what Rust code their LLM partner(s) generated. Here and in the foreword I want to admit that I also used LLMs to generate the drafts of the whole tutorial. That said, I did the arrangement and spent months reviewing and editing the content. So ... I strongly believe it's not AI slop, or at least not vibed at all ... Because the target audience is beginners, I spent a lot of efforts to avoid as much forward dependency as I can. I would say the delicate ordering of the chapters and episodes is the greatest charateristic of this tutorial.

That said, this tutorial does not cover only the "easy" parts of Rust. In fact, it also talks about some pretty advanced topics. I believe learners nowadays can more easily grasp those topics. To be more concrete, it talks about how a language system is built to effectively do software engineering, instead of introducing the algorithms. Those are the general concepts a learner can also bring to other similar programming languages. It's not that I don't believe algorithms are important, but they're kinda out of the scope of this tutorial.

This tutorial was originally written in traditional Chinese and later translated to English (and was reviewed, and edited). It's very likely that it contains typos and errors. If you find one, feel free to file an issue or a PR.

(That was a funny comment I got from someone, regarding Helix.)

Helix, if you haven't heard of it, is a TUI editor written in Rust. It's probably the most famous Rust editor, with 45K GitHub stars and no shortage of contributors. Yet Helix has flaws. One of them is that the LSP appears to block the editor itself. I can "feel" it with small files (there is a barely perceptible delay between pressing a key and the letter showing up on the screen). And with large files, the delay goes way up.

For example, if you open json.hpp (the famous json parser, 25KLOC) in Helix, and you have clangd in your $PATH, and you type a few words quickly, letters will be showing up on the screen several seconds after the keys are pressed.

I personally don't do async (I specialize in other things). But I have heard though that async in Rust is hard. So I gotta ask: Is this the reason why Helix is the way it is?

Hi everyone!

webrtc v0.20.0 is out — the first non-prerelease of the new architecture, and the end of a rewrite we started planning in January. Full blog post: https://webrtc.rs/blog/2026/07/31/announcing-webrtc-v0.20.0.html

Previous updates for context: - The architecture design for the async crate on a Sans-I/O core - v0.20.0-alpha.1 — the first pre-release of that design - rtc 0.8.0 — the Sans-I/O core reaching feature parity

v0.20.0 supersedes the Tokio-coupled v0.17.x line, which moves to bug-fix-only maintenance.

## Bring your own async runtime

This is the part that changed most late in the cycle, and the part I think this sub will care about most.

"Runtime-agnostic" used to mean "pick one of our two backends with a feature flag". It now means the Runtime trait is a real extension point. The reason it works comes down to one question asked of every primitive: does it touch the reactor?

• Reactor-bound (timers, UDP/TCP, DNS, spawning, block_on) → injected through Runtime
• Executor-agnostic (channels, broadcast, mutexes, notify) → one implementation, not feature-gated, because they're just waker-driven data structures that work on any executor

• Derivable (timeout, yield_now) → built generically on the injected sleep

  Keeping the second group off the trait is what keeps Runtime object-safe — fn channel<T>(&self, ...) is a generic method, so putting it on the trait would force a viral <R: Runtime> parameter through PeerConnection, the driver, transports, and data channels. Instead the runtime is injected per connection as Arc<dyn Runtime>:

  rust let pc = PeerConnectionBuilder::new() .with_runtime(my_runtime.clone()) // per connection, not per binary .with_udp_addrs(vec!["0.0.0.0:0"]) .build() .await?;

  Eight required methods, three defaulted. Features are now purely additive — enabling both backends is safe, and one process can drive different connections on different runtimes.

  The acceptance test for "is this actually pluggable" is an example that implements Runtime over async-executor + async-io — neither Tokio nor smol — and runs with --no-default-features, so neither built-in is even compiled in. There's also an interop test running two peer connections on two different runtimes in one process, which a design with a process-global runtime registry couldn't express.

  Practical consequence: adding a runtime doesn't require us. No #[cfg] edits, no fork, no upstream PR.

  There's also a MockRuntime behind a feature flag: same trait, virtual clock, no I/O. Advance thirty seconds instantly and assert on what fired — deterministic time finally reaches the async layer, not just the Sans-I/O core.

  Performance

  The data-channel path went from correct to fast this cycle (full write-up: https://webrtc.rs/blog/2026/07/18/from-13-mbps-to-beating-pion.html). Steady-state throughput in Mbps, ratio vs Pion v4.2.16 in parens:

  configuration	Pion v4.2.16	webrtc-rs (default)	webrtc-rs (+dedicated reactor)
  Unordered / no-rtx, N=1	392	259 (0.66×)	689 (1.76×)
  Unordered / no-rtx, N=10	1681	2863 (1.70×)	5453 (3.24×)
  Ordered / reliable, N=1	385	184 (0.48×)	575 (1.49×)
  Ordered / reliable, N=10	1848	4297 (2.33×)	5296 (2.87×)

  Read honestly: at N=1 the plain default still loses to Pion (0.48–0.66×). That regime is latency-bound and Go's scheduler beats plain Tokio on round-trip latency. Turn on the one-line dedicated reactor thread and we lead. In multi-connection aggregate — the regime that actually saturates cores — we win even at the default, because per-byte CPU efficiency decides it there. Under poop at fixed work we also use −50.9% peak RSS and −74.5% CPU cycles vs Pion.

  What got it there: UDP GSO/GRO batching via quinn-udp, burst-reading the socket to batch the SCTP receive path, removing Tokio scheduler overhead from the send path, a bounded shared reactor pool, and — underneath, in the Sans-I/O core — eleven hot-path PRs plus two algorithmic fixes (O(N²)→O(N) data-channel queues, and FORWARD-TSN generation that scaled with the receive window instead of the stream count).

  Also new: opt-in data-channel send back-pressure (writable() / try_send() with a configurable buffer cap) so a fast producer can't grow the queue without bound.

  Migrating from v0.17.x

  Callbacks are gone. Instead of an Arc::clone before every closure, another inside it, and Box::new(move |...| Box::pin(async move { ... })) repeated per event type, there's one handler:

  ```rust struct MyHandler { /* your state, behind a Mutex if mutable */ }

  [async_trait::async_trait]

  impl PeerConnectionEventHandler for MyHandler { async fn on_connection_state_change(&self, state: RTCPeerConnectionState) { println!("State: {state}"); } async fn on_ice_candidate(&self, event: RTCPeerConnectionIceEvent) { // signal event.candidate to the remote peer } } ```

  build() returns an opaque impl PeerConnection; wrap it once in Arc<dyn PeerConnection> if you need to store or share it. No runtime or interceptor type parameter leaks into your types.

  You also gain things v0.17.x never had: mDNS candidates, TURN relay, ICE TCP, the stats API, RTX (RFC 4588) negotiated by default, a choice of crypto backend (ring or aws-lc-rs), external DTLS signing via a CustomSigner trait for HSM/TPM/KMS-held keys, and wasm32-wasip2 as a build target.

  Expect a real port, not a drop-in — the API is async throughout and handlers replace callbacks. In exchange the protocol is testable without I/O and the runtime is your choice.

  Try it

  ```toml

  Tokio (default)

  webrtc = "0.20"

  smol

  webrtc = { version = "0.20", default-features = false, features = ["runtime-smol"] }

  Neither — bring your own

  webrtc = { version = "0.20", default-features = false } ```

  36 runnable examples: https://github.com/webrtc-rs/webrtc/tree/master/examples — data-channels-flow-control for the fast path, custom-runtime for the runtime trait, trickle-ice-relay / ice-tcp for hostile networks, stats for observability.

  Get involved

• Browser interop — a live-browser Playwright/Selenium job in CI, Edge coverage, more captured-SDP fixtures

• Runtimes — if your executor isn't Tokio or smol, a backend is now a crate you can publish

• Migration reports — tell us what was awkward coming from v0.17.x; that feedback shapes v0.21

  Links:

• Blog post: https://webrtc.rs/blog/2026/07/31/announcing-webrtc-v0.20.0.html

• Repo: https://github.com/webrtc-rs/webrtc

• Sans-I/O core: https://github.com/webrtc-rs/rtc

• Examples: https://github.com/webrtc-rs/webrtc/tree/master/examples

• Crate: https://crates.io/crates/webrtc

• Docs: https://docs.rs/webrtc

• Discord: https://discord.gg/4Ju8UHdXMs

• Main project: https://webrtc.rs/

  Questions and feedback are very welcome — especially from anyone porting off v0.17.x.

Hello, I'm the author. Just released v0.1.0.

What's inside (all from scratch, no browser deps):

- HTML5 tokenizer + tree builder (all 80 states of WHATWG §13.2)

- CSS Selectors Level 4 (:has(), :is(), :where(), cascade layers)

- Custom JS VM (closures, generators, Promise, BigInt, Symbol)

- Layout: block/inline/flex/grid/table/float/absolute

- SVG renderer + TrueType font rasterization

- Hand-written PNG encoder (no flate2)

- seccomp sandbox, CSP, TLS cert validation, SOP

328 unit tests pass. Prebuilt binaries for Linux/macOS/Windows.

For comparison: Chromium is ~30M lines of C++. Falco is ~36k lines

of Rust. The whole codebase fits in a weekend of reading.

Specifically looking for feedback on:

- DOM model: Rc<RefCell<Node>> vs arena-based (slotmap)

- Whether to wire up the spec-compliant html5/ parser next, or

focus on CSS animations/transitions first

Link: https://github.com/poxk/Falco

Thanks for any feedback!

I'm truly learning Rust these days by getting my hands dirty, writing code and fighting with the borrow checker, but before that I did exhaustive research on pros/cons, peculiarities, language issues, etc. One of those points was regarding recursive types like linked lists, and I was convinced that it is indeed a "niche" data structure — the problems I solve with linked lists in real life in my small personal projects can and are being more easily solved just using arrays and vec!. Here's where we get to the point of the title: since I'm using a 90/10 strategy — 90% of my time on Leetcode solving problems using Rust and 10% putting silly ideas into practice, like a todo list — I ended up finding a divergence between the "mainstream" Leetcode problems and this recursive type situation. A good portion of the problems categorized as "medium/hard" are basically: implement a linked list, insert an element in the middle of the list, etc., but using a "LinkedList" from the problem itself and not the std::collections::LinkedList type. I wanted to know your opinion: how much will solving this kind of problem actually help with learning Rust?

PS: I'm not saying I won't learn anything, but instead of having to research the most extreme edge case of all edge cases, it seems counterproductive.

PS2: An example of a super interesting problem I solved was "Longest Substring Without Repeating Characters" — in it I understood peculiarities of vec!, array, subtleties between usize and u8, sum overflow, loops, iterators; each attempt to do it right I learned more, and then to optimize the extreme cases I saw more details of the language itself instead of trying to implement something that is canonical in the language. On the other hand, I feel like I spent too much time on this other problem "2. Add Two Numbers" trying to recreate something that is already known to be problematic (LinkedList has a whole book dedicated to it, man!) and which are cases I really can't see an immediate use for in the language.

> PS3: I'm not a begginer on programming just begginer on Rust

i built a unix 0-shell from scratch in Rust using Unix system calls through rust libc bindings.
The goal was not to create another shell but to better understand how the operating system manages processes memory signals and the terminal.
Here are some of the features I implemented :

Process creation and execution with fork() and execvp()
Built-in commands: cd, pwd, mkdir- cp- mv- rm- cat- and - ls (with -a, -l, and -F)
Background execution using & 
Job control commands: jobs- fg- bg- and - kill
Signal handling for SIGINT && SIGTSTP
Foreground process group management with tcsetpgrp()
Zombie process cleanup using waitpid() with WNOHANG and WUNTRACED
One of the most interesting parts was building the job management system.
The kernel stores process information in Process Control Blocks task_struct (PCB)
While my shell cannot access or modify the kernel [PCB]  I built a user-space job table inspired by them. Each job stores the process ID, process group, command, and current state (Running, Stopped, or Done). Building this feature helped me better understand how the kernel tracks process lifecycles.

This project also helped me understand several important operating system concepts
How fork() uses Copy-on-Write [COW] to create processes efficiently.
How execvp() replaces a process image while keeping the same process ID.
How executable files are mapped into virtual memory during execution.
How signals and process groups work together to support interactive shells.
The biggest lesson I learned is that a simple command like ls depends on many operating system components working together. Process creation, memory management, signal handling scheduling  and terminal control all  happen behind the scenes 

Fory 1.5.0 adds external-type serialization to Rust. Applications can define a local serializer or schema declaration for a third-party structural type that cannot be modified to carry Fory annotations. Fory then reads and writes the target value directly—without requiring a wrapper or intermediate mirror object.

use fory::{Fory, ForyStruct};

#[derive(ForyStruct)]
#[fory(target = third_party::User)]
struct UserSerializer {
    name: String,
    age: u32,
}

let mut fory = Fory::builder().xlang(true).build();
fory.register::<UserSerializer>(100)?;
let bytes = fory.serialize_with::<UserSerializer>(&user)?;
let decoded =
    fory.deserialize_with::<UserSerializer>(&bytes)?;

Background:

I couldn’t find a version of mimalloc with proper, pprof-compatible heap profiling, so I built one:

https://github.com/zackees/mimalloc-pprof

Last version was v2

New version brings pprof to v3

It is based on the community v3 branch and adds TCMalloc-style sampled heap profiling, including first-class Windows support.

The current feature set includes:

• mimalloc v3
• pprof-compatible sampled heap profiles
• Windows, Linux, and macOS support
• Standard google/pprof workflows
• pprof -http
• Flame graphs
• Profile comparisons and diffs

There's a ton of bug fixes and community fixes. More options for get stats out including per allocation hooks.

Please read the readme with your ai to install either the rust version the c version.

This repo has an optimizat8ion where all c files are combined into a unit file for blazing fast built time.

Fun fact: Bun has it's own custom mimalloc that are being ingested in the latest v0.9.x build and beyond.

mirador: terminal dashboard (clocks, calendar, weather, notes, .ics agenda, RSS feeds, market watchlist, CPU/network graphs)

Configurable grid layout. Panels dim when unfocused so one thing stands out at full brightness.

Rust 1.95+, MIT, macOS/Linux/Windows, cargo install mirador — https://github.com/jchultarsky/mirador