6 ms·

Another big one that many languages treat as table stakes these days is the whole 'batteries included' thing. Whenever a new language comes out and I have to ma

Another big one that many languages treat as table stakes these days is the whole 'batteries included' thing. Whenever a new language comes out and I have to make my own (or install) core capabilities, it feels like a huge waste of time.

analog31 4y ago
Having to piece together a Python installation can be an annoyance for a beginner. I always offer to help them set things up the first time. Since most of my workplace is on Windows, it's easy to have people install WinPython. This is especially true if they've already tried setting things up, and have made a mess of it. Because WinPython is self contained, it can work on a computer that already has a working or non-working Python installation.
- donkeybeer 4y ago
  What do you mean by piecing together a python install? Most linux should have one pre-installed or easily available via the package manager. After that venvs and pip seem to be generally enough for most tasks.
  - ghshephard 4y ago
    I've been using Python for about 6 years, my last company wrote it's core commercial product exclusively in python. I've never used venvs, but I've yet to run into a situation where virtualenv (maybe with virtualwrappers as sugar), and pip + requirements.txt haven't been able to handle even fairly complex install situations.
  - analog31 4y ago
    My workplace is a Windows shop. I'm multi platform, but by and large the folks using Linux don't need my help. ;-) So when I help people its almost always on Windows.
  - heavyset_go 4y ago
    Packaging Python applications that are outside of containerized apps can be a headache. You can't assume that the system's Python suits your needs, or even that Python versions in package repositories will, either. A big pain point still remains when it comes to packaging and distribution. It's not insurmountable, but if you're used to compiling and/or cross-compiling and shipping binaries, shipping Python apps can be headache inducing. The headaches increase when you're working with Windows or macOS, or using bleeding edge Python versions. That said, for 99% of Python apps out there, the default tooling should be absolutely fine for packaging and distribution, as should 3rd party solutions like PyInstaller or Nuitka.
    - donkeybeer 4y ago
      Oh of course, packaging python apps for final distribution is a different matter. I was assuming they were talking about the process of setting up a dev environment not deployment.
      - heavyset_go 4y ago
        Oh yeah, 99.999% that's the case for dev environments. The only issue I've seen is that some versions of Linux distros have Python shipping with Tk and cryptography support in separate packages to be installed from repositories, where they might be installed by default on other distros, or are just included with the Python package.
travisgriggs 4y ago
"A lot of batteries included" cannot be repeated enough. This is huge. Some languages you have to write your own. But the flip is also true. Take Node. For function X, there are 100 ill named "add ons" of variable quality and repute. Discoverability is a nightmare. Which-to-use in your mashup leads to paralysis analysis. I use a handful of libraries for some pretty large Python apps, but for so much of the basics, it's all in there. The quality and documentation vary a little, but the similarity/consistency is much better than you find in the wild. Even in Elixir (a much smaller universe than Node/JS), I experience this "15 poorly named packages that do the same thing in different ways".
- jolux 4y ago
  Which Elixir libraries do you think should be in the stdlib that aren’t?
- sodapopcan 4y ago
  I haven't found that in Elixir... I often find one of two that haven't been updated in a couple of years but still work just fine because the Elixir language itself doesn't change much. It may depend on what types of libs you're looking for, of course. It's definitely missing a lot of stuff.
- at_a_remove 4y ago
  Agreed. I am a Perl refugee. I was so tired of searching CPAN to find ten packages, but some wouldn't install on Windows, and then I would have to evaluate the survivors. They would cover sixty percent of the problem, maybe seventy, all different coverages. Now people talk about Python's standard library being "where code goes to die," they want to remove old stuff, makes me sad.
- otabdeveloper4 4y ago
  Wait until you have to upgrade and update your Node application a year later.
- newswasboring 4y ago
  I am not a JS person so I dont know, but in the jungle of add ons I wonder why there isn't a project which provides a stdlib like package for JS. Is it because for JS you want to install minimal libs?
