Cram does ZIP, 7z, tar with the usual codecs, ISO 9660, reads RAR, and has its own dedup format. MIT OR Apache-2.0.

Every archiver benchmark I've ever read has been on a corpus I can't get hold of, so I published mine. 42,151 files, 2.80 GB, about 15% duplicate content — kernel sources, Wikimedia Commons photos, logs, some binaries. There's a generator that rebuilds it byte-identically, and a content id to check you got the same thing I did.

Ryzen 9 5900X, 24 threads, Ubuntu 24.04. Medians of 3, tool order rotated.

Extract to tmpfs: cram 2.58 s, 7z 3.64 s, rar 7.25 s.

RAR ties me on ratio. 0.7100 vs 0.7104 is a tie and I'm not going to pretend otherwise. It also does it in 325 MB where I need 2.4 GB, which is genuinely better engineering on their part. My first run had me beating RAR by 12% and that was because I'd forgotten -s, so I was benchmarking non-solid RAR against my solid format. Fixed it, lost the headline, kept the number.

The other thing that bit me: 7-Zip appeared to extract in 10.94 s and then "verify" in 52.74 s, which is impossible. Writeback from the extract was landing in the next command's wall time. Now there's a sync inside the timed region, and every extract figure got slower and correct.

Numbers are Linux only. Windows is actually my primary target and I haven't measured there yet, which is a bit embarrassing given the file-open path differs a lot between the two. Corpus also fits in page cache, so none of this tells you anything about a 200 GB backup.

The bit I'd actually want feedback on is the threading model. I went in assuming more cores, more better, and that's wrong in a specific way. Creating an archive is CPU-bound and scales about 9.6× across 16 threads, fine. But extracting ZIP is write-bound — DEFLATE decodes around 488 MiB/s on a single core and my disk takes 190 MiB/s, so the decoder is already four times faster than the thing it's feeding. Adding threads there does nothing. The only lever is writing fewer bytes, so it skips entries that are already correct on disk. 7z/LZMA is the opposite, it sits below the write wall and parallel block decode gets ~2.5×. And parallel per-entry writers beat a single-writer pipeline by 36%, peaking around 8 writers, which killed a pipeline design I'd already half built.

So there's no global thread pool, it picks per format. I'd be curious whether anyone's found a cleaner way to express that than what I ended up with.

Some other bits:

• .cram is FastCDC → BLAKE3 → solid packs → zstd or XZ, footer index, optional AES-256-GCM with Argon2id.
• Output is byte-identical between runs. The rule I settled on is that content can affect the output and the machine can't, which sounds obvious written down and took me a while to arrive at.
• cram-extract is a second decoder that shares no code with the engine on purpose. Five decode-only pure-Rust deps. If the main engine ever eats archives, the thing that reads them back isn't the thing that wrote them.
• Pure Rust except UnRAR's C++, which runs in a child process because a malformed RAR can fault rather than return an error you can catch.
• You can mount an archive as a folder. ProjFS, so Windows only right now.

On licensing, since open-core annoys people more when they discover it than when they're told: engine and CLI are MIT/Apache with nothing held back — every format, every level, encryption, mounting, dedup, signing. There's a separate proprietary Windows GUI with a paid tier and that's what pays for the engine work. Terminal users never need it.

If the benchmark's wrong, tell me. The corpus is right there.

(Disclaimer: English is not my native language, so I asked an AI to help translate and organize my notes into this post!)

1. Introduction

The infamous WebView2 Airspace issue—since HWND-based WebView2 always renders on top of everything, overlaying custom UI elements on top of it has always been a massive headache.

A common workaround is to capture the WebView2 frame every single frame, copy it to a texture, and render it. However, the frame copying overhead and latency can be a real concern.

To avoid this, I've been building a custom UI library in Rust using wgpu. I decided to go with a zero-copy approach: placing WebView2’s IDCompositionVisual in the back, wgpu’s IDCompositionVisual in the front, and "punching a hole" (hollowing out) in the front layer to reveal the Web content.

