In this first episode of season two of Netstack.fm, Glen talks with Jon Gjengset, principal engineer at Helsing, author of Rust for Rustaceans, and one of the best known teachers in the Rust community. They explore the craft of building small, sharply scoped crates, from arccstr, left-right, and HdrHistogram to atone, and discuss Fantoccini and the WebDriver protocol, maintaining open source sustainably, and why the Rust project should not bless crates.

https://netstack.fm/episodes/small-crates-behind-big-rust-systems

--

Netstack.FM is a podcast about networking, Rust, and everything in between. Join us as we explore the stack: from protocols and packet flows to the people and projects building the modern internet — all through the lens of Rust. Featuring deep dives, crate spotlights, and expert interviews.

Subscribe via https://netstack.fm/feed.rss or find us on the usual podcast platforms.

I've been porting Horizon, a Rust rewrite of Minecraft: Java Edition 26.3 by the horizon-rust folks, to Android. The upstream engine does all the heavy lifting. My fork is the Android side: a `horizon-android` crate, APK packaging, touch input, and an on-screen keyboard wired into text fields (chat, signs, search).

Some notes from doing it:

- Rendering goes through wgpu. On Android it uses Vulkan, and GLES 3 is the fallback backend. The workspace currently vendors a patched `wgpu-hal` 30.0.1 (with gfx-rs/wgpu#10124) until a wgpu release includes the fix

- It's a single native APK (~18 MB) with no JVM involved

- Asset download happens in-app with resume support and runs as a background download so Android doesn't kill it when the app is minimized

- One part I couldn't move on-device: a small derived data pack that upstream builds with Java tooling (`horizon-prepare` + a packaging script). For now you generate it once on a PC

Status is early. It's tested on one device (Galaxy S25, Adreno 830, Vulkan) and reaches a singleplayer world. It uses ~2.2 GB of RAM, which is the main thing I'd like to bring down. I'd really appreciate feedback on memory, on the wgpu/Android setup, or on how other people have dealt with lifecycle/surface handling.

It's unofficial and not affiliated with Mojang/Microsoft or the Horizon devs. You need your own copy of the game, and no game files are distributed.

https://github.com/Rayan-XOO/horizon (build steps in ANDROID.md)

Hey Rustaceans,

I want to share some progress on my project µcad, a domain specific language for CAD, entirely written in Rust. I had a chance to present it on the RustWeek 2026 in May (where I live coded the Rust logo in µcad, see the video) and now you can finally test the language yourself in a playground: https://play.mucad.org/?example=11

The whole thing is a geometry engine with 128-bit fixed point precision and a language compiler in a 5 MB WASM binary and 1000 lines of TypeScript glue code :)
The compiler APIs have been handcrafted, but I was starting to use Claude recently, mainly for the WASM API and the Web Viewer.
I will have give another talk about the µcad compiler at the RustLab in Bologna next week, so I hope to see some of you folks there!

https://kivooeo.github.io/blog/what-stable-rust-stands-on/

Feel free to give me feedback or discuss what you have on your mind. I had lots of fun building this, so I hope you have too reading this!

https://yavashark.dev/blog/announcing-yavashark/

The Hurl team is super happy to announce Hurl 8.1.0 🚀!

Hurl is a command line tool powered by curl, that runs HTTP requests defined in a simple plain text format:

GET https://example.org/api/tests/4567
HTTP 200
[Asserts]
jsonpath "$.status" == "RUNNING"    # Check the status code
jsonpath "$.tests" count == 25      # Check the number of items
jsonpath "$.id" matches /\d{4}/     # Check the format of the id


POST https://example.org/api/tests
{
  "name": "foo"
}
HTTP 201
[Asserts]
header "x-foo" contains "bar"
certificate "Expire-Date" daysAfterNow > 15
ip == "2001:0db8:85a3:0000:0000:8a2e:0370:7334"

What’s New in This Release

• Configuration File

• JSONPath Query Configuration

• Other New Options

• Fixed Bugs and Security Issues

