4 ms·
I like the approach that steps back and looks at usage scenarios. Not everything has to be solved by changing the language itself; it may be a matter of better
by pornel 6y ago
I like the approach that steps back and looks at usage scenarios. Not everything has to be solved by changing the language itself; it may be a matter of better tooling or teaching materials.
For example, the recent "async doesn't work" blog post was centered around confusion between `fn()` pointer and `Fn()` trait, and misuse of temporary `&mut` where `Arc<Mutex>` was required. If the compiler was smart enough to suggest these fixes, then the whole blog post could have been "async works fine, just needed a couple of lines changed as indicated".
- wahern 6y agoThat wasn't confusion, that was the point. If there's confusion it's in people having different conceptions of what async language constructs should provide, which color their criticisms and rationales.