4 ms·

The main problem is that you cannot version the standard library (well, there are "editions" but that's a bit of a workaround for other language changes). Go h

by cyphar 7y ago

The main problem is that you cannot version the standard library (well, there are "editions" but that's a bit of a workaround for other language changes). Go has the exact same problem, and has also historically made similar mistakes to Rust in their stdlib (the "syscall" module is strongly recommended against -- instead you should use "golang.org/x/sys"). And it should be noted that Go is even more bare-bones than Rust -- the lack of generics means you have to use "containers" which is very limited (I also have a feeling it's used by effectively nobody, because of the bad ergonomics). I think the best solution for this problem might be some form of "meta-crate" concept which would allow you to pull in all of the well-vetted and stable libraries that most people want, without having to curate ~20 libraries yourself.

the_duke 7y ago
> And it should be noted that Go is even more bare-bones than Rust In certain ways Go is more bare bones, but Go also comes with common hashes, some crypto primitives, encodings like JSON, compression/archives, logging, date/time utilities, Regex, a templating engine, an http client and server, regex, .... All of which requires a dependency with Rust. I do remember an effort of a meta package like you mentioned. I think it was driven by brson and on Github, but I can't find it now, and it was abandoned anyway.
- cyphar 7y ago
  The problem is that several of those standard library components are no longer recommended for general usage: * As with "syscall", users are strongly suggested to use "golang.org/x/crypto" for crypto primitives like AEAD. All of the crypto bits in the standard library are probably still "okay" but there are better interfaces and more efficient implementations in "golang.org/x/crypto". * The "flags" package is basically useless for large projects (everyone uses "cobra" or "spf13/cli" to create CLI interfaces now). It also has the really weird Go-ism of "-flag" arguments. * For logging, most people use "logrus" or similar. "log" isn't necessarily bad, but it's not full-featured enough that most people end up not using it. * As for HTTP servers, at the very least you'll use "gorilla" to deal with routes -- if not completely switch to a different HTTP server implementation. * Not to mention some of the other weird bits and bobs which are useful, but are strange to include in such a small stdlib, like "mime". Or some of the more fruity stuff like "database". This is the downside of the batteries-included model. Especially when a lot of the bits in the Go stdlib were included early in the language's life and then quickly became a clearly bad idea but it was too late to remove them.
  - the_duke 7y ago
    I agree and I'm not advocating for Rust's std to gain things like http clients or template engines. But some parts of the ecosystem end up in a lot of projects. Conservatively extending std would be good for the language, IMO. To set a standard, reduce compile times, and ease the burden for companies that have hard review requirements for each dependency. Some things I'd like to see in std in a few years: * `serde` * `rand` * `log`, but probably without a backend, or a simple default * a subset of `chrono` * some parts of `rayon`
    - Sean1708 7y ago
      What about a set of "blessed" crates (that can only depend on other "blessed" crates) that are maintained by the language developers? Seems like the best of both worlds to me.
    - eridius 7y ago
      I think we could strike a balance. Don't put this stuff in the standard library, but have a category for crates that are officially blessed (or even maintained by) the core team, such that if you trust the Rust stdlib then you should be comfortable trusting these crates. Then provide binary distributions for the built crates for all tier 1 platforms at least (ideally for any platform where a binary distribution of the stdlib is available) and teach cargo how to download those. This way we maintain the ability to version these crates and have breaking changes, but without the overhead of having to recompile these crates.
the_duke 7y ago
Ah, I found the meta approach I mentioned: https://github.com/brson/stdx https://github.com/brson/stdx
- steveklabnik 7y ago
  There was also https://aturon.github.io/blog/2016/07/27/rust-platform/ https://aturon.github.io/blog/2016/07/27/rust-platform/ Both failed to gain any traction.
steveklabnik 7y ago
To be clear here, yes, editions cannot change the standard library, as it must be the same across all editions.

by cyphar 7y ago

the_duke 7y ago

> And it should be noted that Go is even more bare-bones than Rust In certain ways Go is more bare bones, but Go also comes with common hashes, some crypto primitives, encodings like JSON, compression/archives, logging, date/time utilities, Regex, a templating engine, an http client and server, regex, .... All of which requires a dependency with Rust. I do remember an effort of a meta package like you mentioned. I think it was driven by brson and on Github, but I can't find it now, and it was abandoned anyway.

cyphar 7y ago
The problem is that several of those standard library components are no longer recommended for general usage: * As with "syscall", users are strongly suggested to use "golang.org/x/crypto" for crypto primitives like AEAD. All of the crypto bits in the standard library are probably still "okay" but there are better interfaces and more efficient implementations in "golang.org/x/crypto". * The "flags" package is basically useless for large projects (everyone uses "cobra" or "spf13/cli" to create CLI interfaces now). It also has the really weird Go-ism of "-flag" arguments. * For logging, most people use "logrus" or similar. "log" isn't necessarily bad, but it's not full-featured enough that most people end up not using it. * As for HTTP servers, at the very least you'll use "gorilla" to deal with routes -- if not completely switch to a different HTTP server implementation. * Not to mention some of the other weird bits and bobs which are useful, but are strange to include in such a small stdlib, like "mime". Or some of the more fruity stuff like "database". This is the downside of the batteries-included model. Especially when a lot of the bits in the Go stdlib were included early in the language's life and then quickly became a clearly bad idea but it was too late to remove them.
- the_duke 7y ago
  I agree and I'm not advocating for Rust's std to gain things like http clients or template engines. But some parts of the ecosystem end up in a lot of projects. Conservatively extending std would be good for the language, IMO. To set a standard, reduce compile times, and ease the burden for companies that have hard review requirements for each dependency. Some things I'd like to see in std in a few years: * `serde` * `rand` * `log`, but probably without a backend, or a simple default * a subset of `chrono` * some parts of `rayon`
  - Sean1708 7y ago
    What about a set of "blessed" crates (that can only depend on other "blessed" crates) that are maintained by the language developers? Seems like the best of both worlds to me.
  - eridius 7y ago
    I think we could strike a balance. Don't put this stuff in the standard library, but have a category for crates that are officially blessed (or even maintained by) the core team, such that if you trust the Rust stdlib then you should be comfortable trusting these crates. Then provide binary distributions for the built crates for all tier 1 platforms at least (ideally for any platform where a binary distribution of the stdlib is available) and teach cargo how to download those. This way we maintain the ability to version these crates and have breaking changes, but without the overhead of having to recompile these crates.

the_duke 7y ago

Ah, I found the meta approach I mentioned: https://github.com/brson/stdx https://github.com/brson/stdx

steveklabnik 7y ago
There was also https://aturon.github.io/blog/2016/07/27/rust-platform/ https://aturon.github.io/blog/2016/07/27/rust-platform/ Both failed to gain any traction.

steveklabnik 7y ago

To be clear here, yes, editions cannot change the standard library, as it must be the same across all editions.