You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the README recommends to try spaad in case one wants better ergonomics out of xtra.
Personally, I was never a big fan of spaad because I've found that it obfuscates too many things. With the upcoming release, the public API of xtra changed massively and I believe it is now in a state where it provides great control over what is happening without too much boilerplate. For example, the split_receiver functionality is only available on SendFuture which would be hidden by something like spaad.
Especially once we add #111 and async fn in traits being hopefully stable soon, the amount of boilerplate is practically zero, i.e. every line of code is intentional and not a "this library is making me write code that I don't want to write".
The text was updated successfully, but these errors were encountered:
I am not 100% sure if we should recommend it per se but it might be worth a mention. I also agree. Spaad was always a little bit of an experiment with it and I was not totally satisfied with how it turned out.
Yeah, we should definitely mention it. What irks me is that the current wording suggests that xtra is too verbose to use by itself when at least in my opinion, it definitely isn't.
I agree :) I think that macros are a little unergonomic and we should strive to improve xtra's usability outside of other macros like what was done in spaad.
At the moment, the README recommends to try
spaad
in case one wants better ergonomics out ofxtra
.Personally, I was never a big fan of
spaad
because I've found that it obfuscates too many things. With the upcoming release, the public API ofxtra
changed massively and I believe it is now in a state where it provides great control over what is happening without too much boilerplate. For example, thesplit_receiver
functionality is only available onSendFuture
which would be hidden by something likespaad
.Especially once we add #111 and
async fn
in traits being hopefully stable soon, the amount of boilerplate is practically zero, i.e. every line of code is intentional and not a "this library is making me write code that I don't want to write".The text was updated successfully, but these errors were encountered: