5 ms·

Because it requires that library with that API be maintained forever. Guaranteeing it eventually becoming unused because the language is evolving and better API

by rapsey 4y ago

Because it requires that library with that API be maintained forever. Guaranteeing it eventually becoming unused because the language is evolving and better APIs can be made. For instance mpsc and mutex libs are commonly not used because crossbeam-channels and parking_lot libraries are better than what Rust ships with.

maxbond 4y ago
In the Python community this is called the "dead batteries" problem, and the example I like to bring up is the csv sniffer: https://docs.python.org/3/library/csv.html#csv.Sniffer https://docs.python.org/3/library/csv.html#csv.Sniffer This feature runs some heuristics and invents a new dialect of CSV based on a sample of the file. That should send chills down your spine, there is literally no safe way to use this thing. Using it in production is a bug in and of itself and will likely lead to security issues.
- pjmlp 4y ago
  I rather use a dead battery that somehow helps me doing my work, even if with a couple of warts, than trying to see how random package gets compiled on platform XYZ.
  - maxbond 4y ago
    Totally understand not wanting to spend time vetting dependencies. For what it's worth, most packages "just work" on most platforms. My experience with WASM and microcontrollers is fairly limited, but I haven't had too much trouble there either. Or at least, less trouble than I would've anticipated.
    - pjmlp 4y ago
      Lets say I instal Python package for IBM I, I am sure that the standard library is supported. How many Rust packages work on IBM i? IBM i was a random example, there are plenty of platforms out there.
      - maxbond 4y ago
        If Rust added support for that operating system, than all of the packages that didn't rely on platform specific features would work (which is to say, virtually all of them). As it is, I'd speculate that with some fiddling you could probably get them working there today, but you'd have to repeat that every time you wanted to move to a new version of Rust. That isn't really a function of whether or not the language is batteries included, and making it batteries not included can make porting the language to new platforms simpler. But if you're working in an environment where Rust support is poor and Python support is rich, then yeah it totally makes sense to choose Python over Rust, I'm not any sort of absolutist.
        pjmlp 4y ago
        That isn't the point, rather it is hit-and-miss with external libraries.
        maxbond 4y ago
        I've not had the experience that Rust libraries rely on platform specific behavior (ignoring things that specifically expose the capabilities of a platform specific like a HAL crate or an io_uring crate). I've had far less trouble than I anticipated getting up and running in embedded and WASM contexts. Have you had a different experience that's leading you to these views?
        pjmlp 4y ago
        As mentioned, assuming rustc and cargo exist for IBM i, what will cargo build on any random project do?
        maxbond 4y ago
        Well, I responded to this hypothetical, so I guess we just disagree.
- bigbillheck 4y ago
  Python deprecates stuff all the time. I got bit by this just last week when dusting off some old code and trying to update it from 3.7 only to find out that it's broken because stuff got moved around and now some imports don't work.
endorphine 4y ago
With things that don't change often like JSON, XML and crypto, the same argument doesn't hold much value though.
- maxbond 4y ago
  Those are all use cases that are likely to have security issues; it would be nice if we could release security fixes for them without needing to bump up the release schedule of the entire language. (But this is an area where good engineers reasonably differ.)
- fiedzia 4y ago
  crypto does change. Maybe not specifications of specific algorithms, but which of them are supported may change. Do we want to break existing code when one of them will become deprecated or do we want to allow insecure method to be used to make web requests?
  - cesarb 4y ago
    > > With things that don't change often like [...] and crypto > crypto does change A nearby comment mentioned Python, which did have that problem. The ssl module on its standard library didn't verify certificates by default, and since that's no longer considered good cryptographic practice (to put it mildly), that behavior had to change, even though it could break existing code. See for instance https://access.redhat.com/articles/2039753 https://access.redhat.com/articles/2039753 and the several PEPs it links to, in particular https://peps.python.org/pep-0466/ https://peps.python.org/pep-0466/ which is about the backporting of the Python 3.x version of that module to a patch release of Python 2.7.
ohbtvz 4y ago
> Because it requires that library with that API be maintained forever. Why would you say that? Do a cycle of deprecate + remove every few major releases, provide a migration path, and you're good.
- pornel 4y ago
  No, Rust has a strong backwards compatibility guarantee. It can deprecate stuff, but not remove. Editions currently don't allow existence of multiple standard libraries, because code from different editions can be mixed.
  - kibwen 4y ago
    Note that editions don't allow multiple standard libraries, but it would be possible (trivial, even) to use an edition-specific lint to deny access to a deprecated function on a newer edition. Even with that, editions don't allow you to expose two different symbols with the same name from the one single libstd so you can't easily "reclaim" or "redefine" an existing function, however since Rust already does mangling it should be possible (though potentially hairy) to expose identically-named functions that resolve to different symbols depending on the chosen edition of the crate. Neither of these things have ever been done, though they have been proposed, and it's just up to the library team to determine if they ever think it would be worth it to do so.
    - nicoburns 4y ago
      I would absolutely love rustc to gain the ability to rename stdlib types across edition boundaries (e.g. you create a Range2 type which is named Range in Rust 2024, or vice versa). I'm not super familiar with the compiler internals, but it seems to me that it shouldn't be all that hairy. One ought to be able to deal with this in a single pass at a very early stage in the compile process. Seems like this would be a great way to deal with deprecated stdlib functionality. Especially in the case that there is a better replacement available. Ranges and channels would be obvious candidates for this.
  - ohbtvz 4y ago
kibwen 4y ago
Rust's standard Mutex type has been improved to the point that they're now competitive or faster than parking_lot, at least on Linux: https://github.com/rust-lang/rust/pull/95035#issuecomment-1073966631 https://github.com/rust-lang/rust/pull/95035#issuecomment-10... Channels appear to be trickier, but it might be possible to upstream crossbeam's version of those as well (it's certainly been proposed and discussed for years).
- rapsey 4y ago
  Locking api in std returns Result which is very annoying.

