Hello everyone! Excited to post my first project in rust. Has several month under the bell and has been tested in real applications, so it's ready to be shown the world!

I'm the author of ethernetip-*, a set of crates (ethernetip-core, -logix, -connections, -safety, v0.1.1) implementing EtherNet/IP and CIP Safety in Rust on tokio.

What's there: - Logix tag client and server: Read_Tag/Write_Tag, automatic fallback to fragmented reads, tag browsing, array indexing like arr[1,2,3], and ControlLogix backplane routing with a libplctag-style path ("1,0"). - Class 1 implicit I/O: adapter (target) and scanner (originator), with one tokio task per connection and MissedTickBehavior::Skip for jitter-tolerant RPI timing. - CIP Safety, originator and target: CRC-S1 through S5, base and extended frames, Time Coordination, and the Safety Supervisor object.

I also created similar implementations in C#, Python and C++, if you want to cross-check.

Repo: https://github.com/CristianMori/EthernetIpRust · crates: https://crates.io/crates/ethernetip-core

Feedback on the API shape is very welcome, especially from anyone doing industrial or embedded Rust.

Hi everyone!

Yesterday we released version 0.4 of the qtbridge crate. The technical changes to 0.3 are relatively small. We focused on local hardening and bugfixes and exchanged the QMethodInvoker with a type safe QThreadHandle.

More importantly, we took the next step and entered Technology Preview. It is an important step for us, showing that we get closer to the first stable release. The core API is mostly in place but might still change in a couple of places. That also means that your feedback is now more valuable than ever.

Thanks to everybody that gives this a try and gives us feedback. We already got quite some good input that we are very grateful for!

You find more information in our blog post: https://www.qt.io/blog/qt-bridges-technology-preview-rust-csharp (There is also a short video of me showing some things 😄)