zx14 4y ago
Python is nowhere near as "batteries included" as .NET for example.
- osigurdson 4y ago
  Perhaps the next programming language / ecosystem can remove this problem entirely . Why is it so hard to have access to everything while shipping only what is actually needed?
  - bdcravens 4y ago
    The need to runtimes shared by multiple applications on a single machine makes this a hard problem to solve, unless it's statically compiled. Of course, Docker renders this moot, and I'm unaware of any languages written in a "Docker-first" manner.
  - chubot 4y ago
    Testing, versioning, deployment
bobbylarrybobby 4y ago
I think the desire for batteries to be included is a holdover from the time of really really bad (or no) package managers. With a good package manager it doesn't matter if your batteries come included or not. It also provides a way for packages to battle it out external to the language -- compare Python’s `urllib` and `requests`.
- galangalalgol 4y ago
  The curation of the batteries is the value add. Which grpc package do I want? Which json? Which random number generator? Finding which rust crate is the norm for any given thing, is a task in itself. Then there is the security aspect. Pulling in hundreds of repos with many authors each, is a security risk.
  - tialaramex 4y ago
    The curation you're relying on is probably not delivering what you hope. If you picked a Rust crate by looking at a SO answer from say 2020, you're probably getting a similar quality of "curation" in Python's standard libraries. Not because the Python maintainers are intentionally doing a bad job, it's just that their mission isn't to substitute for your research. To them, "Does last year's Python script still work?" is always higher priority than "What's the best way to do it today?". And what Python's security team decide constitutes a reasonable security fix may conflict pretty badly with what you need.
    - ShredKazoo 4y ago
      SO would disable a question of this type for being opinion-based. I would assume the Python devs review the code for a package before including it in the standard lib, right? That seems like a pretty big deal, well beyond someone just telling you that they tried a package and it worked for them.
    - adrianN 4y ago
      "Does last year's code still work" is very important to almost all programmers. I wouldn't want to accidentally use a library that gets abandoned or deprecated a few months after I made it an integral part of my software. Being able to mostly stick to the standard lib makes this a lot easier.

analog31 4y ago

Having to piece together a Python installation can be an annoyance for a beginner. I always offer to help them set things up the first time. Since most of my workplace is on Windows, it's easy to have people install WinPython. This is especially true if they've already tried setting things up, and have made a mess of it. Because WinPython is self contained, it can work on a computer that already has a working or non-working Python installation.

donkeybeer 4y ago
What do you mean by piecing together a python install? Most linux should have one pre-installed or easily available via the package manager. After that venvs and pip seem to be generally enough for most tasks.
- ghshephard 4y ago
  I've been using Python for about 6 years, my last company wrote it's core commercial product exclusively in python. I've never used venvs, but I've yet to run into a situation where virtualenv (maybe with virtualwrappers as sugar), and pip + requirements.txt haven't been able to handle even fairly complex install situations.
- analog31 4y ago
  My workplace is a Windows shop. I'm multi platform, but by and large the folks using Linux don't need my help. ;-) So when I help people its almost always on Windows.
- heavyset_go 4y ago
  Packaging Python applications that are outside of containerized apps can be a headache. You can't assume that the system's Python suits your needs, or even that Python versions in package repositories will, either. A big pain point still remains when it comes to packaging and distribution. It's not insurmountable, but if you're used to compiling and/or cross-compiling and shipping binaries, shipping Python apps can be headache inducing. The headaches increase when you're working with Windows or macOS, or using bleeding edge Python versions. That said, for 99% of Python apps out there, the default tooling should be absolutely fine for packaging and distribution, as should 3rd party solutions like PyInstaller or Nuitka.
  - donkeybeer 4y ago
    Oh of course, packaging python apps for final distribution is a different matter. I was assuming they were talking about the process of setting up a dev environment not deployment.
    - heavyset_go 4y ago
      Oh yeah, 99.999% that's the case for dev environments. The only issue I've seen is that some versions of Linux distros have Python shipping with Tk and cryptography support in separate packages to be installed from repositories, where they might be installed by default on other distros, or are just included with the Python package.

