smol-macros

[notgull]

Greetings @smol-rs/admins,

I've created a new repository under smol-rs called smol-macros. While working with a private project, I noted that it takes a not-insignificant amount of code to create an executor and get it running. For scaffolding use, I wanted to create a way to immediately get to a working runtime. Hence, this new crate.

I wanted to post it here for review before I published it. Any thoughts on it before it goes up on crates.io?

[zeenix]

@notgull Nice! One comment:

This crate uses declarative macros rather than procedural macros, in order to avoid needing to use heavy macro dependencies.

I am not sure the benefits here are worth the cost: unusual API (people are super used to #[runtime_of_choice::main] and IMO it would be nice to provide a familiar interface. The build-time costs of using proc macros is a very general problem in Rust ecosystem and we shouldn't (again IMO) have to design APIs to workaround that.

Talking of proc macros, if we go for the proc macros it would be also nice to have the macros reexported by smol crate and have that as the recommended way to use the macros (it can be feature gated).

[notgull]

I am not sure the benefits here are worth the cost: unusual API (people are super used to #[runtime_of_choice::main] and IMO it would be nice to provide a familiar interface. The build-time costs of using proc macros is a very general problem in Rust ecosystem and we shouldn't (again IMO) have to design APIs to workaround that.

smol has always been about finding new ways to address existing problem spaces. Thus far we've gone to great lengths to avoid proc macros (see our extensive usage of pin-project-lite) and I'd like to keep it that way. Declarative macros are generally more efficient and the ergonomics are only slightly worse than proc macros. In fact, with the apply attribute, the disadvantage can be negated entirely.

Talking of proc macros, if we go for the proc macros it would be also nice to have the macros reexported by smol crate and have that as the recommended way to use the macros (it can be feature gated).

This can be done with declarative macros as well.

[zeenix]

smol has always been about finding new ways to address existing problem spaces.

Sure, I agree with that.

Thus far we've gone to great lengths to avoid proc macros (see our extensive usage of pin-project-lite) and I'd like to keep it that way. Declarative macros are generally more efficient and the ergonomics are only slightly worse than proc macros. In fact, with the apply attribute, the disadvantage can be negated entirely.

Fair enough. I'm just afraid people will see a macro named main and assume it works the same as everywhere else and then get disappointed and confused when it doesn't work. Perhaps good documentation can help with that.

[notgull]

Okay, I think that it's ready to go up.

@taiki-e Can you set up the GITHUB_TOKEN keys for the smol-macros repository? I'm not familiar enough with GitHub Actions to add it myself.

[taiki-e]

Can you set up the GITHUB_TOKEN keys for the smol-macros repository? I'm not familiar enough with GitHub Actions to add it myself.

GITHUB_TOKEN is automatically set by GitHub Actions.
https://docs.github.com/en/actions/security-guides/automatic-token-authentication