3 ms·

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

nneonneo 4y ago
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 https://news.ycombinator.com/item?id=33510976
- dmitriid 4y ago
  > 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.
  - sbergot 4y ago
    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.
  - deleted 4y ago
    [deleted]
  - wongarsu 4y ago
    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.
  - maple3142 4y ago
    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 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.
- hardware2win 4y ago
  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
  - sbergot 4y ago
    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.
  - pharmakom 4y ago
    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.
  - recuter 4y ago
    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.
  - JamesSwift 4y ago
    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
- nurettin 4y ago
  Weak stdlib is all fun and games until someone deletes their crate.
rawoke083600 4y ago
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 ?

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 https://news.ycombinator.com/item?id=33510976

dmitriid 4y ago
> 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.
- sbergot 4y ago
  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.
- deleted 4y ago
  [deleted]
- wongarsu 4y ago
  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.
- maple3142 4y ago
  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 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.
hardware2win 4y ago
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
- sbergot 4y ago
  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.
- pharmakom 4y ago
  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.
- recuter 4y ago
  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.
- JamesSwift 4y ago
  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
nurettin 4y ago
Weak stdlib is all fun and games until someone deletes their crate.

rawoke083600 4y ago

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 ?