travisgriggs 4y ago

"A lot of batteries included" cannot be repeated enough. This is huge. Some languages you have to write your own. But the flip is also true. Take Node. For function X, there are 100 ill named "add ons" of variable quality and repute. Discoverability is a nightmare. Which-to-use in your mashup leads to paralysis analysis. I use a handful of libraries for some pretty large Python apps, but for so much of the basics, it's all in there. The quality and documentation vary a little, but the similarity/consistency is much better than you find in the wild. Even in Elixir (a much smaller universe than Node/JS), I experience this "15 poorly named packages that do the same thing in different ways".

jolux 4y ago
Which Elixir libraries do you think should be in the stdlib that aren’t?
sodapopcan 4y ago
I haven't found that in Elixir... I often find one of two that haven't been updated in a couple of years but still work just fine because the Elixir language itself doesn't change much. It may depend on what types of libs you're looking for, of course. It's definitely missing a lot of stuff.
at_a_remove 4y ago
Agreed. I am a Perl refugee. I was so tired of searching CPAN to find ten packages, but some wouldn't install on Windows, and then I would have to evaluate the survivors. They would cover sixty percent of the problem, maybe seventy, all different coverages. Now people talk about Python's standard library being "where code goes to die," they want to remove old stuff, makes me sad.
otabdeveloper4 4y ago
Wait until you have to upgrade and update your Node application a year later.
newswasboring 4y ago
I am not a JS person so I dont know, but in the jungle of add ons I wonder why there isn't a project which provides a stdlib like package for JS. Is it because for JS you want to install minimal libs?

zx14 4y ago

Python is nowhere near as "batteries included" as .NET for example.

osigurdson 4y ago
Perhaps the next programming language / ecosystem can remove this problem entirely . Why is it so hard to have access to everything while shipping only what is actually needed?
- bdcravens 4y ago
  The need to runtimes shared by multiple applications on a single machine makes this a hard problem to solve, unless it's statically compiled. Of course, Docker renders this moot, and I'm unaware of any languages written in a "Docker-first" manner.
- chubot 4y ago
  Testing, versioning, deployment

bobbylarrybobby 4y ago

I think the desire for batteries to be included is a holdover from the time of really really bad (or no) package managers. With a good package manager it doesn't matter if your batteries come included or not. It also provides a way for packages to battle it out external to the language -- compare Python’s `urllib` and `requests`.

galangalalgol 4y ago
The curation of the batteries is the value add. Which grpc package do I want? Which json? Which random number generator? Finding which rust crate is the norm for any given thing, is a task in itself. Then there is the security aspect. Pulling in hundreds of repos with many authors each, is a security risk.
- tialaramex 4y ago
  The curation you're relying on is probably not delivering what you hope. If you picked a Rust crate by looking at a SO answer from say 2020, you're probably getting a similar quality of "curation" in Python's standard libraries. Not because the Python maintainers are intentionally doing a bad job, it's just that their mission isn't to substitute for your research. To them, "Does last year's Python script still work?" is always higher priority than "What's the best way to do it today?". And what Python's security team decide constitutes a reasonable security fix may conflict pretty badly with what you need.
  - ShredKazoo 4y ago
    SO would disable a question of this type for being opinion-based. I would assume the Python devs review the code for a package before including it in the standard lib, right? That seems like a pretty big deal, well beyond someone just telling you that they tried a package and it worked for them.
  - adrianN 4y ago
    "Does last year's code still work" is very important to almost all programmers. I wouldn't want to accidentally use a library that gets abandoned or deprecated a few months after I made it an integral part of my software. Being able to mostly stick to the standard lib makes this a lot easier.