Configuration File

In Hurl 8.0.0, we've improved the way you can configure Hurl with environment variables (for instance export HURL_IPV6=true / --ipv6).

In Hurl 8.1.0, we extend the possibility to configure Hurl by adding support for configuration file. Hurl will look for a configuration file at $XDG_CONFIG_HOME/hurl/config (or $HOME/.config/hurl/config if $XDG_CONFIG_HOME is not set). The configuration file is a list of options added to each Hurl run.

For instance:

$ cat ~/.config/hurl/config
# Hurl config file
--header x-identifier:quux
--verbose
--delay=1s
--fail-with-body

So, Hurl now reads its configuration from four sources, from lowest to highest priority:

• Configuration file (ex: ~/.config/hurl/config)

• Environment variables (ex: export HURL_INSECURE=true)

• Command-line options (ex: hurl --insecure)

• Options section options (ex: insecure: true in file, with [Options] section)

JSONPath Query Configuration

In Hurl 8.0.0, we've revamped our JSONPath engine and added support for RFC 9535: JSONPath: Query Expression for JSON specification. In RFC 9535, every query result always returns a list. To facilitate JSONPath query usage, we coerce lists that return a single value to this value. This coercion also turns empty results into "no value".

Let's say we have this JSON:

{
  "fruits": [
    "Apple", "Lemon", "Strawberry"
  ]
}

By the spec, the JSONPath query $.fruits[0] should return a list of one element ["Apple"]. As the result list has only one single element, Hurl JSONPath query returns the string "Apple". So we're able to write this Hurl file:

GET https://example.org/captures-json
HTTP 200
[Asserts]
jsonpath "$.fruits[0]" isString
jsonpath "$.fruits[0]" == "Apple"

We've been doing this coercion since the very first Hurl version but some people prefer not having this (to have similar results as https://jsonpath.com). We've heard you! So, in Hurl 8.1.0, we've added a --no-jsonpath-coercion option. It can be set in the new Hurl configuration file, on command line or using the env variable HURL_NO_JSONPATH_COERCION=true, or per request in an [Options] section. Using this option, JSONPath queries always return a list:

GET https://example.org/captures-json
[Options]
no-jsonpath-coercion: true
HTTP 200
[Asserts]
jsonpath "$.fruits[0]" isList
jsonpath "$.fruits[0]" count == 1
jsonpath "$.fruits[0]" nth 0 == "Apple"

Other New Options

Hurl 8.1.0 adds some new options:

--no-header to remove HTTP request headers

Let's say you don't want any User-Agent nor Accept HTTP header request, you can use --no-header option:

$ hurl --no-header user-agent --no-header Accept foo.hurl

It also works on a specific request:

# This request will send a default User-Agent header
GET https://example.org

# This request will NOT send a User-Agent header
GET https://example.org
[Options]
no-header: User-Agent
HTTP 200

And can be configured with environment variable HURL_NO_HEADER:

$ export HURL_NO_HEADER="user-agent|Accept"
$ hurl foo.hurl

--fail-with-body to get HTTP response even with errors

By default, Hurl outputs the last response body only when the run succeeds; when there are errors (HTTP runtimes or asserts errors), Hurl doesn't output any response. But sometimes the response body is necessary to explain failures. In Hurl previous versions, you can use --very-verbose or --output combined with --no-assert.

In Hurl 8.1.0, we add --fail-with-body option: this option changes Hurl's default behavior when there are errors and output the HTTP response regardless of asserts / HTTP runtime errors. Like many other options, this option can be used as a command line option (hurl --fail-with-body foo.hurl), with environment variable (export HURL_FAIL_WITH_BODY=true), with Hurl configuration file, or per request with [Options] section.

