4 ms·

No way. I'd much prefer we have a constellation of core companion libraries like Google's Guava. We do not need to saddle Rust with garbage that will feel date

No way. I'd much prefer we have a constellation of core companion libraries like Google's Guava. We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Cargo does the job just fine. We just need some high quality optional batteries. Embedded projects are unlikely to need standard library bloat. No_std should be top of mind for everyone. Something that might make additional libraries feel more first class: if cargo finally got namespaces and if the Rust project took on "@rust/" as the org name to launch officially sanctioned and maintained packages.

pjmlp 2y ago
Python's garbage works everywhere there is a full CPython implementation, I see that as an advantage.
- echelon 2y ago
  I develop for Linux, Mac, and Windows. Multiple architectures and OSes. I rarely see platform issues with Rust. It's typically only stuff at the edge, like CUDA libraries, that trip up cross-platform builds. Rust, as a systems language, is quite good at working on a variety of systems.
  - pjmlp 2y ago
    Starts already that Rust won't support architectures not available on LLVM, but on GCC, otherwise having a Rust frontend project for GCC wouldn't be a thing. And the systems language remark, I am still looking forward when sorting ABI issues for binary libraries is finally something that doesn't need to go through solutions designed for C and C++.
    - dezgeg 2y ago
      What architectures that are missing from LLVM are commercially relevant today and not on well-earned retirement?
bigstrat2003 2y ago
> We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Python's standard library is a strength, not a weakness. Rust should be so lucky. It's wonderful to have basic functionality which is guaranteed to be there no matter what. Many people work in environments where they can't just YOLO download packages from the Internet, so they have to make do with whatever is in the stdlib or what they can write themselves.
- echelon 2y ago
  > Python's standard library is a strength, not a weakness. Rust should be so lucky. Rust is luckier. It has the correct approach. You can find every battery you need in crates.io. Python has had monstrosities like urllib, urllib2, http, etc. All pretty much ignored in favor of the external requests library and its kin. The standard library also has inconsistencies in calling conventions and naming conventions and it has to support those *FOREVER*. The core language should be pristine. Rust is doing it right. Everything else you need is within grasp.
  - wolvesechoes 2y ago
    "Rust is doing it right." Standard response every time there is some criticism of Rust.
    - echelon 2y ago
      bigstrat2003's argument is approximately "Python is batteries included" My counter argument is that the "batteries included" approach tends to atrophy and become dead weight. Your counter seems to be "that's not an argument, that's just Rust hype." Am I interpreting you correctly? Because I think my argument is salient and correct. I don't want to be stuck with dated APIs from 20 years of cruft in the standard library. The Python standard library is where modules go to die. It has two test frameworks nobody uses anymore, and how many XML libraries? Seven? (The correct answer is "four", I think. And that's four too many.) The Python standard library has so much junk inside, and it can't be safely removed or cleaned up. A standard library should be data structure/collections, filesystem/os libraries, and maybe network libraries. That's it. Everything else changes with too much regularity to be packed in.
jaas 2y ago
I don't think an additional standard library layer, whatever you call it, has to have the same tight controls on backwards compatibility and evolution that the actual standard library has. IMO the goal of creating it should be to improve supply chain security, not to provide an extremely stable API, which might be more of a priority at lower levels but chokes off the kind of evolution that will be needed. I think what you're suggesting is a great idea for a new standard library layer, you're just not using that label. A set of packages in a Rust namespace, maintained by the same community of folks but under policies that comply with best practices for security and some additional support to meet those best practices. The crates shouldn't be required, so no_std should work just as it would prior to such a collection.
- deleted 2y ago
  [deleted]
procaryote 2y ago
Python's standard library is the main reason python is usable. Python packaging is somehow a 30 year train crash that keeps going, but the standard library is good enough that I can do most things without dependencies or with very small number of them.

pjmlp 2y ago

Python's garbage works everywhere there is a full CPython implementation, I see that as an advantage.

echelon 2y ago
I develop for Linux, Mac, and Windows. Multiple architectures and OSes. I rarely see platform issues with Rust. It's typically only stuff at the edge, like CUDA libraries, that trip up cross-platform builds. Rust, as a systems language, is quite good at working on a variety of systems.
- pjmlp 2y ago
  Starts already that Rust won't support architectures not available on LLVM, but on GCC, otherwise having a Rust frontend project for GCC wouldn't be a thing. And the systems language remark, I am still looking forward when sorting ABI issues for binary libraries is finally something that doesn't need to go through solutions designed for C and C++.
  - dezgeg 2y ago
    What architectures that are missing from LLVM are commercially relevant today and not on well-earned retirement?

bigstrat2003 2y ago

> We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Python's standard library is a strength, not a weakness. Rust should be so lucky. It's wonderful to have basic functionality which is guaranteed to be there no matter what. Many people work in environments where they can't just YOLO download packages from the Internet, so they have to make do with whatever is in the stdlib or what they can write themselves.

echelon 2y ago
> Python's standard library is a strength, not a weakness. Rust should be so lucky. Rust is luckier. It has the correct approach. You can find every battery you need in crates.io. Python has had monstrosities like urllib, urllib2, http, etc. All pretty much ignored in favor of the external requests library and its kin. The standard library also has inconsistencies in calling conventions and naming conventions and it has to support those *FOREVER*. The core language should be pristine. Rust is doing it right. Everything else you need is within grasp.
- wolvesechoes 2y ago
  "Rust is doing it right." Standard response every time there is some criticism of Rust.
  - echelon 2y ago
    bigstrat2003's argument is approximately "Python is batteries included" My counter argument is that the "batteries included" approach tends to atrophy and become dead weight. Your counter seems to be "that's not an argument, that's just Rust hype." Am I interpreting you correctly? Because I think my argument is salient and correct. I don't want to be stuck with dated APIs from 20 years of cruft in the standard library. The Python standard library is where modules go to die. It has two test frameworks nobody uses anymore, and how many XML libraries? Seven? (The correct answer is "four", I think. And that's four too many.) The Python standard library has so much junk inside, and it can't be safely removed or cleaned up. A standard library should be data structure/collections, filesystem/os libraries, and maybe network libraries. That's it. Everything else changes with too much regularity to be packed in.

jaas 2y ago

I don't think an additional standard library layer, whatever you call it, has to have the same tight controls on backwards compatibility and evolution that the actual standard library has. IMO the goal of creating it should be to improve supply chain security, not to provide an extremely stable API, which might be more of a priority at lower levels but chokes off the kind of evolution that will be needed. I think what you're suggesting is a great idea for a new standard library layer, you're just not using that label. A set of packages in a Rust namespace, maintained by the same community of folks but under policies that comply with best practices for security and some additional support to meet those best practices. The crates shouldn't be required, so no_std should work just as it would prior to such a collection.

deleted 2y ago
[deleted]

procaryote 2y ago

Python's standard library is the main reason python is usable. Python packaging is somehow a 30 year train crash that keeps going, but the standard library is good enough that I can do most things without dependencies or with very small number of them.