3 ms·

> "An inconvenient truth about async Rust is that libraries still need to be written against individual runtimes." In general Rust has tried hard to improve on

by pavlov 3y ago

> "An inconvenient truth about async Rust is that libraries still need to be written against individual runtimes." In general Rust has tried hard to improve on the developer experience of C++ by providing more safety in the language and better defaults in the standard library. So it's interesting that both languages have now ended up in a similar same place for async. (C++20 coroutines finally enable sensible async libraries, but code written against a higher-level library isn't easily portable to another one even though both are using the low-level language coro primitives.) > "Freely after Stroustup: Inside Rust, there is a smaller, simpler language that is waiting to get out. It is this language that most Rust code should be written in." Maybe there's a Meta-Stroustrup's Law in effect: "Every successful language eventually becomes one which contains a smaller, simpler language struggling to get out." It happened to C++ and Java and JavaScript, now Rust seems to be reaching that point.

Ygg2 3y ago
In practice it's not hard to make your app support async and sync, simultaneously. Quick XML does it via macros, which looks very similar to keyword generics. Edit: > Maybe there's a Meta-Stroustrup's Law in effect: > "Every successful language eventually becomes one which contains a smaller, simpler language struggling to get out." Corollary: every simple subset of language contains missing features dearly needed by someone else.
- 0xDEADFED5 3y ago
  quick-xml is great
- soerxpso 3y ago
  > Corollary: every simple subset of language contains missing features dearly needed by someone else. This could even be said about larger languages, though. If Rust committed to pleasing everyone, it would have an optional garbage collector, lifetime annotations would be optional, and there would be an interpreted runtime available as an alternative to the compiler. Those are features that some people do dearly need for some tasks. There's a point where you have to stop and put limits on what the language is actually for and what it's not. It seems to me that much of the push to add async/await in the first place was from people who really should have been using Go, Java, or Node, but wanted Rust to be their "everything language." It's okay to say, "This language is for writing performant systems applications. It's not a fullstack language for writing a webapp."

by pavlov 3y ago

Ygg2 3y ago

In practice it's not hard to make your app support async and sync, simultaneously. Quick XML does it via macros, which looks very similar to keyword generics. Edit: > Maybe there's a Meta-Stroustrup's Law in effect: > "Every successful language eventually becomes one which contains a smaller, simpler language struggling to get out." Corollary: every simple subset of language contains missing features dearly needed by someone else.

0xDEADFED5 3y ago
quick-xml is great
soerxpso 3y ago
> Corollary: every simple subset of language contains missing features dearly needed by someone else. This could even be said about larger languages, though. If Rust committed to pleasing everyone, it would have an optional garbage collector, lifetime annotations would be optional, and there would be an interpreted runtime available as an alternative to the compiler. Those are features that some people do dearly need for some tasks. There's a point where you have to stop and put limits on what the language is actually for and what it's not. It seems to me that much of the push to add async/await in the first place was from people who really should have been using Go, Java, or Node, but wanted Rust to be their "everything language." It's okay to say, "This language is for writing performant systems applications. It's not a fullstack language for writing a webapp."