4 ms·

Hard disagree. The main reason I've wrote so much python in the last 10 years is due to it's stdlib being comprehensive enough to do 95% of the tasks I need wi

Hard disagree. The main reason I've wrote so much python in the last 10 years is due to it's stdlib being comprehensive enough to do 95% of the tasks I need without adding any dependency. This despite the fact that I never was super-fond of python's syntax and ideology, although I just learned to accept it. I was writing a ton of perl before that, and with python I could do more with less "CPAN". I would have _never_ made the switch without. A good stdlib ensures decent performance, stability and overall code quality to your project. Without that, you need tons of dependencies along with version pinning (as developers nowdays understand semver even less than 20 years ago) and duplication due to your dependencies picking different packages as their own base due to the lacking stdlib. I hate the sort of ecosystem which is built around this pattern. See npm for one extreme, although I see cargo not too far away in the horizon.

hiptobecubic 5y ago
Ok but you didn't contest anything in their argument as far as I can tell.
cies 5y ago
> A good stdlib ensures decent performance, stability and overall code quality to your project. How then? I can give counter examples of the opposite easily: An extensive stdlib ensures decent performance: https://stackoverflow.com/questions/31548680/why-is-python-3-is-considerably-slower-than-python-2 https://stackoverflow.com/questions/31548680/why-is-python-3... An extensive stdlib ensures stability: i'm not even sure how, with good version pinning it should always work, regardless of the it being std lib or otherwise. An extensive stdlib ensures overall code quality to your project. This one I agree most with, but because the std lib sets the idiomatic writing style of the project. I'm not how important the size of the std is for this to work.
- progval 5y ago
  > An extensive stdlib ensures decent performance: https://stackoverflow.com/questions/31548680/why-is-python-3-is-considerably-slower-than-python-2 https://stackoverflow.com/questions/31548680/why-is-python-3... This example is about a language issue, not the stdlib. And it's only slower on purely computational code, which Python is known to be bad at anyway, as a tradeoff to avoid overflow issues. > An extensive stdlib ensures stability: i'm not even sure how, with good version pinning it should always work, regardless of the it being std lib or otherwise. Version pinning is a bad practice because it slows deployment of security updates. It also only works for end applications, as libraries cannot reasonably pin their own dependencies.
  - cies 5y ago
    In rust an int is an int, in Python this changes with versions. Std lib needs to change along. > Version pinning is a bad practice because it slows deployment of security updates. How is that not true for stdlibs? > It also only works for end applications, as libraries cannot reasonably pin their own dependencies. Really?
    - codeflo 5y ago
      >> It also only works for end applications, as libraries cannot reasonably pin their own dependencies. > Really? At least not usefully if types from those dependencies appear on the API surface.
    - progval 5y ago
      > In rust an int is an int And Rust ints can overflow. It's a tradeoff. >> Version pinning is a bad practice because it slows deployment of security updates. > How is that not true for stdlibs? Because, if without pinning, the package manager always gets the latest available version and installs it for all applications on the system once and for all. When pinning dependencies, system administrators need to wait for every single application to update its pin.
      - DerArzt 5y ago
        Do we want to always get the latest version? The whole colors.js and faker.js thing from yesterday comes to mind as a very good reason to not want to auto-update to the latest version of a lib.
        progval 5y ago
        That's why I install from curated package repositories (eg. Debian) as much as possible, and encourage users of my own software to do so as well.
      - jimktrains2 5y ago
        > And Rust ints can overflow. There are provisions to do math that won't overflow or that can saturate. For example https://doc.rust-lang.org/std/primitive.u32.html#method.checked_sub https://doc.rust-lang.org/std/primitive.u32.html#method.chec...
duped 5y ago
I think this mindset is exactly what Rust's stdlib encapsulates, where the differentiator comes is "scope." As an example, most of STD (the stuff outside core) makes the assumption that a nonfallible allocator exists. This is an entirely reasonable assumption for any high level programming language... yet it's one of the biggest complaints about Rust's standard library from systems programmers. And so a not-insignificant amount of (mostly volunteer) developer time has been spent modifying very basic data structures and APIs to support the (not so niche) use case of fallible and pluggable allocators. If you're working on a stdlib where the question, "what if my allocator doesn't work" is meaningful, it's not a big jump to much more complex questions about how to implement "standard" features in other languages that simply don't have the same concerns as a systems language like Rust - making it much more reasonable to shove off the responsibility of implementing those features in libraries out in the ecosystem. And I think that's wholly in line with the space that Rust occupies, which is next to C++ (which also has a lacking stdlib for "standard" features), but at least has a good enough package manager to deal with it.
mlindner 5y ago
Just try to do anything that involves any kind of heavy calculation with Python and tell me it has "decent performance". If you write such code in pure python it can easily be up to 1000x slower than a compiled language or using dedicated libraries that link C/C++/Rust libraries to Python. This is why you need to immediately reach for numpy and similar libraries that aren't part of the standard library.
- p7g 5y ago
  This discussion is about the standard library, not the language runtime. Decent performance here is meant relative to the performance of the language. In this case it could mean algorithmic complexity, for example.