by rapsey 4y ago

maxbond 4y ago

In the Python community this is called the "dead batteries" problem, and the example I like to bring up is the csv sniffer: https://docs.python.org/3/library/csv.html#csv.Sniffer https://docs.python.org/3/library/csv.html#csv.Sniffer This feature runs some heuristics and invents a new dialect of CSV based on a sample of the file. That should send chills down your spine, there is literally no safe way to use this thing. Using it in production is a bug in and of itself and will likely lead to security issues.

pjmlp 4y ago
I rather use a dead battery that somehow helps me doing my work, even if with a couple of warts, than trying to see how random package gets compiled on platform XYZ.
- maxbond 4y ago
  Totally understand not wanting to spend time vetting dependencies. For what it's worth, most packages "just work" on most platforms. My experience with WASM and microcontrollers is fairly limited, but I haven't had too much trouble there either. Or at least, less trouble than I would've anticipated.
  - pjmlp 4y ago
    Lets say I instal Python package for IBM I, I am sure that the standard library is supported. How many Rust packages work on IBM i? IBM i was a random example, there are plenty of platforms out there.
    - maxbond 4y ago
      If Rust added support for that operating system, than all of the packages that didn't rely on platform specific features would work (which is to say, virtually all of them). As it is, I'd speculate that with some fiddling you could probably get them working there today, but you'd have to repeat that every time you wanted to move to a new version of Rust. That isn't really a function of whether or not the language is batteries included, and making it batteries not included can make porting the language to new platforms simpler. But if you're working in an environment where Rust support is poor and Python support is rich, then yeah it totally makes sense to choose Python over Rust, I'm not any sort of absolutist.
      - pjmlp 4y ago
        That isn't the point, rather it is hit-and-miss with external libraries.
        maxbond 4y ago
        I've not had the experience that Rust libraries rely on platform specific behavior (ignoring things that specifically expose the capabilities of a platform specific like a HAL crate or an io_uring crate). I've had far less trouble than I anticipated getting up and running in embedded and WASM contexts. Have you had a different experience that's leading you to these views?
        pjmlp 4y ago
        As mentioned, assuming rustc and cargo exist for IBM i, what will cargo build on any random project do?
        maxbond 4y ago
        Well, I responded to this hypothetical, so I guess we just disagree.
bigbillheck 4y ago
Python deprecates stuff all the time. I got bit by this just last week when dusting off some old code and trying to update it from 3.7 only to find out that it's broken because stuff got moved around and now some imports don't work.

endorphine 4y ago

With things that don't change often like JSON, XML and crypto, the same argument doesn't hold much value though.

maxbond 4y ago
Those are all use cases that are likely to have security issues; it would be nice if we could release security fixes for them without needing to bump up the release schedule of the entire language. (But this is an area where good engineers reasonably differ.)
fiedzia 4y ago
crypto does change. Maybe not specifications of specific algorithms, but which of them are supported may change. Do we want to break existing code when one of them will become deprecated or do we want to allow insecure method to be used to make web requests?
- cesarb 4y ago
  > > With things that don't change often like [...] and crypto > crypto does change A nearby comment mentioned Python, which did have that problem. The ssl module on its standard library didn't verify certificates by default, and since that's no longer considered good cryptographic practice (to put it mildly), that behavior had to change, even though it could break existing code. See for instance https://access.redhat.com/articles/2039753 https://access.redhat.com/articles/2039753 and the several PEPs it links to, in particular https://peps.python.org/pep-0466/ https://peps.python.org/pep-0466/ which is about the backporting of the Python 3.x version of that module to a patch release of Python 2.7.

ohbtvz 4y ago

> Because it requires that library with that API be maintained forever. Why would you say that? Do a cycle of deprecate + remove every few major releases, provide a migration path, and you're good.

pornel 4y ago
No, Rust has a strong backwards compatibility guarantee. It can deprecate stuff, but not remove. Editions currently don't allow existence of multiple standard libraries, because code from different editions can be mixed.
- kibwen 4y ago
  Note that editions don't allow multiple standard libraries, but it would be possible (trivial, even) to use an edition-specific lint to deny access to a deprecated function on a newer edition. Even with that, editions don't allow you to expose two different symbols with the same name from the one single libstd so you can't easily "reclaim" or "redefine" an existing function, however since Rust already does mangling it should be possible (though potentially hairy) to expose identically-named functions that resolve to different symbols depending on the chosen edition of the crate. Neither of these things have ever been done, though they have been proposed, and it's just up to the library team to determine if they ever think it would be worth it to do so.
  - nicoburns 4y ago
    I would absolutely love rustc to gain the ability to rename stdlib types across edition boundaries (e.g. you create a Range2 type which is named Range in Rust 2024, or vice versa). I'm not super familiar with the compiler internals, but it seems to me that it shouldn't be all that hairy. One ought to be able to deal with this in a single pass at a very early stage in the compile process. Seems like this would be a great way to deal with deprecated stdlib functionality. Especially in the case that there is a better replacement available. Ranges and channels would be obvious candidates for this.
- ohbtvz 4y ago

kibwen 4y ago

Rust's standard Mutex type has been improved to the point that they're now competitive or faster than parking_lot, at least on Linux: https://github.com/rust-lang/rust/pull/95035#issuecomment-1073966631 https://github.com/rust-lang/rust/pull/95035#issuecomment-10... Channels appear to be trickier, but it might be possible to upstream crossbeam's version of those as well (it's certainly been proposed and discussed for years).

rapsey 4y ago
Locking api in std returns Result which is very annoying.