[Chai-T-Rex]

If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)` as the version that can return `None` when there's nothing at that index.

[mathw]

I do wish this is something Rust had done better though - the panicking versions often look more attractive and obvious to developers, and that's the wrong way round. Vec indexing, IMO, should return Option<T>.

[sshine]

While that is true, there are clippy::indexing_slicing, clippy::string_slice for that:

  https://github.com/rust-lang/rust-clippy/issues/8184#issuecomment-1003651774

  error: indexing may panic
     --> src/main.rs:100:57
      |
  100 |             rtmp::header::BasicHeader::ID0 => u32::from(buffer[1]) + 64,
      |                                                         ^^^^^^^^^
      |
      = help: consider using `.get(n)` or `.get_mut(n)` instead
      = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#indexing_slicing

[quotemstr]

One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.

[jll29]

One of my dreams is for someone to create a Rust stdlib, full stop.

I love Rust the language, but the current bazar of little bits of functionality scattered around in the form of a zoo of crates is such a mess compared to, say, Java's class library (I/O, data structures, std. algorthms for searching, sorting etc., arranged in a logically and hierarchially named way).

I'm not against alternative implementations, but I'd rather have one "official" implementation that everyone knows that covers most cases and makes for the idiomatic reading of source code.

[OtomotO]

No!

I mean, yes, but not an official one.

The stdlib is where good ideas go to die.

Waiting for "pub struct RDBMSInferfaceV17ThisTimeWeGotItRightForSure"

[thesuperbigfrog]

Firm disagree.

Sylvain Kerkour described the problems Rust faces by having a limited standard library:

"The time has come for Rust to graduate from a shadow employment program in Big Tech companies to a programming language empowering the masses of engineers (and not just "programmers") wanting to build efficient and robust sfotware.

What crypto library should we use? ring, RustCrypto, rust-crypto (don't use it!), boring, aws-lc-s or openssl?

Which HTTP framework? actix-web, axum, dropshot or hyper?

What about a time library? time, chrono or jiff (how I'm even supposed to find this one)?

You get it, if you are not constantly following the latest news, your code is already technical debt before it's even written. Fragmentation is exhausting.

I just looked at the dependencies of a medium-sized project I'm working on, and we have 5+ (!) different crpyto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto. All of this because our various dependencies have picked a different one for their own cryptographic usage. This is insane, first because it introduces a lot of supply chain attack entry points, but also because there is no way that we will audit all of them"

Source: https://kerkour.com/rust-stdx

My moderate-sized Rust web service project requires 587 third-party crates which seems ridiculous.

Fortunately, cargo makes it easy to manage the dependencies, but unfortunately I don't know how well supported or maintained the dependencies are. How well will they be maintained in five years from now? Will I need to find newer libraries and rewrite portions of my project to provide the same features that I have now? I don't know.

[andrewshadura]

I think someone's already created this.

[OtomotO]

in the stdlib, yes. In 3rd party crates? Depends!