Go is simpler but has a light overhead (2KiB per goroutine and 30 to 75 nanoseconds to spawn one), but Rust has a fragmented ecosystem where async is dependent of the runtime and the related functions comletely differ from the synchronous ones.

It shows how using RAM efficiently can increase performance.

In this article, crates that only use core and alloc will be referred to as no_std, whereas the subset of crates that can compile without alloc will be called no_alloc.

The bet is AI can rewrite large portion of codebases. Let's see.

Using DEBUG compilation slows down the compilation by nearly ~40 times.

Why ?
LLVM represents variable locations through DBG_VALUE records. Heavy function inlining can create hundreds of thousands of these records in a single function.

WebAssembly’s Register Stackify pass moves values from virtual registers onto the operand stack to produce compact, efficient wasm. While moving instructions, it repeatedly scans basic blocks to find and update debug records. Those linear scans are repeated for many definitions, while the pass also leaves invalidated records behind and creates new records for duplicated cheap computations. The result is quadratic work on increasingly large instruction lists.

As example:
Module: repro total codegen
Current Rust: 52.58s
LLM fix:7.12s
Author fix: 1.99s

and serving a complete web app

A safe, single-binary, offline viewer for the official BSI Grundschutz++ catalog, written in Rust. The complete OSCAL catalog from the BSI Stand-der-Technik-Bibliothek is embedded in the executable at compile time: copying the binary to any machine is a full installation — no install step, no database, no network access required.

So yes, it's one binary and it is one way to transfer data and make it usable.

The project is available on GitLab: https://gitlab.com/vPierre/ndaal_public_bsi_grundschutz_oscal_viewer

Five Rust working groups stance on the AI usage on Rust lang

Full of great explanations about securing (hardening) Rust code.

• treat panic behavior as part of your API. Decide explicitly whether panics should unwind or abort, and avoid uncontrolled panics.
• enable stricter Clippy lints (such as indexing and arithmetic checks) when panic freedom is important.
• use a panic hook to shutdown gracefully, set reports, cleanup, collect diagnostics and
• sanitize panic (and logging) messages while logging. veil is a good crate for that.
• avoid unbounded recursion. Prefer iterative algorithms or use depth limits.
• releases builds behave differently. They should be accordingly tested.
• audit dependencies with cargo-audit and cargo-deny
• secure allocation (for defense-in-depth when using unsafe code or FFI) with mimalloc or similar. Measure performance before enabling it globally.
• use minimal runtime images if needed (rust distroless). It reduces the attack surface.
• use multi-stage builds with cargo-chef, --locked and proper .dockerignore
• avoid alpine musl lib c as it introduces subtle runtime differences; at least be aware of them.
• use Linux landlock to restrict filesystem access even after compromission
• never run as root unless absolutely necessary. Drop as much Linux capabilities as possible.
• use Miri to detect undefined behavior, invalid pointer usage and unsafe-ode bugs.
• handle SIGTERM/SIGINT properly. Stop accepting new work, finish inflight requests, flush buffers and then exit cleanly
• protect external dependencies (database, API, cache) with circuit breakers so repeated failures don't cascade
• put explicit limits on everything: upload size, request bodies, queues, timeouts, thread counts,
• expose two health endpoints: a liveness probe and a readiness probe. The liveness probe checks if the process is alive at all, while the readiness probe checks if the process is healthy enough to handle traffic.
• Use fuzzing (cargo-fuzz, honggfuzz), coverage (cargo-llvm-cov), unsafe detection (cargo-geiger), and memory-analysis tools alongside Rust's compile-time guarantees.

A ripgrep dedicated for Rust

1. Stop allocating useless strings: to_string(), .clone(), HashMap borrow the string
2. Optimize hashmap lookups with hashmap.entry().or_insert(0) += 1 instead of 3 lookups: in an if condition, insert operation and update.
3. Use as much core as possible: rewrite loops as iterators and then use rayon with par_lines.
4. remove() in array is a costly O(n) operation. If order is not important, prefer swap_remove.

1. Rust doesn't prevent TOCTOU (Time-of-Check to Time-of-Use) race conditions (file path resolution → use file handlers directly)
2. Panics are denial-of-service vulnerabilities when handling untrusted input.
3. In case of a well established tool, compatibility is a security feature.
4. Resolve external information before crossing trust boundaries.
5. The interactions with the operating system is a security boundary in Rust. The developer has to be careful.

The post goes in-depth for many cases.

For later when it will be needed.

Some projects has more value to be written in Rust:

• Rust's safety allow to use complex patterns more safely
• Concurrent or multi-threaded systems
• Security-critical components

There are three approaches for ar Rust migration:

• Full Rewrite
  • the codebase is relatively small and the scope is tractable
  • there is an exhaustive blackbpx test suite that validates behavior
  • the API surface is well defined and stable
  • the deployment environment is controlled
• Incremental migration for each module
  • all other use cases
• Incremental migration with vertical features: each feature is built from the ground up to use 100% Rust code. Business value can be measured directly.

The incremental migration has its own challenge: FFI with C and C++. The rule of thumb is to keep the code responsible for the memory allocation do the deallocation.

An alternative yet similar to VSCode

From 2-10 nanoseconds to 700 picoseconds to format a number.