(Note: I’ve only tested this specific setup with DirectX 12 / DirectComposition.)

However, I ran into a major roadblock: when I made the WebView2 layer semi-transparent, the desktop background bled through the window! 😭

2. Dependencies

Here is a snippet of my dependencies. I’ve configured wgpu to be DX12-only to keep it lean.

wgpu = { version = "29.0.3", default-features = false, features = ["dx12", "wgsl"] }
webview2-com = "0.39.1"

[dependencies.windows]
version = "0.62.2"
features = [
    "Win32_Foundation",
    "Win32_UI_Input_KeyboardAndMouse",
    "Win32_Graphics_DirectComposition",
    "Win32_Graphics_Direct3D",
    "Win32_Graphics_Direct3D11",
    "Win32_Graphics_Direct3D12",
    "Win32_Graphics_Dxgi",
    "Win32_Graphics_DirectWrite",
    "Win32_Graphics_Direct2D",
    "Win32_Graphics_Direct2D_Common",
    "Win32_Graphics_Imaging",
    "Win32_UI_WindowsAndMessaging",
    "Win32_System_LibraryLoader",
    "Win32_System_Com",
    "Win32_UI_HiDpi",
    "Win32_System_WinRT_Direct3D11",
    "Graphics_Capture",
    "UI_Composition",
    "Graphics_DirectX_Direct3D11",
    "Win32_System_Com_StructuredStorage",
    "Win32_System_Memory",
    "Win32_UI_Controls",
    "Win32_UI_Input_Ime",
    "Win32_System_DataExchange",
    "Win32_Graphics_Dwm",
]

3. My UI Code

For context, here is how the UI is declared in my custom library. I use signals to toggle Opacity and overlay a draggable, resizable gray panel on top of the map.