- wheelerof4te 5y ago
  Software does not always require "heavy calculations". That is the case in majority of applications today. You would be surprised as to what can be made in Python using stdlib only. Ironically, Python makes the best desktop calculator. Go figure.

hiptobecubic 5y ago

Ok but you didn't contest anything in their argument as far as I can tell.

cies 5y ago

> A good stdlib ensures decent performance, stability and overall code quality to your project. How then? I can give counter examples of the opposite easily: An extensive stdlib ensures decent performance: https://stackoverflow.com/questions/31548680/why-is-python-3-is-considerably-slower-than-python-2 https://stackoverflow.com/questions/31548680/why-is-python-3... An extensive stdlib ensures stability: i'm not even sure how, with good version pinning it should always work, regardless of the it being std lib or otherwise. An extensive stdlib ensures overall code quality to your project. This one I agree most with, but because the std lib sets the idiomatic writing style of the project. I'm not how important the size of the std is for this to work.

progval 5y ago
> An extensive stdlib ensures decent performance: https://stackoverflow.com/questions/31548680/why-is-python-3-is-considerably-slower-than-python-2 https://stackoverflow.com/questions/31548680/why-is-python-3... This example is about a language issue, not the stdlib. And it's only slower on purely computational code, which Python is known to be bad at anyway, as a tradeoff to avoid overflow issues. > An extensive stdlib ensures stability: i'm not even sure how, with good version pinning it should always work, regardless of the it being std lib or otherwise. Version pinning is a bad practice because it slows deployment of security updates. It also only works for end applications, as libraries cannot reasonably pin their own dependencies.
- cies 5y ago
  In rust an int is an int, in Python this changes with versions. Std lib needs to change along. > Version pinning is a bad practice because it slows deployment of security updates. How is that not true for stdlibs? > It also only works for end applications, as libraries cannot reasonably pin their own dependencies. Really?
  - codeflo 5y ago
    >> It also only works for end applications, as libraries cannot reasonably pin their own dependencies. > Really? At least not usefully if types from those dependencies appear on the API surface.
  - progval 5y ago
    > In rust an int is an int And Rust ints can overflow. It's a tradeoff. >> Version pinning is a bad practice because it slows deployment of security updates. > How is that not true for stdlibs? Because, if without pinning, the package manager always gets the latest available version and installs it for all applications on the system once and for all. When pinning dependencies, system administrators need to wait for every single application to update its pin.
    - DerArzt 5y ago
      Do we want to always get the latest version? The whole colors.js and faker.js thing from yesterday comes to mind as a very good reason to not want to auto-update to the latest version of a lib.
      - progval 5y ago
        That's why I install from curated package repositories (eg. Debian) as much as possible, and encourage users of my own software to do so as well.
    - jimktrains2 5y ago
      > And Rust ints can overflow. There are provisions to do math that won't overflow or that can saturate. For example https://doc.rust-lang.org/std/primitive.u32.html#method.checked_sub https://doc.rust-lang.org/std/primitive.u32.html#method.chec...

duped 5y ago

I think this mindset is exactly what Rust's stdlib encapsulates, where the differentiator comes is "scope." As an example, most of STD (the stuff outside core) makes the assumption that a nonfallible allocator exists. This is an entirely reasonable assumption for any high level programming language... yet it's one of the biggest complaints about Rust's standard library from systems programmers. And so a not-insignificant amount of (mostly volunteer) developer time has been spent modifying very basic data structures and APIs to support the (not so niche) use case of fallible and pluggable allocators. If you're working on a stdlib where the question, "what if my allocator doesn't work" is meaningful, it's not a big jump to much more complex questions about how to implement "standard" features in other languages that simply don't have the same concerns as a systems language like Rust - making it much more reasonable to shove off the responsibility of implementing those features in libraries out in the ecosystem. And I think that's wholly in line with the space that Rust occupies, which is next to C++ (which also has a lacking stdlib for "standard" features), but at least has a good enough package manager to deal with it.

mlindner 5y ago

Just try to do anything that involves any kind of heavy calculation with Python and tell me it has "decent performance". If you write such code in pure python it can easily be up to 1000x slower than a compiled language or using dedicated libraries that link C/C++/Rust libraries to Python. This is why you need to immediately reach for numpy and similar libraries that aren't part of the standard library.

p7g 5y ago
This discussion is about the standard library, not the language runtime. Decent performance here is meant relative to the performance of the language. In this case it could mean algorithmic complexity, for example.
wheelerof4te 5y ago
Software does not always require "heavy calculations". That is the case in majority of applications today. You would be surprised as to what can be made in Python using stdlib only. Ironically, Python makes the best desktop calculator. Go figure.