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!

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?

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.

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/

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.

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

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

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!

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!

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

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