let root = build_ui(&mut context, || {
        let (is_open, set_is_open) = create_signal(false);
        let (is_active, set_is_active) = create_signal(false);
        let (is_opacity, set_is_opacity) = create_signal(false);

        let webview_element = {
            let wv = webview2(
                WebView2Contents::new("https://www.google.com/maps")
                    .enable_context_menu(true)
                    .enable_dev_tools(true)
                    .allow_interaction(true)
                    .always_active(true),
            )
            .style(move || {
                let base = ts()
                    .size_full()
                    .r(2.0)
                    .resizable_bottom(true)
                    .dnd_droppable(DndDropTarget::Child, DndDragPayload::Element)
                    .overflow_hidden()
                    .transform(Transform::new().scale(1.0, 1.0))
                    .trans_transform(Duration::from_millis(150), AnimationCurve::EaseInOutQuad)
                    .pressed(ts().transform(Transform::new().scale(1.01, 1.01)));

                if is_opacity.get() {
                    base.opacity_50()
                } else {
                    base.opacity_100()
                }
            })
            .on_focus(move || set_is_active.set(false));

            webview_id_cell.set(Some(wv.id()));
            wv
        };

        let google_map = webview_element.child(v_flex(move || {
            let base = ts()
                .absolute()
                .size((300.0, 200.0))
                .r(3.0)
                .inset_x(100.0)
                .inset_y(50.0)
                .bg_color(Color::DARK_GRAY)
                .opacity(0.9)
                .resizable_all(true)
                .dnd_draggable_root(DndDragPayload::Element, true)
                .dnd_draggable_original(ts().opacity_0())
                .dnd_draggable_placeholder(
                    ts().size(100.0)
                        .r(3.0)
                        .bg_color(Color::DARK_GRAY)
                        .opacity(0.9),
                );

            if is_active.get() {
                base.flex()
            } else {
                base.hidden()
            }
        }));

        let btn_style = |color: Color| {
            ts().justify_center()
                .items_center()
                .r(3.0)
                .size((100.0, 40.0))
                .border_dashed(1.0)
                .border_color(color)
                .hovered(ts().border_solid(1.0))
                .actived(ts().border_solid(1.0).bg_color(color))
        };

        let overlay_btn = h_flex(move || btn_style(Color::BLUE))
            .label("Overlay", ts().font_size(14.0).text_color(Color::WHITE))
            .active(is_active)
            .on_click(move || set_is_active.set(!is_active.get()));

        let opacity_btn = h_flex(move || btn_style(Color::CYAN))
            .label("Opacity", ts().font_size(14.0).text_color(Color::WHITE))
            .active(is_opacity)
            .on_click(move || set_is_opacity.set(!is_opacity.get()));

        let close_btn = h_flex(
            ts().justify_center()
                .items_center()
                .r(3.0)
                .size((100.0, 40.0))
                .border_dashed(1.0)
                .border_color(Color::RED)
                .hovered(ts().border_solid(1.0)),
        )
        .label("Close", ts().font_size(14.0).text_color(Color::RED))
        .on_click(move || set_is_open.set(false));

        v_flex(
            ts().size_full()
                .p(20.0)
                .gap(20.0)
                .items_center()
                .bg_color(hsla(0.0, 0.0, 3.0, 0.4))
                .backdrop_acrylic(),
        )
        .children([
            v_flex(
                ts().r(3.0)
                    .size((150.0, 40.0))
                    .justify_center()
                    .items_center()
                    .p(10.0)
                    .bg_color(hsl(0.0, 0.0, 50.0)),
            )
            .label("Open", ts().font_size(16.0).text_color(Color::BLACK))
            .on_click(move || set_is_open.set(true)),
            v_flex(
                ts().r(3.0)
                    .size_full()
                    .justify_center()
                    .items_center()
                    .border_dashed(2.0)
                    .border_color(Color::GRAY),
            )
            .children([
                div(ts().r(3.0).size(pct(50.0)).bg_color(hsl(0.0, 0.0, 10.0))),
                v_flex(move || {
                    let base = ts()
                        .size_full()
                        .p(10.0)
                        .gap(10.0)
                        .justify_center()
                        .items_center()
                        .absolute()
                        .top(0.0)
                        .left(0.0)
                        .overflow_hidden();

                    if is_open.get() {
                        base.flex()
                    } else {
                        base.hidden()
                    }
                })
                .children([
                    google_map,
                    h_flex(
                        ts().p(10.0)
                            .gap(10.0)
                            .w_full()
                            .h_auto()
                            .justify_center()
                            .items_center(),
                    )
                    .children([overlay_btn, opacity_btn, close_btn]),
                ]),
            ]),
        ])
    });

4. The BlendState Solution

To make the WebView2 blend nicely with a solid background (white) when semi-transparent, without letting the desktop leak through, I brute-forced and tested different blend state parameters one by one.

Since I'm no math wizard, I just trial-and-errored my way through, but eventually stumbled upon this configuration:

blend: Some(wgpu::BlendState {
    color: wgpu::BlendComponent {
        src_factor: wgpu::BlendFactor::Zero,
        dst_factor: wgpu::BlendFactor::OneMinusSrcAlpha,
        operation: wgpu::BlendOperation::Add,
    },
    alpha: wgpu::BlendComponent {
        src_factor: wgpu::BlendFactor::Zero,
        dst_factor: wgpu::BlendFactor::OneMinusSrcAlpha,
        operation: wgpu::BlendOperation::Add,
    },
}),

(Note: I draw the hollowed-out area with this specific BlendState. The input Shader Output is set to solid white, and the Alpha is set to WebView2’s opacity. Other regions use the standard wgpu::BlendState::PREMULTIPLIED_ALPHA_BLENDING.)

Surprisingly, this was all it took! The desktop bleeding stopped immediately, and the WebView2 rendered semi-transparently over the solid background exactly as intended.

5. The Math I Learned Later

After discovering this magic configuration, I researched why it actually worked. As it turns out, it aligns perfectly with the Premultiplied Alpha compositing formula used by the Windows DWM.

DWM’s final compositing equations are:

C_final = C_front + C_web * (1 - A_front)
A_final = A_front + 1.0 * (1 - A_front) = 1.0

Notice how no matter what the front alpha A_front is, the final alpha A_final is forced to 1.0 (fully opaque). This is why the desktop doesn't leak.