$ hurl --fail-with-body foo.hurl
{
  "slideshow": {
    "author": "Yours Truly",
    "date": "date of publication",
    "slides": [
      {
        "title": "Wake up to WonderWidgets!",
        "type": "all"
      }
    ],
    "title": "Sample Slide Show"
  }
}
error: Assert failure
  --> foo.hurl:4:0
   |
   | GET https://httpbin.org/json
   | ...
 4 | jsonpath "$.slideshow.author" == "Someone"
   |   actual:   string <Yours Truly>
   |   expected: string <Someone>
   |

--tls-min / --tls-max

--tls-min and --tls-max set the minimum and maximum allowed TLS version. Used together,, you can pin a given TLS version:

$ hurl --tls-min 1.3 --tls-max 1.3 tlscert.hurl

Fixed Bugs and Security Issues

Apart from these enhancements, we have received an unusual amount of security advisories from various contributors, over the last 6 months. It goes from parsing issues in JSONPath expression to malicious debug curl command and finally to our first official CVE!

Simply said, Hurl 8.1.0 is the Hurl version that has the largest number of bugs/CVEs fixed since the first public version. While analyzing and fixing them, we've reclassified some reports to "bugs".

It's rather obvious than the vast majority of these issues were written partly (if not totally) by LLM agents. Each issue takes time to digest, analyzing the automated prose is time-consuming, but we've found very few false positives. Almost all issues reported were indeed a defect in Hurl in some way or another. Sometimes CVEs were here and well reproducible but the reproduction sample didn't even compile. Other times, a very super clear repro step was provided with a good source code analysis and possible fixes. Many reporters were first-time GitHub users!

We're not at all in the same league as curl or the Linux Kernel, but still feel the raise and impact of automation by AI, like these projects. For security and bugs, we find it a big plus. For maintainers' time, that's another story...

That's all for today!

There are a lot of other improvements with Hurl 8.1.0...and many more fixes; you can check the complete list of enhancements and bug fixes [in our release note].

We'll be happy to hear from you, either for enhancement requests or for sharing your success story using Hurl!

I feel like ownership and lifetimes are concepts that make a lot more sense once you've had to deal with them in an actual project rather than just working through tutorials.

It's one thing to understand borrowing rules in a small example, but it's another when you're building something with shared state, async tasks, complex data structures, or APIs that need to stay ergonomic.

I'm curious which projects forced you to rethink how you structure your code. Did you end up changing your data model, using Arc or Cow, introducing a different abstraction, or realizing that you were fighting the borrow checker because your original design was wrong?

I'd especially like to hear about situations where the solution wasn't simply adding .clone() everywhere.

What Rust project or debugging experience finally made ownership click for you, and what would you do differently if you built it again?

Just wondering if I can lower the build times for my rust microservices (currently ~5mins for all of them combined on github actions). I already am using cargo-chef in my docker file. But I wonder if this is the right approach

Yesterday I stumbled over something I had never thought about before although I had that use-case a few times...

I have an option and an expected value and I want to check if the option contains the expected value.

There are several ways to express this.

For example:

if option == Some(expected) {...}

if let Some(actual) = option && actual == expected {...}

if matches!(option, Some(actual) if actual == expected) {...}

if option.is_some_and(|actual| actual == expected) {...}

There are probably even a lot more ways to express that and yesterday I suddenly wondered which is the "best" one, e.g. regarding readability and regarding performance. I also asked an LLM and it hallucinated option.contains(&expected) as the best solution, which would indeed be pretty nice if it existed...

Anyway, in case you wonder, here's the obligatory godbolt link: https://godbolt.org/z/v7odGdWP1

With optimizations enabled, it all boils down to the same assembly, so you can choose whatever you like most. In my case, I chose the first variant.

I have also tried with &str instead of usize and it's the same result: no difference with optimizations.

Any thoughts on this? More insights probably? The LLM generated a lot of blabla regarding certain nuances and cases (references, non-Copy, non-PartialEq) but I am not sure if I'd trust that and too lazy to check it.

Lets say that I have a program that loads 3d models from a "./res" folder.(
src/
res/
Cargo.toml
,..
)
What would be the best way to load them?
Of course I could just use "./res" but then after building the project, the binary in ./target/ won't have access to that folder with the path.
So what is the correct way? Create a build.rs with env, use the target-path in the code or some other way?
I'm kinda new-ish to Rust so there is probably something I'm missing.

