1. 11
  1. 2

    I completely agree with all the points the author makes in the article!

    (Perhaps except the one regarding HTTP in the core library… In fact there are things in there I would see extracted, especially those related to the OS, like net, process, thread, etc. Just like there are multiple crates handling cryptography, so could there be multiple crates handling sockets… The standard library should handle mainly “core language” constructs, and perhaps basic data-structures.)

    I found the one about async friendliness especially true, because I’ve also tried to wrap my head around hyper (for example to add TLS support to the server), and after 6 months since writing that code I don’t understand what happens in there… The level of complexity, trait-here, pin-this, box-that, poll-there, goes beyond my pain threshold…

    Also, I must second the observation about Go’s error handling! If there were one feature of Go I would trade generics plus goroutines, it would be error handling… Either you litter your code with panic (err) or if err != nil { return 0, "", false, err } (and hope you don’t ever change the return type of that function)…

    1. 1

      Even or maybe exactly because they are somewhat repetitive, these subjective reports are super helpful.

      Also push back on using too many traits is important so that API designers try to simplify things where possible.

      When I hear complaints about dynamic dispatch in Rust, I wonder if it is about

      1. “inconvenience” of Boxing or similar as mentioned in the article,
      2. restrictions on what methods can be used in dynamic dispatch and object safety in general,
      3. the overhead of dynamic dispatch (which I’d suspect is rarely the case),
      4. the overhead of allocation.