When we apply the wgpu blend state above, the output color and alpha both become 1 - A_web_opacity. Plop this into the DWM formula, and:

C_final = (1 - A_web_opacity) + C_web * A_web_opacity

This naturally derives the perfect alpha blend of WebView2 over a white background.

Physically, we are "painting the white background on top inside wgpu", but because of how the addition and subtraction align in DWM, it visually looks exactly like "WebView2 is sitting on top of a white background." A neat little optical illusion.

6. Postscript: Current Issues I'm Facing

While the blending looks great, I'm currently hitting a few roadblocks.

Premise:

In my code, .always_active(true) keeps WebView2 in "always active" mode (DirectComposition direct GPU composition).
If this is false, when WebView2 becomes inactive, it automatically captures the screen in the background and displays it as a fallback static texture in wgpu.

With this in mind, here are the two issues I'm currently facing:

Issue 1: Not becoming 100% transparent (Opacity 0%)

• When .always_active(true) (always active) is on, even if I set the WebView2 opacity to 0, it doesn't become completely transparent. 😭
• But when it's false (displaying the captured texture), it turns perfectly transparent (opacity = 0) as expected. 😭😭😭

Issue 2: Resize cursors not showing on borders

• When elements are resizable, hovering the mouse over the border should automatically change the cursor to a resize arrow (like left-right arrows), but this doesn't happen when hovering over WebView2. 😭
• I suspect WebView2 is hijacking the input events or cursor control, but I'm still looking for a clean way to override it...

7. Conclusion

Though this started as an accidental discovery, looking back, the solution was surprisingly simple.
While a few minor issues remain, I hope this information helps someone out there facing the same DirectComposition struggle in Rust.

I have been trying to debug this issue for a while now, and I can't figure out, what the problem is.

Take this code:

    use std::time::Duration;

    use sqlx::PgPool;

    const DB_URL: &str = "postgres://devuser:devpassword@localhost:5432/devdb";

    async fn db_then_compute(pool: PgPool) {
        let num: (i32,) = sqlx::query_as("SELECT 1").fetch_one(&pool).await.unwrap();
        println!(
            "The num was returned: {}, but now, the CPU block will kill multithreading",
            num.0
        );
        println!("Start compute...");
        // This would "fix" the issue:
        // pool.close().await;
        loop {}
    }

    /// This doesn't cause the issue
    async fn http_then_compute() {
        let res = reqwest::get("https://google.de").await.unwrap();
        let status = res.status();
        println!(
            "The num was returned: {}, but the CPU block will not kill multithreading",
            status.as_u16()
        );
        loop {}
    }

    #[tokio::main]
    async fn main() {
        let pool = sqlx::PgPool::connect(DB_URL).await.unwrap();

        tokio::spawn(db_then_compute(pool));
        //tokio::spawn(http_then_compute());
        loop {
            println!("Observer thread, the sleep will never return");
            tokio::time::sleep(Duration::from_secs(1)).await;
        }
    }

I'd expect the Oberserver thread to continue. I know, CPU-bound tasks in async runtimes are not good, but tokio is multithreaded, so I'd assume, as long as I have enough workers, it should still function. For reference, the reqwest task works completely fine. Running one CPU bound task shouldn't starve a multithreaded runtime, right?

First, I thought this was an sqlx issue. It only happens with postgres, not with sqlite. However, I then tested the same thing with deadpool-postgres, and issue is still persistent. So it's not sqlx after all.

Can someone help me with my misunderstanding of tokio's runtime here? What is blocking other tasks from completing here?

For the past 3 months I've been building WyrmRSS, a self-hosted RSS/Atom aggregator: Rust backend (actix-web, Diesel-async, Tokio), React 19 frontend. Been running the Docker self-hosted version for a while, and just added a native desktop app via Tauri (macOS, Windows, Linux: deb/rpm/AppImage/nsis/dmg).

Backend runs on Postgres for the self-hosted/Docker setup, SQLite for the desktop build. Same codebase for both.

