3 ms·

> First, the syntax. It’s ugly. TO MY EYES! Beauty is in the eye of the beholder, you can't please everyone and you should not exceed your weirdness budget[1].

> First, the syntax. It’s ugly. TO MY EYES! Beauty is in the eye of the beholder, you can't please everyone and you should not exceed your weirdness budget[1]. The decision to please the C++ crowd so much (mainly manifested in later syntax related decisions) would not have been my preference, but it makes sense and there could have been worse decisions. > Second, Third, Fourth, Fifth I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. > Sixth, Rust doesn’t go far enough in static analysis. Rust had a chance to go much further, and the team blew it. I am not qualified to judge that, but I am curious of other opinions. > Seventh, Rust compile times are a joke True, but this is actively tackled on multiple fronts. One is cranelift, which I find highly fascinating. [1] https://steveklabnik.com/writing/the-language-strangeness-budget https://steveklabnik.com/writing/the-language-strangeness-bu...

anonymoushn 2y ago
> I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. No, this is a language design issue. In Lua or Zig the easy way to write a library that speaks websockets produces a library that works with synchronous or asynchronous i/o and with the user's choice of read and write primitives. In Rust, after many years of unnecessary suffering, we finally have the ability to ship one library that can use either kind of i/o.... unless the user wants to use both in the same workspace, in which case they are screwed. You may enjoy this tale of a user trying to get Rust to do what Lua and Zig do by default, for a single library: https://nullderef.com/blog/rust-async-sync/ https://nullderef.com/blog/rust-async-sync/
- weinzierl 2y ago
  This is being worked on: https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...
  - anonymoushn 2y ago
    This looks great! The example in the linked post directly addresses the obvious follow-up of "well, what about for functions that use traits that are currently divided into two or more flavors?". I hope it progresses to an RFC and code sometime!

anonymoushn 2y ago

> I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. No, this is a language design issue. In Lua or Zig the easy way to write a library that speaks websockets produces a library that works with synchronous or asynchronous i/o and with the user's choice of read and write primitives. In Rust, after many years of unnecessary suffering, we finally have the ability to ship one library that can use either kind of i/o.... unless the user wants to use both in the same workspace, in which case they are screwed. You may enjoy this tale of a user trying to get Rust to do what Lua and Zig do by default, for a single library: https://nullderef.com/blog/rust-async-sync/ https://nullderef.com/blog/rust-async-sync/

weinzierl 2y ago
This is being worked on: https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...
- anonymoushn 2y ago
  This looks great! The example in the linked post directly addresses the obvious follow-up of "well, what about for functions that use traits that are currently divided into two or more flavors?". I hope it progresses to an RFC and code sometime!