fn player_turn(hand: &mut Vec<Card>, dealer_hand: &Vec<Card>){
    let mut done: bool = false;
    while !done{  //cannot apply unary operator `!` to type `bool`
        display_hand(hand, false);
        display_hand(&dealer_hand, true,);
        let choice = get_input();


        if choice == "h" {
            deal_card(hand);
        } else if choice == "s" {
            done = true;
        }


        if hand_value(hand) > 21{
            done = true;
        }
    }

I'm pretty new to computer science and this is baffling me

Wild version 0.11.0 is out. Wild is a fast linker for Linux and Wasm.

That's right, Wasm is now a supported platform! The Wasm port is working reasonably well and has great performance. The Wasm port was largely done by lapla-cogito during GSoC 2026.There are of course still a few things to be done like debug info.

Linker script support has advanced considerably. This is largely the work of vishruth-thimmaiah during GSoC 2026.

Lots of work has also been done on the Mac port, which is now to the point where at least one of the maintainers is using it as their default linker for Rust on Mac. It's not yet stabilised and there's still plenty to be done.

We've had some performance gains and losses that to some extent cancel each other out. Some performance was lost by adding proper COMDAT support. For Rust code, which is pretty light on COMDAT usage, the impact was around 1.5%. On the up-side, some OS-level tweaks were made that fixed performance issues when the output is on filesystems like EXT4. We also now cap the maximum threads at 32, which fixes scaling issues that we were hitting beyond that point due to contention on a per-inode cache lock in the Linux kernel.

You can read the full release notes here: https://github.com/wild-linker/wild/releases/tag/0.11.0

Repo: https://github.com/clickswave/crossfyre-toolchain

It's five CLI engines I've been working on since July: voyage (subdomains), doorward (ports), ambulo (content discovery), toolmark (fingerprinting) and plessor (nuclei-compatible templates). One cargo workspace, with shared crates for the ratatui dashboard, the HTTP client, the finding format and the scope guard. In a terminal you get the dashboard, piped you get NDJSON.

The bug I'd point a Rust reader at is in plessor's backoff. It eased off with d - d / 4, and once d is 3ms or less, d / 4 is 0, so the delay sat at 3ms forever. That's nothing per request, but a 300-endpoint pass sends about 22k requests, and 65 of its 95 seconds went on pacing. (d / 4).max(1) fixed it.

The hardest part was pyo3 (cfx-script embeds Python) on Linux, macOS and Windows. The prebuilt Linux binary links libpython3.11, which some distros don't ship. If you've shipped a pyo3 binary across distros, how did you handle that?

I work on this at Clickswave. There's a paid platform on top, but the repo builds on its own with cargo build --release. Apache 2.0.

Γεια σας. Είμαι φοιτητής 18 χρόνων στο ΑΠΘ και έχω αρχίσει εδώ και λίγο καιρό να ασχολούμαι με rust. Ουσιαστικά θέλω να χτίσω μια κοινότητα με ανθρώπους σαν και εμένα που ασχολούνται με τον προγραμματισμό και ιδιαίτερα με την rust(σε οποιοδήποτε επίπεδο και να είναι κάποιος δεν υπάρχει θέμα) . Έχω κάνει ένα server της πλάκας στο discord αλλά η αλήθεια είναι θέλω βοήθεια και σε αυτό είμαι λίγο boomer όσον αφορά το discord δεν ξέρω σχεδόν τίποτα.

Η ομαδική δεν θέλω να περιορίζεται απόλυτα σε προγράμματιστικους σκοπους. Είμαι ένας άνθρωπος με πολλά ενδιαφέροντα. Με λίγα λόγια ψάχνω ανθρώπους να μοιραζόμαστε απορίες,ιδέες ,προβληματισμούς ,νέα από την καθημερινότητα μας και εννοείται στην τελικη να ασχολούμαστε και με αυτήν την γλώσσα που από το όσο την έχω γνωρίσει φαίνεται πάρα πολύ ενδιαφέρουσα.

Hey everyone. I'm an 18-year-old student at Aristotle University of Thessaloniki (AUTH), and I recently started getting into Rust.

Basically, I want to build a community with people like me who are into programming and especially Rust (any skill level is totally fine, no worries). I made a basic Discord server, but to be honest, I need some help with that—I'm a bit of a "boomer" when it comes to Discord and I barely know anything.

I don't want the group to be strictly limited to programming topics. I'm a guy with many interests. In short, I'm looking for people to share questions, ideas, thoughts, everyday news, and of course, end up working with this language, which—from what I've seen so far—seems super interesting.

I have a `HashMap<Coord, Box<dyn BlockEntity>>`. During a tick I need to iterate over entities and, for each one, get a mutable reference to it while also getting immutable references to other entities in the same map.

Performance is critical here, so I want to avoid Mutex, RwLock, RefCell. Right now I use UnsafeCell. I'm rebuilding something like Minecraft's block-entity tick loop (you've probably heard of it).

I've also considered a smarter iterator that marks an entry as "taken" and returns `Option` on conflicting access — something like `(&mut elem, &mut NonGrowingHashMap)` from `HashMap::smart_values_mut()` — but I'm not sure whether such a pattern exists in the ecosystem or whether it's worth building. Are there other known patterns or approaches in Rust for dealing with this kind of access?

Full CVE: https://cvefeed.io/vuln/detail/CVE-2026-115905

Apparently in 2026 everyone has to build their own task board, usually with Docker, three services and half a GB of RAM to show a todo list. I built the opposite: a kanban board in your browser plus an MCP server, in one small Rust binary. Tell Claude Code or Codex "take the next task from kanzo" and it moves the card and comments as it works, which is more than I do.

https://github.com/emanuele-em/kanzo

I liked Vikunja but wanted zero setup. The one rule was keeping it small, which these days feels almost rebellious:

• ~5k lines total. You can read the whole thing in an afternoon
• 4.3 MB binary with SQLite inside, ~4 MB RAM idle
• starts in 3 ms, a 3,000-task board loads in 17 ms
• light on your agents too: ~800 tokens of tools, short replies
• no account, no cloud, no Docker. Syncs between machines through your own private git repo if you want
• one-line install on macOS/Linux, runs fine on a Raspberry Pi

Still early. If you've got ideas on how to make it even smaller, PRs very welcome, deleting code counts as a feature here.

I've read that in C++ you have many ways of shooting your own foot or something but there aren't any good game engines designed for Rust. I've heard of Bevy but I've heard that it's better to stick with Unity or Unreal as Bevy needs time to be at a good enough level. So the question boils down to should I learn Rust or C++?

I've been building Composure, a Rust framework for HTTP-only Discord bots. This originally was a macro-driven way to group commands and route requests automatically, but grew into what it is now when Components V2 released.

I never liked the patterns for handling interactions within components, I wanted to build something that felt more like building a typical JSX app.

This is what I came up with:

use composure::{app, command, rsx, view, command::View};

/// A card that counts its likes. The count lives in the button's custom_id.
#[view]
pub fn Card(title: String, likes: u32) -> View {
    rsx! {
        <Container>
            "## " {title.as_str()}
            <Text>"-# " {likes} " likes"</Text>
            <Row>
                <Button primary on:click:like=move |_| Card { likes: likes + 1, title }>
                    "Like"
                </Button>
                <Button url="https://discord.com/developers/docs">"Docs"</Button>
            </Row>
        </Container>
    }
}

/// Post a card
#[command]
fn card(#[option("Title")] title: String) -> Card {
    Card { title, likes: 0 }
}

#[app(handlers(card, Card))]
pub struct Bot;

The click handler is written inline next to its button. Clicking Like re-renders the message with new props. The props the handler captures (likes, title) are encoded into the button's custom_id, so the counter needs no database.

Each tag expands to a builder, and each attribute to a method on it. As a result, rustc catches a misspelled attribute or a button placed where Discord doesn't allow one, and rust-analyzer completes and documents tags and attributes as you type. Limits like 5 buttons per row are checked as well.

Modals work the same way. Each input's name matches a parameter of the submit closure, so submitted values arrive typed:

#[derive(Choice, Debug)]
pub enum Severity { Low, High }

#[view]
pub fn Report(page: String) -> ModalView {
    rsx! {
        <Modal title="Report a problem" on:submit:send={move |_ctx, what: String, severity: Severity, notify: bool| {
            Ephemeral(format!("{page}: {what} ({severity:?}, notify: {notify})"))
        }}>
            <Label text="What happened?">
                <TextInput name="what" paragraph max_len=500/>
            </Label>
            <Label text="Severity">
                <RadioGroup name="severity" options=Severity/>
            </Label>
            <Label text="Notify me">
                <Checkbox name="notify"/>
            </Label>
        </Modal>
    }
}

An input without a matching parameter, a parameter without an input, or a type the input can't produce is a compile error.

Underneath, Composure handles Interactions only, which Discord sends as signed HTTP requests. A bot needs no WebSocket and no process running 24/7: it runs on Cloudflare Workers, where you pay per request, or on any server with tokio. Other features:

• Commands are functions. Parameters become Discord options and the doc comment becomes the description, so the registered definition and the handler can't drift apart.
• ctx.defer(async |ctx| ..) for work that takes longer than Discord's 3 seconds.
• A REST client for Discord's endpoints, checked in CI against Discord's OpenAPI spec.
• A command sync CLI. Its --check mode fails CI when the commands registered on Discord are out of date.
• Each interaction takes a few microseconds, and the full example bot is about 307 KB of gzipped WASM.

If your bot needs to read every message or track presence, use serenity or twilight, because you need the gateway for that.

It's pre-1.0 (currently 0.2), so the API may still change. I'd really like feedback on the rsx! syntax and on what's missing.

• GitHub: https://github.com/BlueFrog130/composure-rs
• Guide (the Views chapter covers every tag): https://bluefrog130.github.io/composure-rs/views.html
• Templates: cargo generate --git https://github.com/BlueFrog130/composure-rs templates/cloudflare
• Discord: https://discord.com/invite/8rWjWtp3pG

I have ported this over to TypeScript as well, as the JSX patterns fit well, but it lacks the compiler-safety. https://github.com/BlueFrog130/composure-js

Ochre is a Rust voxel project I've been working on since 2021.

Open source on GitHub: https://github.com/rornic/ochre

It started as a simple Minecraft clone using Amethyst's ECS library and plain OpenGL bindings through glium, but I migrated it to Bevy a while back to make the most of the ecosystem.

Some cool features:

• Terrain streams in around the player and falls back to coarser LOD meshes with a cross-fade, so the curved horizon reaches 16km at the default render distance, increasing to 32km with altitude.
• 64 km x 64 km deterministic world. Droplet erosion carves valleys, hydrology routes rivers to lakes and the sea, and a climate pass sets temperature and moisture.
• A day and night cycle with sun, moon and stars, atmospheric scattering, volumetric clouds and weather including rain.

Built and tested on an aging RTX 2060 which currently begs for mercy at 1440p on 32km render distances. Ryzen 7 9800X3D crunches through chunk generation and meshing in an instant. Would love to see how this melts more modern GPUs!

I've found using a pure Rust engine like Bevy to be a great accelerator for AI coding harnesses too, really easy to do performance A/B tests on new engine features.

Notes, code and benchmark: https://github.com/VAHPEM/rust-deobf

I've been studying how Rust string-obfuscation crates behave once compiled, mostly in the context of malware analysis, and wanted to share a few observations.

- In the tested obfstr and litcrypt cases, the original string literals don't appear as plaintext in the binary, but the decoding logic remains executable. Emulating the relevant routines is enough to recover the strings, even with opt-level = "z", fat LTO, and panic = "abort".

- In my tested binaries, panic::Location information remained available after stripping. When source paths are preserved, paths such as .cargo/registry/src/.../<crate>-<version>/... can reveal exact third-party crate versions. Compiler-related source paths may also provide clues about the Rust toolchain.

- A small litcrypt quirk: lc!(r"...") keeps a leading `"` in the decrypted value, so the program really builds `"C:\...`.

If you maintain a Rust string-obfuscation crate, or have tested one that behaves differently, I'd be interested in comparing results.

Hey everyone, are there any GitHub repos or templates that help set up an offline-first Rust environment? I need to cache all toolchains and vendor dependencies while online so that building and deploying works completely air-gapped, like during a prolonged wartime internet blackout in Iran.

If you have a personal example of a situation where you wanted to go with rust but went back to js I would appreciate that too.

I find it interesting when Rust projects share detailed technical reports instead of just announcing new features. Seeing the reasoning behind architectural decisions, performance improvements, and engineering trade-offs can be just as valuable as the final results.

For people who follow Rust projects closely, what makes you pay attention to one in the long term? Is it the quality of the engineering write-ups, the problems the project is solving, its open-source community, or the way it pushes Rust's capabilities?

I'd love recommendations for projects that regularly share useful technical updates, especially ones that are interesting to learn from even if you're not planning to contribute.

Two months ago I posted here about running rustc, cargo and lld as WebAssembly on an iPad. I said I had no rust-analyzer: I had compiled it to wasm and measured it, and the proc-macro and std source costs looked too high for a tablet. It's in the app now, with a catch: it only runs when the device has the memory for it. The editor is also native now; it was Monaco in a web view then.

The screenshot is the editor with the debugger paused at a breakpoint.

What I use rust-analyzer for first is color.

Before rust-analyzer is warm, the editor is colored by a tree-sitter highlighter, and the status line says "basic colours". When rust-analyzer finishes indexing, its semantic tokens replace those colors. Both servers are translated into one vocabulary, so a word whose category doesn't change keeps its color. What rust-analyzer adds is the distinctions a grammar can't make: a trait versus a struct versus an enum versus a type alias, a method versus a free function, a macro_rules macro versus a proc-macro, value parameters, lifetimes, Self, the mutable modifier, items from a dependency crate, and unresolved references.

The memory rule, since that's the interesting part. The default is "Auto":

- device with 6 GB or more: full rust-analyzer when there is headroom, otherwise a reduced mode

- device with 4 to 6 GB: the reduced mode when there is headroom, otherwise off

- device with under 4 GB: off

"Headroom" means no memory-pressure warning and more than 2000 MB available. Pressure steps the level down one notch, and a warning expires after 45 seconds of quiet. During a build, if available memory drops below 2000 MB, rust-analyzer is released so rustc has the memory, and in Auto it comes back when the build ends (it retries every 5 seconds for about two minutes). If rust-analyzer fails to start, it is retried after 5, 20 and 60 seconds. You can also force it on, off, or to the reduced mode in settings.

The reduced mode drops the Cargo dependency graph, the crate index and code lens, the chaining, closure and borrow hints (type and parameter hints stay), and files over 200 KB. The cost is real: without the graph, crates show up as "missing reference". The graph itself needs a device with at least 7000 MB and at least 3000 MB available, and the editor doesn't attempt one for projects over 120 crates. Proc-macros only expand when a compiled reactor for that crate is already cached, otherwise the crate stays unexpanded for that graph load.

Numbers, with a caveat: I don't have an on-device warm-up time I trust yet. These are from running the same wasm under Node on a Mac:

- warm-up in a single-file project: 1.3 to 2.7 s, heap about 220 MB

- a small project with a couple of crates: about 300 MB, 1.9 to 2.2 s

- a project with 93 crates: about 500 MB, 3.4 s (about 3 MB per crate)

- semantic tokens for a 3,100-line file: 128 to 213 ms cold, 36 to 53 ms warm

- the rust-analyzer wasm is about 16 MB, built from the 2026-08-31 tag with Rust 1.98.0 for wasm32-wasip1, optimized with wasm-opt -O3

I also added GitHub Copilot after people asked for it in that thread. It uses your own subscription.

Same disclosure as before: it's a paid, closed-source app with a free tier for single files, I'm the author, and it's in TestFlight beta: https://testflight.apple.com/join/4Yaujqd5

I'd like to know where it falls over: crates that fail to build, rust-analyzer colors or diagnostics that differ from a desktop, and any device where the memory rule picks the wrong level. I'll be traveling for most of November, so replies may be slow.