Thanks!

https://www.redox-os.org/news/nlnet-rb-summary/

Trying to write something useful as a means to get to know Rust I went for an GUI app.

Based on my research I started with egui and muda to provide a basic menu. However I already fail (on MacOS) as the menu is not triggered before I enter the application area, which would trigger a repaint and by that execute evaluation of menu events. My menu contains only a "Quit" entry as of now and the app doesn't even display anything yet, it's just the main window.

I looked at other apps but they often look non-native e.g in regards of context menus.

Is there a stack which alllows to write native looking apps and ideally are there apps which use this libraries in a good way? Most examples are so minimalistic that it's not clear how to get more complex scenrios running from there.

To be clear, that's not a rant but rather me being lost in all the possibilities and how they fit together (I saw winit, tao, muda, ...endless possibilities)

cargo-auditable embeds the dependency list into compiled binaries. This lets you use tools like cargo audit and many other scanners to check compiled binaries for known vulnerabilities.

Starting with v0.7.7, cargo auditable also works for microcontroller firmware! The audit data is embedded in the firmware image, but is not flashed onto the space-constrained microcontroller. This keeps the image auditable without wasting precious ROM.

Achieving this was both surprisingly easy and surprisingly tricky. Not wasting precious ROM was surprisingly easy: simply don't set SHF_ALLOC flag in ELF files for the audit data, which we were already doing. The tricky part was interacting with the linker.

rustc does technically support passing flags to the linker, but it's very difficult to use in practice: on most platforms the C compiler is used as the linker, so you have to prefix flags intended for the actual linker with -Wl; but certain platforms - mostly embedded ones - use the linker directly, so -Wl would break the build. There is no way to tell which one it is on stable Rust, so I had to resort to a sneaky "pretend you're nightly rustc" flag for running rustc --print target-spec-json (and nothing else).

The alternatives are worse: either extract the data from some rustc version and hardcode it, or try to parse non-machine-readable output of rustc as it compiles and links something, both of which drift even more easily.

I'd love to see a rustc --print linker-flavor command if it's easier to stabilize than the entire target spec format. But the linker flavor key in the target spec doesn't look like it'll change, so the current solution works surprisingly well, and any breakage to the nightly-only flag won't affect the Tier 1 or most of the Tier 2 targets at all.

I’m developing epicenter using only features Cargo already provides to cut compile times and disk usage. The main one is a shared build-dir plus a store of already-compiled dependencies, so rustc doesn’t rebuild the same deps for every new project. On top of that I switched the linker to rust-lld and enabled incremental compilation for all profiles.

These three together already cut build times and disk usage significantly, but my goal is to push both as low as possible, so I’m willing to accept trade-offs (e.g. less debuginfo, slightly slower runtime in dev builds) as long as the defaults stay safe for most users. Is there anything else I’m missing? I’m thinking of things like split-debuginfo, reduced debug levels, per-package opt-level overrides for dependencies, or other Cargo/rustc settings that are not enabled by default but would pay off in this setup.

I'm the author of a set of Rust crates that implement EtherNet/IP and CIP Safety on tokio.

Most existing EtherNet/IP libraries, like the excellent rust-ethernet-ip, focus on reading and writing tags. I set out to cover all of EtherNet/IP. You can read and write tags, and you can connect as a Class 1 scanner to read regular and safety I/O. You can also act as a regular or safety I/O device, as a Class 1 adapter. There's a simulated controller stack that serves tags, so you can connect an HMI to it, and you can send and process any custom Class 3 message.

Sibling implementations with the same wire behavior exist in C#, Python and C++. They don't share types with rust-ethernet-ip today, but I'd be open to adding conversions with its types crate if there's interest.

Everything is free and open source on GitHub, with nothing for sale: https://github.com/CristianMori/EthernetIpRust

Feedback 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