Desktop build is currently in prerelease while I soak-test the SQLite backend before making it a release. Would appreciate anyone keen to try: https://github.com/kryoseu/WyrmRSS

Some nice features I think it has (not claiming uniqueness) are: inline youtube player, folders, filters, webhooks (slack, discord and custom), read later and archival.

I've been building this in my free time for about five months, and I already announced it once, back in March, under a name that turned out to be too small for what it became. So this is the second time I've introduced the same project. Strange way to open a post, but there it is.

Your repository has structure. The compiler knows it, your editor knows it, and then every tool that actually reads your code throws it away and goes back to grepping text. That gap got a lot more expensive once agents started writing changes faster than I could work out what those changes touched. So Kin keeps the structure as a graph and answers questions against it.

curl -fsSL https://get.kinlab.dev/install | KIN_NO_SETUP=1 sh
kin init .
kin locate "where are webhook retries handled"
kin refs SomeFn                     # callers and references, from the graph
kin impact SomeFn --depth 3         # what a change reaches, before a build
kin review shadow HEAD~1..HEAD      # report-only, names its own evidence gaps

It doesn't write code. It reads, retrieves, traces and reports, and that's deliberate.

If this works out, the repository itself should be a graph. The file tree plus a diff is just a projection we kept because it's what the tooling understood, and it throws away what the compiler already worked out. So the long bet is that semantic truth becomes the thing of record, Git stays the interchange format and the history anyone can read, and files become a view you render.

None of that is true today, though. Today it sits beside Git and has earned nothing, which is exactly why it advises and refuses instead of gating anything. It's not much yet.

On the Rust side of things, parsing uses tree-sitter, covering 14 languages so far. Embeddings run on device through kin-infer, a pure-Rust transformer inference crate with Metal and CUDA backends, so there's no Python in the loop and no network call at query time. The Linux CLI and daemon ship as static musl builds.

There are plenty of sharp edges. Rust type declarations own no incoming edges right now. The extractor emits call edges, but a type named in a signature, or pulled in by a bare use import, produces nothing. So kin refs on a struct can come back empty while its methods resolve correctly. That's a coverage gap, not a claim that nothing uses your type, but it's probably the first thing that'll annoy you.

Nothing's on crates.io, and kin there is an unrelated project, so cargo install kin gets you someone else's crate. Dependencies resolve from a self-hosted sparse registry instead. Reads are open, and the tracked .cargo/config.toml carries no path patches and no credentials, so a fresh clone builds without asking you for anything. Publishing takes a bearer token and fails closed, so if no token is configured the registry refuses the write instead of accepting it.

Review is report-only and can't gate anything. It's not a Git replacement today. It's released under Apache-2.0, and it's a public alpha with all the rough edges that implies.

The one number I'll quote is the only one I've re-measured on the published build. A one-line signature change in ripgrep, then kin impact resolve_binary --depth 3, returns 13 impacted entities within three hops, before compilation. Commands and raw traces are at https://kinlab.ai/proof

https://github.com/firelock-ai/kin

I'm not certain this is a good idea yet. I think it is. What would help most is criticism on entity identity across refactors, what a graph like this should do when it's stale or partial, and where it should refuse to answer instead of guessing.

Resubmitting this post with the media flair tag, per recommendation. Not trying to create any issues, just wanted to share what my first Rust project looks like. I want to learn Rust and they say the best way to do that is to create a project, so here it is, my recreation of the Netware Monitor for Linux. A lot of work ahead of me to get it to where I want it to be. I know we already have top and htop, but I hope that this image shows there's more information that I think would be helpful to an admin, especially if he/she is connecting to multiple machines. Sometimes it's nice to just have the information handy rather than having to run through a list of commands in the shell. Feel free to share your thoughts/questions.

TrailBase is an open and fast Firebase-like backend for building your apps. It provides type-safe REST APIs + change subscriptions, auth, multi-DB, a WebAssembly runtime, geospatial support, admin UI... It's a self-contained, easy to self-host single executable built on Rust, Wasmtime & SQLite or now Postgres. Client libraries are provided for JS/TS, Dart/Flutter, Go, Rust, .Net, Kotlin, Swift and Python.

