Ah, now you’re talking my language. 🙃

Well, for one you’re forgetting the main():

fn main() {
    println!("Hello, World!");
}

Then Rust already has syntactic sugar to omit the Unit-return-type, so it’s really:

fn main() -> () {
    println!("Hello, World!");
}

And then Rust decided to make println!() blocking. It could also look like this:

async fn main() -> () {
    println!("Hello, World!").await;
}

async is what the ' in Unison is. I guess, because it is so commonly used in Unison.

And Rust decided, if the println!() fails, then panic!(). But I can see merit in a language that can guarantee that a given function cannot terminate your program. And that would mean we’d have to at least ignore the result in Rust:

async fn main() -> () {
    let _ = println!("Hello, World!").await;
}

And like, yeah, are you seeing the parallels? It’s a handful of small design decisions that make a huge difference here.
And you can absolutely argue that Rust took the less rigorous, less consistent approach for its println!().

I do think, that’s fine. Rust doesn’t give guarantees for not terminating to begin with and so, if println!() should ever not work, I do think, it’s fine to abort mission.
And the decision to not make println!() async doesn’t affect the remaining language design. Most production codebases will practically never use println!() anyways and should someone genuinely need an async_println!(), then that can be built.

But yeah, personally, it does excite me to see that the Unison authors thought differently. Even if it’s just sheer curiosity what they do with it and whether that added consistency is nice to work with.