What's missing from Hurl is snapshot testing. After using `insta` for testing APIs, I cannot go back.

Is this https://insta.rs/? What are the benefits you've found with snapshot testing?

Greatly reduced boilerplate. Diffing snapshots and providing previews to accept or reject changes is also more robust and user friendly.

What's your value proposition for snapshots and why can't that already be fulfilled with full body checks? https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file...

Snapshots diff current with previous output and I only have to accept or reject the diff. I don't have to write the expected response myself. Snapshots can also stub out parts of the response that are not determistic.

> Snapshots can also stub out parts of the response that are not determistic.

TIL! The way I knew to do it was to have a mock implementation that behaved like the real thing, expect for data/time/uuids/..., where there was just a placeholder. Snapshot tests being able to "mask" those non-deterministic parts sounds cool!

tbh, that seems pretty close to what I would call snapshot testing already. What people usually do with it is using it for more broadly compared to API testing (for example, I currently use it to test snapshots of a TUI application I am developing) - i.e. you can use it whenever your test is of the form "I have something that I can print in some way and that should look the same until I explicitely want it to look differently in the future". There are a bit more bells and wizzles - For example, it is nice that one does not have to write the initial snapshots oneself. You write the test, execute, it creates the resulting file, then you review and commit that - handy little workflow!

We are working on snapshot testing for Kreya, expected to come in August. You might want to check it out :)

Rewriting could also make sense if there is a chance to improve the architecture based on the experience with the existing codebase. Something that would otherwise be impossible to even consider.

consistency between platforms

"really should be" ?

"in C# or Java" ?

where do you even base these claims? Do you know what C# and Java threads have that Rust doesn't? data races. And don't get me stated on the biggest paradigm failure that is OOP.

Projects I've seen at work. Projects posted on Hacker News. Data races aren't usually an issue for backend services, and modern Java/C# is multi-paradigm.

> Data races aren't usually an issue for backend services

I beg to differ unless all your logic is in the database with strong isolation guarantees.

Speaking of C# for backends that are using EF actively, I bet there are bugs in pretty much all of them caused by incorrect applications of optimistic concurrency.

Both have a garbage collection though that lead to higher developer productivity than compared to rust's affine types.

> higher developer productivity

Where have you been the past 5 years? Rust developers are insanely productive.

Can we put this myth to rest already? Rust being an "unproductive language" is thoroughly dis-proven.

There are domains where C# (and F#) productivity stems from similar reasons why writing a game in something that isn't Rust might be more productive without even sacrificing performance (or, at least, not to the drastic extent).

I can give you an example:

    var number = 0;
    var delay = Task.Delay(1000);

    for (var i = 0; i < 10; i++)
    {
        Task.Run(() =>
        {
            while (!delay.IsCompleted)
            {
                Interlocked.Increment(ref number);
            }
        });
    }

    await delay;

How would you write this idiomatically in Rust without using unsafe?

To avoid misunderstanding, I think Rust is a great language and even if you are a C# developer who does not plan to actively use it, learning Rust is of great benefit still because it forces you to tackle the concepts that implicitly underpin C#/F# in an explicit way.

There's a few things here that make this hard in Rust:

First, the main controller may panic and die, leaving all those tasks still running; while they run, they still access the two local variables, `number` and `delay`, which are now out of scope. My best understanding is that this doesn't result in undefined behavior in C#, but it's going to be some sort of crash with unpredictable results.

I think the expectation is that tasks use all cores, so the tasks also have to be essentially Send + 'static, which kinda complicates everything in Rust. Some sort of scoped spawning would help, but that doesn't seem to be part of core Tokio.

In C#, the number variable is a simple integer, and while updating it is done safely, there's nothing that forces the programmer to use Interlocked.Read or anything like that. So the value is going to be potentially stale. In Rust, it has to be declared atomic at the start.

Despite the `await delay`, there's nothing that awaits the tasks to finish; that counter is going to continue incrementing for a while even after `await delay`, and if its value is fetched multiple times in the main task, it's going to give different results.

In C#, the increment is done in Acquire-Release mode. Given nothing waits for tasks to complete, perhaps I'd be happy with Relaxed increments and reads.

So in conclusion: I agree, but I think you're arguing against Async Rust, rather than Rust. If so, that's fair. It's pretty much universally agreed that Async Rust is difficult and not very ergonomic right now.

On the other hand, I'm happy Rust forced me to go through the issues, and now I understand the potential pitfalls and performance implications a C#-like solution would have.

Does this lead to the decision fatigue you mention in another sub-thread? It seems like it would, so I'll give you that.

For posterity, here's the Rust version I arrived at:

    let number = Arc::new(AtomicUsize::new(0));
    let finished = Arc::new(AtomicBool::new(false));

    let finished_clone = Arc::clone(&finished);
    let delay = task::spawn(async move {
        sleep(Duration::from_secs(1)).await;
        finished_clone.store(true, Ordering::Release);
    });

    for _ in 0..10 {
        let number_clone = Arc::clone(&number);
        let finished_clone = Arc::clone(&finished);

        task::spawn(async move {
            while !finished_clone.load(Ordering::Acquire) {
                number_clone.fetch_add(1, Ordering::SeqCst);
                task::yield_now().await;
            }
        });
    }
    
    delay.await.unwrap();

https://play.rust-lang.org/?version=stable&mode=debug&editio...

