Hacker News Reader

Comment by worldsavior | Hacker News Reader

Why regex is not in rust stdlib? It's one of the fundamental libraries out there.

Rust's philosophy is "batteries not included". It's weird coming from Python or Go, where the standard libraries are much larger, but it makes sense for Rust: keep the standard library small and agile (especially as it is statically linked into every binary!) so that it can be backwards-compatible forever and easily ported to different platforms, etc.

For regex specifically, the usual "regex" crate is fantastic and provides very good performance guarantees (no exponential behaviour, ever!), unlike a lot of regex libraries. However, it also comes with the tradeoff of not supporting arbitrary lookahead/lookbehind or many regex extensions, so people needing those features might need a different crate.

There's a nice discussion on another thread: https://news.ycombinator.com/item?id=33510976

> Rust's philosophy is "batteries not included".

In Javascript this led to, well, npm. Because there's no standard library, and everyone ended up reinventing everything.

And Python's philosophy leads to three different HTTP libraries in the standard library, but everyone still just does "pip install requests".

It's easy to find drawbacks of either extreme. I find Rust's approach of favoring competing, versioned libraries over standard library inclusion generally works well. Many of the libraries managed to significantly improve performance and ergonomics because they can have space to improve their API, and explore which behaviors and guarantees are useful. The biggest downside is that it's more difficult to protect against supply chain attacks.

I am not sure that python is a shining example for library management. Cargo seems well designed. And the package size is more a cultural thing.

JavaScript certainly has a standard library, it just really small. Node.js have a bigger standard library (https://nodejs.org/docs/latest-v18.x/api/index.html), including http/https and crypto stuffs and more, they are just not easy to use.

Weak standard lib is poor approach imo.

Supply chains are real and being scared to design good API that will survive test of time sounds like poor excuse

At worst you could steal API design from some mature and battle tested base class libs like .net

I agree that supply chain is a risk but I think you are creating a false dichotomy.

There is nothing stopping us from having a small standard library and a set of official - but optional - crates for common things like regex. This is the best of both worlds in my view.

It is not a weak standard lib and nobody is making excuses. Your mental mapping doesn't apply here, look into how it works if you are interested as it is different from what you are used to.

Yeah, from experience spinning up in Rust it is definitely not a good first-run experience.

- You type something in expecting autocomplete, its not there. "Huh, thats weird"

- Look it up online. Sure enough, its not in the standard library. OK, what should I use then?

- Do research to figure out what 3rd party crate to use

- Tend to abstract/isolate those bits in case you need to rip it out for a different implementation later

rust lifetimes and traits leads to different designs than .net more classical OO with managed memory & runtime. Also the rust team doesn't have Microsoft manpower. It is a bit unfair to say "just do like .net".

To me the right approach is to publish an "official" meta package that depends on a few core packages that work well together.

Weak stdlib is all fun and games until someone deletes their crate.

In 2022, I look for and expect my "next-lang-to-use" to have a basic and workable stdlib. By 2022 I mean, we live in a "connected and multi core world". Thus I want at min: 1) fantastic http-client 2) good enough json enc/dec 3) basic-db access 4) concurrency via lang primitives 5) Basic crypto stuff (hash)

Sure it might be overkill or "underkill ?) for some ?

Reply on news.ycombinator.com