@5150cec1 oh, what I meant was that the framework would be sync like `iron` or the old versions of `rocket` and all endpoints would be sync. If you need async, you'd have to start a runtime, handle all futures, and return the results. No magic, no hidden runtime, very explicit. We should make running a few futures concurrently as easy as possible.
@bf55f1f1 But starting a runtime involves some overhead. Did I get it right that you would start a runtime for each request?
I am not familiar with iron though and only tried a recent version of Rocket.
About the hidden runtime: Why do you think that it is hidden? For me, it is very implicit since you annotate your main function with a tokio macro. Maybe because of the macro hiding how the runtime is launched? One can see its equivalence here: https://docs.rs/tokio/latest/tokio/attr.main.html#usage
@5150cec1 yeah, that's what I mean. Without looking into the cargo.toml, there is no way of figuring out whether it uses a single threaded or multithreaded runtime unless the annotation is more explicit than the default, which not what many people use.
@bf55f1f1 The Cargo.toml will not necessarily tell you about that if the feature "full" in Tokio was used. One needs to check where the runtime is spawned (noramally at the main function). The multithreaded version is the default. Otherwise you would see this explicit annotation:
#[tokio::main(flavor = "current_thread")]
I am sorry if I am missing something, but I don't get how the runtime that you normally start yourself (for example in Axum) is hidden.
@5150cec1 you're right. I was of the opinion that it would choose the runtime based on the activated features, which isn't the case.
Then people "just" need to know what `#[tokio::main]` does. Not that much of an issue, but still more implicit than I'd like to.
Oddbean new post about login | logout