I am not sure what are you trying to represent with this example, but here is the exact same thing without any unsafe:

use rayon::prelude::*;

use std::time::{Instant, Duration};

use std::sync::atomic::{AtomicUsize, Ordering};

fn main() {

    let finish_at = Instant::now() + Duration::from_secs(1);

    let number = AtomicUsize::new(0);

    (0..10).into_par_iter().for_each(|_| {
        while finish_at > Instant::now() {
            number.fetch_add(1, Ordering::Relaxed);
        }
    });

}

You can make it even simpler if you would use Mutex instead of atomics. Atomics are more performant though.

> How would you write this idiomatically in Rust without using unsafe?

Channels and selects. It's trivial.

Please post a snippet.

use std::{ sync::{ Arc, atomic::{AtomicBool, AtomicUsize, Ordering}, }, time::Duration, };

fn main() { let num = Arc::new(AtomicUsize::new(0)); let finished = Arc::new(AtomicBool::new(false));

    for _ in 0..10 {
        std::thread::spawn({
            let num = num.clone();
            let finished = finished.clone();
            move || {
                while !finished.load(Ordering::SeqCst) {
                    num.fetch_add(1, Ordering::SeqCst);
                }
            }
        });
    }

    std::thread::sleep(Duration::from_millis(1000));
    finished.store(true, Ordering::SeqCst);
}

What if we want to avoid explicitly spawning threads and blocking the current one every time we do this? Task.Run does not create a new thread besides those that are already in the threadpool (which can auto-scale, sure, but you get the idea, assuming the use of Tokio here).

What you're asking for is thread parking. Use tokio for that, it's still trivial.

I was implying that yes, while it is doable, it comes at 5x cognitive cost because of micromanagement it requires. This is somewhat doctored example but the "decision fatigue" that comes with writing Rust is very real. You write C# code, like in the example above, quickly without having to ponder on how you should approach it and move on to other parts of the application while in Rust there's a good chance you will be forced to deal with it in a much stricter way. It's less so of an issue in regular code but the moment you touch async - something that .NET's task and state machine abstractions solve on your behalf you will be forced to deal with by hand. This is, obviously, a tradeoff. There is no way for .NET to use async to implement bare metal cooperative multi-tasking, while it is very real and highly impressive ability of Rust. But you don't always need that, and C# offers an ability to compete with Rust and C++ in performance in critical paths when you need to sit down and optimize it unmatched by other languages of "similar" class (e.g. Java, Go). At the end of the day, both languages have domains they are strong at. C# suffers from design decisions that it cannot walk back and subpar developer culture (and poor program architecture preferences), Rust suffers from being abrasive in some scenarios and overly ceremonious in others. But other than that both provide excellent sets of tradeoffs. In 2025, we're spoiled with choice when it comes to performant memory-safe programming languages.

To be honest this sounds like something someone inexperienced would do in any language.

If you're not comfortable in a language, then sure you ponder and pontificate and wonder about what the right approach is, but if you're experienced and familiar then you just do it plain and simple.

What you're describing is not at all a language issue, it's an issue of familiarity and competency.

It's literally not 5x the cost, it would take me 3 minutes to whip up a tokio example. I've done both. I like C# too, I totally understand why you like it so much. This is not a C# vs Rust argument for me. All I'm saying is that Rust is a productive language.

Rust is manual by design because people need to micro-manage resources. If you are experienced in it, it still takes a very little time to code your scenario.

Obviously if you don't like the manual-ness of Rust, just use something else. For what you described I'd reach for Elixir or Golang.

I was disagreeing with you that it's not easy or too difficult. Rust just takes a bit of effort and ramping up to get good at. I hated it as well to begin with.

But again -- niches. Rust serves its niche extremely well. For other niches there are other languages and runtimes.

Even when it's used by mediocre developers, which is probably more than 90% of us, myself very much included? All I've been seeing is Rust being used by very enthusiastic and/or talented developers, who will be productive in any language.

> Rust developers are insanely productive.

If your baseline is a language that is missing some features that were in standard ML, sure. If you were already using OCaml or F#, Rust doesn't make you any more productive. If you were already using Haskell or Scala, Rust's lack of HKT will actively slow you down.

Longer compile times prolong iterative programming processes and having to take care of memory management through linear types adds restrictions on how you can express code and leads to additional mental burden. This can be part of a trade-off, where you get things in return (no runtime/gc), but your typical web app I don't see much advantages.

No, that's the other end of the stick. Its en par with other languages

Well, put any language against Rust and Rustaceans would argue Rust is better than those languages so ... Silver bullet no?

If the word “Rustaceans” is actually in common use then rust loses by default.

Agreed, RustRover is by far the best IDE for Rust atm. I also use the AI Assistant which is so toned down that it's actually useful and not full of spam.

RustRover and PyCharm keep my jetbrains subscription going. The AI assistant on pandas APIs is a godsend.

The Rhai interpreter is configurable, you can choose which features of Rain will be available on the runtime. You can even disable keywords.

Just like lua?

"accidentally"

it's already happening

it’s not. it’s being presented as such. but it’s not.

What about immutable systems like Fedora Atomic?

They're great! But also still miss fundamental pieces that Nix gets right. Especially the way the build and dependency graph goes right to the root of every package, and comes together to completely describe the system you're running today.