2 Likes
I understand this video a little differently. It isn’t async and await that are difficult painful so much as trying to use them while also using non-async code.
I watched the video over 3 days, but a project I work on does something like this and it doesn’t seem quite as painful as they make it out to be. IIRC (I’m on another project at the moment) the synchronous api basically wrap calls to the asynchronous api by spawning a blocking tokio thread and using async in there. It’s relatively easy and there’s no code duplication.
Caveats:
- We do feature-flag it, so that cargo builds separate products for synchronous and asynchronous usage.
- I’ve implemented some of the API (on both the synchronous and asynchronous ends), but I didn’t design the feature flagging. What looks relatively easy to me may have been a bear to design.
- I also don’t like how
asynctaints everything it touches. That’s one reason I asked about this in Ada a while back. - I think there was another caveat, but I’ve forgotten it.
1 Like
You understand it far better than I. I guess he is using the part about trying not to use Tokio to create a dramatic title. Perhaps I should be more thankful for Adas standard runtime? 
1 Like
Though Rust projects seem to happily create ip stacks without Tokio or runtime support. Whilst Ada stacks tend to depend on e.g. protected objects except for the Spark one that only supports ipv4.
I happened across another view of theprimagens, which is that Rust doesn’t scale because if you “throw in an extra lifetime” then you have to modify a ton of code.
1 Like
Exactly the same reason for loglog games (and plenty of others I’ve seen) dropping rust.
While I don’t doubt the reasons why those individuals reported their displeasure with Rust, let’s not forget there are far more success stories. It would be interesting to know how what they would think if they tried Ada.
4 Likes