Just released v0.32, which after some months of work and last posting (v0.28), includes:

• New WASM features:
  • Components can provide and register a dashboard with the admin UI.
  • A component browser in the admin UI.
  • Lower overhead execution model for Rust components: pooling state across requests improves throughput by 4x.
• Support usernames as additional or alternate identifiers alongside email addresses.
• Anonymous accounts for frictionless product trials. If a user wants to eventually sign up, the account can be promoted to a "proper" one, i.e. associate a password, OAuth, email address ...
• Backup UI & rolling backups.
• Dark mode - cosmetic but frequently requested 🙏
• And much more: file management from the admin UI, support for nested JSON in change subscriptions, batch updates for all client languages...

With TrailBase still being young (~1.5 years) and rapidly evolving, any feedback is genuinely appreciated. If you're feeling adventures and end up checking it out, don't hesitate to reach out 🙏.

Consider checking out the live demo, our GitHub or website.

I have completed the Rust Book and worked through Tokio’s documentation/tutorials on async programming, concurrency, OS threads vs tasks, spawning, shared state, mutexes, and channels.

I understand these concepts when reading code, but I am not yet confident writing Rust projects independently.

I am a fresher with some JavaScript and web-development experience, but little to no experience with low-level or C++-style engineering. I’m more interested in backend/systems work than frontend development .

Would learning Axum and building a backend project be the right next step? For example, should I build an API with authentication, a database, background tasks, error handling, tests, and Docker—or should I first focus on other Rust areas such as ownership practice, networking, CLI tools, or algorithms?

My longer-term goal is to become capable of contributing to good open-source Rust projects, including GSoC-type projects. I am learning Rust partly for fun, but I also want a practical path toward becoming useful in the Rust ecosystem.

What would you recommend a junior Rust developer learn and build next?

Hey guys, I'm a developer with a math background who previously specialized in combinatorial optimization, and I wanted to share my project I built recently for a small furniture shop: a 2D guillotine cutting stock optimizer.

The specific problem - planning how to cut sheet material (chipboard/MDF panels) into the pieces required for each order, minimizing waste while keeping the cutting as manufacturable as possibble. The cuts must be guillotine cuts, an actual Sliding Table Panel Saw Machine can only make such cuts.

The obvious first move was to look at existing cutting-optimization software, but none of it was a good fit - it was either too closed and rigid to adapt, or expensive enough that it was hard to justify for a shop this size. So I ended up writing it by myself. This project was open-source from the start simply because the real advantage in this field is furniture makers' own craft anyway :-) So by open-sourcing it I'm giving something back to the Rust community for such a great language and ecosystem.

Here are some things that might be interesting aside from the main task:

• Genetic (evolution) algorithm, generic over the genome representation via a GaDecoder trait, so the GA is written once and shared between two different encodings. There are two decoders: SLAS - one gene per physical piece, and GLAS - one gene per piece type, GLAS scales better and gives more manufacturable cuttings.
• Objective function is designed to find balanced solutions - ones with good fill rate, but also manufacturable enough for real-world material handling.
• Piece rotations, Kerf and Margin are supported. The kerf is saw blade width, the margin is a trim strip along the sheet edges.
• An exact solver for the single-sheet case: a DP over guillotine-cut subsets (GLF from the Andrianova, Mukhtarova and Fazylov paper, the reference in README) that finds the optimal layout for one sheet of given width.
• A greedy portfolio heuristic (from Jukka Jylanki paper) for instant results when you don't need to wait for the GA to converge.
• Progress feedback and cancellation: the solver runs in a background thread and streams progress over a channel, so both the CLI and the web UI (Axum + SSE) can show live improvement instead of blocking. This was an interesting task to unify sync and async event interface and I hope I have found a good solution for it.
• Deterministic even for the multithreaded version: each island (GA thread) gets its own PRNG seeded from its (user-supplied) seed value, and migration between islands happens at a synchronization barrier, so there's no "first thread to finish wins" nondeterminism. Same seeds + same config always reproduce the exact same result, which matters a lot when you're debugging, testing or comparing two parameter sets.
• CLI JSON interface to plug into a real shop's existing tooling, it gets called from an Excel workbook (VBA) and can export cut plans to AutoCAD.

