Algeon is a query engine built on Apache DataFusion that exposes NVIDIA's cuGraph, cuVS, and cuML as SQL table functions. It doesn't write its GPU kernels. Instead, it takes what NVIDIA already has and embeds it into DataFusion, so you can call those GPU operations on any arbitrary data, with filter/join/agg using plain SQL.

And why would you want that? Because GPU analytics used to require ad-hoc ETL pipelines, Python glue code, and imperative operation calls. That makes it hard to fit into a backend API service, and it isn't flexible enough for frequent exploratory iteration, adapting to different search conditions and data. Think of agents trying to answer complex questions on a datalake, which involves not only relational operations, but also graph/vector/ML analytics. They can now use declarative SQL to test their hypotheses and build the next query based on the previous response, making GPU OLAP an interactive service. Algeon can also be used as a library living inside your backend service, so your query response can be used directly within a single process, saving the transfer cost between the query engine and backend service.

I started building Algeon last year. At first, it was cuDF Rust FFI bindings that aimed to bring GPU ETL pipelines into a single backend process, and it worked very well. Then I realized it might be possible to move GPU data science workloads into an OLAP query engine, since the NVIDIA RAPIDS ecosystem and DataFusion are mature.

For use cases, architecture design, benchmarks, and more, feel free to check out, any feedback is welcome!

• https://algeon.dev/
• https://github.com/algeon-dev/algeon

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:

shell $ 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!

So, i made this project after completing the rust book and learning axum and i didn't even knew about IAM before making this but now i know so it's an

IAM Platform

learned so many things like how to handle permission management and about IAM and about strongly Session Management and One main thing but not the least RBAC.

github link :- https://github.com/Halloloid/iam_platform

These are Features it have use it if you want to use it for your project i know it not big though
and can check the architecture and design desision i took in the https://github.com/Halloloid/iam_platform/blob/main/DESIGN.md

Here are the features it has:

• User registration and login
• Bcrypt password hashing
• JWT access tokens
• Refresh-token rotation
• Logout and device-based session management
• Organizations and organization membership
• Organization-scoped roles and permissions
• Scoped API keys for service-to-service access
• User and organization audit logs
• Permission and ownership checks for protected resources
• Cursor-based pagination for unbounded collections
• Dual authentication JWT for users, API keys for service-to-service access
• Bootstrap transaction org creation atomically assigns Owner role and all permissions
• Soft deletes for users, organizations, and API keys

We run Shieldify, a small European L7 DDoS protection service. Until 18 October our edge ran on OpenResty. Now it's our own reverse proxy in Rust, working together with an XDP program in the network driver. In October it took two HTTP/2 floods, the larger at about a million requests a second from roughly 889,000 addresses. We wrote up where those packets went:

https://shieldify.ee/research/where-a-flood-goes/

Some notes on the Rust side, since that's what this sub cares about:

• Stack: tokio (multi-threaded, work-stealing), hyper 1 and h2, rustls with the aws-lc-rs provider.
• Why we left OpenResty: nginx workers share state through lock-guarded shared-memory dictionaries. Under a flood every request touched that state and the workers waited on each other. One process with its state in thread-safe structures removed that.
• Why not Pingora: we studied it closely and still use it as a reference. But it's pre-1.0 with breaking changes in most releases, its HTTP/1 parsing is permissive by design to tolerate odd origins (at the very front we wanted the strictest parser we could get), and per-handshake certificate selection needs OpenSSL or BoringSSL, while we wanted rustls.
• Edge to XDP: the edge writes its verdicts straight into BPF maps that the XDP program reads, so a decision made on an HTTP/2 stream reaches the driver without a helper process in between.
• The WAF (OWASP CRS through a C library) runs on its own fixed pool of OS threads, so CPU-heavy inspection never blocks the I/O runtime.
• No GC pauses in the middle of a flood, and memory safety in the code that parses everything the internet sends, were the other two reasons for Rust.

Happy to answer questions about the Rust parts. I'll stay away from detection specifics, for obvious reasons.

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?

Hey everyone!

My team and I recently published a paper called "Rust Without Shortcuts: What Safety Actually Costs."

We compared 10 programming languages across 14 different workloads to better understand Rust's performance and the cost of memory safety.
I'd really appreciate any feedback! (What you liked, hated and need to be improved for future versions). Thanks!

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.

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

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?

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++?

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.