4 ms·

Or rather every rust project starts with cargo install tokio thiserror anyhow. If we just added what 95% of projects are using to the standard library then the

Or rather every rust project starts with cargo install tokio thiserror anyhow. If we just added what 95% of projects are using to the standard library then the async runtime would be tokio, and error handling would be thiserror for making error types and anyhow for error handling. Your ability to go look for new 3rd party libraries, as well as this article's recommendations, are examples of how Rust's careful approach to standard library additions allows the ecosystem to innovate and try to come up with new and better solutions that might not be API compatible with the status quo

johnisgood 1y ago
Just please let us not end up with something like Node.js where we use a crate that has <10 LOC. Irks me. And if Rust ends up like that, I will never switch. It already builds ~50 crates for medium-sized projects.
- Expurple 1y ago
  Rust crates usually have "feature flags" [1] that help with dependency bloat. You only pull in the parts of the dependency tree that you actually use, even if the crates that you use can be configured to provide more features and pull more dependencies. https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html
  - pjmlp 1y ago
    Also a reason why some crates get compiled multiple times, making the compile times even more of a pain, when they happen to be referenced multiple times with different configurations.
    - Expurple 1y ago
      True, but this is being worked on now: https://github.com/rust-lang/cargo/issues/14774 https://github.com/rust-lang/cargo/issues/14774
      - pjmlp 1y ago
        Last update was almost a year ago, hardly being worked on.
        Expurple 1y ago
        What do you mean? At the bottom of the page, the latest update is a pull request that was opened 10 days ago: https://github.com/rust-lang/cargo/pull/15684 https://github.com/rust-lang/cargo/pull/15684
jenadine 1y ago
I prefer `derive_more` than thiserror. Because it is a superset and has more useful derive I use. color-eyre is better than anyhow.
pjmlp 1y ago
I rather take the approach that basic language features are in the box. Too much innovation gets out of control, and might not be available every platform.
- nemothekid 1y ago
  I think this is a valid criticism, however I think the direction Rust went was better. It's easy in hindsight to say that the error handling system that emerged in ~2020-ish should have been baked in the library when the language was stabilized in 2015. However even in 2012 (when Go 1.0 was released), errors as values was a pretty novel idea among mainstream programming languages and Go has some warts that were baked into the language that they have now given up on fixing. As a result, I find error handling in Go to be pretty cumbersome even though the language design has progressed to a point where it theoretically could be made much more ergonomic. You can imagine a world where instead of functions returning `(x, err)` they could return `Result[T]error` - an that would open up so many more monadic apis, similar to whats in Rust. But that future seems to be completely blocked off because of the error handling patterns that are now baked into the language. There's no guarantee the Rust team would have landed on something particularly useful. Even the entire error trait, as released, is now deprecated. `thiserror`, the most popular error crate for libraries wasn't released until 2019.
  - pjmlp 1y ago
    Errors as values is a quite old idea, predating exceptions, mainstream just got a bit forgotten about how we used to code until early 2000's. Also as you can seen by sibling comments, the beauty of 3rd party dependencies is that each dev has a different opinion what they should be, so any given project gets a bunch of them.
    - nemothekid 1y ago
      >However even in 2012 (when Go 1.0 was released), errors as values was a pretty novel idea among mainstream programming languages >Errors as values is a quite old idea, predating exceptions, mainstream just got a bit forgotten about how we used to code until early 2000's. I'm not sure these two sentences are in disagreement with each other. >the beauty of 3rd party dependencies is that each dev has a different opinion what they should be, The hope is in that some time in the future, the community will eventually coalesce on a superior option with the appropriate patterns. Because the mainstream had forgotten how to use errors as values, my point is, its more likely that Rust 1.0 would have baked in a poor solution.
worik 1y ago
> every rust project starts with cargo install tokio thiserror anyhow. True, almost. Not mine Makes me sad

johnisgood 1y ago

Just please let us not end up with something like Node.js where we use a crate that has <10 LOC. Irks me. And if Rust ends up like that, I will never switch. It already builds ~50 crates for medium-sized projects.

Expurple 1y ago
Rust crates usually have "feature flags" [1] that help with dependency bloat. You only pull in the parts of the dependency tree that you actually use, even if the crates that you use can be configured to provide more features and pull more dependencies. https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html
- pjmlp 1y ago
  Also a reason why some crates get compiled multiple times, making the compile times even more of a pain, when they happen to be referenced multiple times with different configurations.
  - Expurple 1y ago
    True, but this is being worked on now: https://github.com/rust-lang/cargo/issues/14774 https://github.com/rust-lang/cargo/issues/14774
    - pjmlp 1y ago
      Last update was almost a year ago, hardly being worked on.
      - Expurple 1y ago
        What do you mean? At the bottom of the page, the latest update is a pull request that was opened 10 days ago: https://github.com/rust-lang/cargo/pull/15684 https://github.com/rust-lang/cargo/pull/15684

jenadine 1y ago

I prefer `derive_more` than thiserror. Because it is a superset and has more useful derive I use. color-eyre is better than anyhow.

pjmlp 1y ago

I rather take the approach that basic language features are in the box. Too much innovation gets out of control, and might not be available every platform.

nemothekid 1y ago
I think this is a valid criticism, however I think the direction Rust went was better. It's easy in hindsight to say that the error handling system that emerged in ~2020-ish should have been baked in the library when the language was stabilized in 2015. However even in 2012 (when Go 1.0 was released), errors as values was a pretty novel idea among mainstream programming languages and Go has some warts that were baked into the language that they have now given up on fixing. As a result, I find error handling in Go to be pretty cumbersome even though the language design has progressed to a point where it theoretically could be made much more ergonomic. You can imagine a world where instead of functions returning `(x, err)` they could return `Result[T]error` - an that would open up so many more monadic apis, similar to whats in Rust. But that future seems to be completely blocked off because of the error handling patterns that are now baked into the language. There's no guarantee the Rust team would have landed on something particularly useful. Even the entire error trait, as released, is now deprecated. `thiserror`, the most popular error crate for libraries wasn't released until 2019.
- pjmlp 1y ago
  Errors as values is a quite old idea, predating exceptions, mainstream just got a bit forgotten about how we used to code until early 2000's. Also as you can seen by sibling comments, the beauty of 3rd party dependencies is that each dev has a different opinion what they should be, so any given project gets a bunch of them.
  - nemothekid 1y ago
    >However even in 2012 (when Go 1.0 was released), errors as values was a pretty novel idea among mainstream programming languages >Errors as values is a quite old idea, predating exceptions, mainstream just got a bit forgotten about how we used to code until early 2000's. I'm not sure these two sentences are in disagreement with each other. >the beauty of 3rd party dependencies is that each dev has a different opinion what they should be, The hope is in that some time in the future, the community will eventually coalesce on a superior option with the appropriate patterns. Because the mainstream had forgotten how to use errors as values, my point is, its more likely that Rust 1.0 would have baked in a poor solution.

worik 1y ago

> every rust project starts with cargo install tokio thiserror anyhow. True, almost. Not mine Makes me sad