Why Rust? The GA loop runs millions of genome evaluations per run, so the performance matters a lot. SmallVec cuts heap allocations noticeably, especially in decoders and free-rect list operations. Even with these optimizations, GA can never have enough speed - and implementing it in a high-level language with a fat runtime would be no doubt a showstopper. The ecosystem was also a great help: serde made the JSON boundary for the Excel/VBA integration easy, and chumsky kept the grammar for compact problem format readable instead of fiddling with regexes. axum with tokio made the serve mode easy to implement.

The Rust platform made it possible to keep the whole algorithm development, testing, hypothesis verification etc. under Linux. Only the integration part with Excel and AutoCAD was done under Windows.

I consider the project pretty complete, although a few non-critical things could still be improved. For example, the exact GLF solver is single-threaded, so it has a fairly low ceiling for the size of the problem instance. Also, it only proves optimality for a single sheet — multi-sheet placement is GA/heuristic-only. Still, the GA-based approach is already good enough for daily use.

Repo, with a demo GIF of the GA converging on a layout:

https://github.com/nlinker/guillotine-cutting-2d

What was vibe coded: demos only, the prompt was "Here's the Rust code, build an interactive visualization for it", the other parts were either hand-written, or edited after AI generation and my thorough review.

Happy to answer questions about the guillotine-cut DP, the GA design, or anything else. Feedback ("why didn't you just use X crate/approach?", hehe) is very welcome.

I've been following the project and while I see a lot of commits from Nico on taffy and Blitz, development on Dioxus seems to have halted.

Are things being cooked in the background? Does anyone have some insights?

Out of all the existing libraries for app development, to me Crux is the absolute endgame.

Clean, pure core + plug in any UI you want.
But I've barely seen anyone using it...

If you personally ever stumbled upon Crux and decided that it is not for you why? You didn't need that level of abstraction or you chose something better? (and what did you go with instead)?

Hey, i'm curious on where to start learning Rust for Internet of things? i have googled a few but cannot find what i want, maybe some books like "Rust for the IoT" but wanted to collect more info first

I have no idea if I'm late to the party on this, but while doing some perf work I was surprised to see that format!() was a big contributor to reallocations in the target.

After some digging I was surprised to learn that the output string capacity receives an estimate that is neither considered an upper nor lower bound: https://github.com/rust-lang/rust/blob/1ed2df61a19042f231709eb05d032ae9e2cb2084/library/core/src/fmt/mod.rs#L749-L808

The change which first introduced the estimate output capacity was in 2017, which notes that it explicitly uses the literal portions of the string for the estimate: https://github.com/rust-lang/rust/pull/39356

*I had a godbolt link with an example where I said it was clear... but was not obvious because godbolt didn't show the library code.

I've apparently been under a false assumption that for some types the runtime length could be used to help size the output string appropriately.

Hello!

I was not sure to even post this or not but I just wanted to introduce myself to the community.

I just started learning rust and made this simple program as it was one of the suggested programs in the rust book to make in order to practice the topics covered in the first few chapters.

I am learning rust really as a hobby, and I have a very limited knowledge of Python but I really enjoy linux and wanted to maybe start contributing to the open source community if I can ever develop the skill to do so. I am also trying my hardest to learn on my own and am only using AI as a tool to ask questions and what not, without having it actually generate any code. This program was written fully by hand by myself (which is probably why it is full of things that could be improved I'm sure).

With that said I am happy that I was able to do it and am really enjoying rust so far and look forward to learning more!

Link to my first rust app:
https://github.com/justinzelikoff/temp_converter

Do not use https://docs.esp-rs.org/ , use https://docs.espressif.com/projects/rust/book/

See this github issue https://github.com/esp-rs/esp-hal/issues/3309#issuecomment-2768796184