5 ms·

Python is a horrible language for system administration (or designing systems as in system engineering, for that matter): it's big, it's bloated, it's over-comp

Python is a horrible language for system administration (or designing systems as in system engineering, for that matter): it's big, it's bloated, it's over-complicated, it's slow, it's hard to debug. Shell is the native automation facility of the UNIX-like operating systems, and with 40+ years behind it, it is well understood, easy to write, easy to debug, and has no artificial dependencies (so, completely the opposite of Python). Combine shell with AWK and you have an unbeatable combination for most computer automation and even very large scale data (pre)processing and number crunching.

dijit 4y ago
I disagree but only about 50%. Python is not really very slow overall unless you’re on windows. When you get to serious computing then breaking out of python is possible, but systems administration is not the place to do heavy computation. As for debugability, I find python to be easier, set -/+x is great, but that’s not doing much more than printing out every line of execution, there’s no interactive debugger like python has afaik. The killer thing for me is that python has modules for basically everything, which is awesome. The thing that kills python for me is that I can’t be 100% sure if what version may exist on a system; and worse: if I actually use any modules then I have to somehow get them on the system. For systems administration, this is pretty close to a non-starter. Prevailing sysadmin knowledge is that the admin tools should not horn in excessive dependencies, since sysadmin tools should work when the system isn’t fully set up. This is why go is so great. But go is harder to debug than python in my experience.
- TomSwirly 4y ago
  > The thing that kills python for me is that I can’t be 100% sure if what version may exist on a system; pip handles that automatically - you set which version numbers of Python you can handle in your project specification. > and worse: if I actually use any modules then I have to somehow get them on the system. pip handles that too! ---- I'm not quite sure what the problems are, but between virtualenv/venv, pip, and modern package managers like poetry, this is really a solved problem - something you spend an hour setting up when you start a project and just never think of again. I do this so much I have a shell function, `nenv`, which creates a new virtualenv with a specific Python and then loads its dependencies into the virtualenv. It gives me tremendous freedom. For example, I can heavily instrument other modules' Python code inside the virtualenv (to find their bugs, e.g.) and then throw it all away and recreate it fresh in a few keystrokes. --- There are OK, well-known solutions to most of the common packaging and distribution problems with Python programs you might have. If you go back to it, you should spend a bit of time with this, it isn't that bad. (Poetry seems really cool - when I start something new it'll be with that.)
  - dijit 4y ago
    it's weirly naive to assume I don't know about pip as a python user as it's a bit ubiquitous. That said: This is very much a developers take on the packaging situation in python. Running virtualenvs is "fine" until you're not connected to the internet, a less-and-less common scenario thankfully. pip itself (without virtualenvs) will "dirty" the system, or you use the --user flag and make it work only for one user. The situation for systems administrators is to do things that do not mess with the developers, if I install a package, especially with a version lock, and it directly conflicts with a developers (less and less of a problem with containers!) then they're going to be very cross with me.
    - keymasta 4y ago
      This may be a silly question, but how would you think to install packages if not with pip? I used to see python the same way, and coding on my megalithic single file would always take a couple hours to set up on a fresh computer. Then I discovered requirements.txt, where you simply list each package you need and the version (range) desired and then run: pip install -r requirements.txt this will install everything unless it's fucky like for example, pip install kivy-garden.matplotlib will not work with pip but everything else does.
      - Annatar 4y ago
        "This may be a silly question, but how would you think to install packages if not with pip?" Through the native software management subsystem: RPM, SVR4 packaging, pkgsrc, MSI... always use the native software management subsystem - that is what it is there for, for developers to deliver their software with.
    - Annatar 4y ago
      "Running virtualenvs is "fine" until you're not connected to the internet, a less-and-less common scenario thankfully." Any high security environment (read: the financial industry) will have most of the servers purposely not connected to the InterNet, to prevent people from doing exactly the above and from attackers hacking in. Energy and pharmaceutical industries - same thing. That's the norm, not the exception, so pretty much any industry which is critical for society at large won't allow access to the InterNet.
TomSwirly 4y ago
Did Python pee in your teacup once or what? (Why is Python hard to debug compared with shell? Python has a debugger - does Bash?)
- Annatar 4y ago
  Python "peed in my teacup" many, many times: every time I run Mercurial, Python shits on me from Earth's orbit because the piece of crap language is so slow. And that is just one example among many. "Bash"? Is that all you know, "bash"? I wasn't writing about that GNU crap of a shell, but of real, AT&T Bourne or Korn shell! Debugging shell is trivial with set -x. I can find a problem in a shell program in seconds.
xigoi 4y ago
You say that Python is slow, as if shell wasn't slow?
- Annatar 4y ago
  shell is ultra fast, and it's very easy to squeeze performance out of shell programs. Like I wrote, shell is a well understood programming language - it's been around for almost 50 years and generations and generations have grown up on it professionally.
  - 411111111111111 4y ago
    To be fair, the startup speed of the shell is generally considered pretty slow/expensive in comparison to running everything in a single shell/executable.
    - Annatar 4y ago
      That's only a problem in real life if you're running SmartOS's pkgsrc build farm. And even then, there are techniques: Johnatan Perkin described them in length on his blog. Search for it.
  - v3ss0n 4y ago
    You are just assuming. Try benchmarking shellscript and compare to python with same functionality and then come back.
    - Annatar 4y ago
      I am not assuming, I do this daily so I know what I'm writing about. And as if that were not enough, I have formal education in shell programming as part of my degree.
      - justinsaccount 4y ago
        Hah. Like the time you tried to tell people that grep -r was not real unix, and that they should use the vastly slower combination of find + xargs + grep? https://news.ycombinator.com/item?id=20633546 https://news.ycombinator.com/item?id=20633546 You are the embodiment of the Dunning–Kruger effect.

dijit 4y ago

I disagree but only about 50%. Python is not really very slow overall unless you’re on windows. When you get to serious computing then breaking out of python is possible, but systems administration is not the place to do heavy computation. As for debugability, I find python to be easier, set -/+x is great, but that’s not doing much more than printing out every line of execution, there’s no interactive debugger like python has afaik. The killer thing for me is that python has modules for basically everything, which is awesome. The thing that kills python for me is that I can’t be 100% sure if what version may exist on a system; and worse: if I actually use any modules then I have to somehow get them on the system. For systems administration, this is pretty close to a non-starter. Prevailing sysadmin knowledge is that the admin tools should not horn in excessive dependencies, since sysadmin tools should work when the system isn’t fully set up. This is why go is so great. But go is harder to debug than python in my experience.

TomSwirly 4y ago
> The thing that kills python for me is that I can’t be 100% sure if what version may exist on a system; pip handles that automatically - you set which version numbers of Python you can handle in your project specification. > and worse: if I actually use any modules then I have to somehow get them on the system. pip handles that too! ---- I'm not quite sure what the problems are, but between virtualenv/venv, pip, and modern package managers like poetry, this is really a solved problem - something you spend an hour setting up when you start a project and just never think of again. I do this so much I have a shell function, `nenv`, which creates a new virtualenv with a specific Python and then loads its dependencies into the virtualenv. It gives me tremendous freedom. For example, I can heavily instrument other modules' Python code inside the virtualenv (to find their bugs, e.g.) and then throw it all away and recreate it fresh in a few keystrokes. --- There are OK, well-known solutions to most of the common packaging and distribution problems with Python programs you might have. If you go back to it, you should spend a bit of time with this, it isn't that bad. (Poetry seems really cool - when I start something new it'll be with that.)
- dijit 4y ago
  it's weirly naive to assume I don't know about pip as a python user as it's a bit ubiquitous. That said: This is very much a developers take on the packaging situation in python. Running virtualenvs is "fine" until you're not connected to the internet, a less-and-less common scenario thankfully. pip itself (without virtualenvs) will "dirty" the system, or you use the --user flag and make it work only for one user. The situation for systems administrators is to do things that do not mess with the developers, if I install a package, especially with a version lock, and it directly conflicts with a developers (less and less of a problem with containers!) then they're going to be very cross with me.
  - keymasta 4y ago
    This may be a silly question, but how would you think to install packages if not with pip? I used to see python the same way, and coding on my megalithic single file would always take a couple hours to set up on a fresh computer. Then I discovered requirements.txt, where you simply list each package you need and the version (range) desired and then run: pip install -r requirements.txt this will install everything unless it's fucky like for example, pip install kivy-garden.matplotlib will not work with pip but everything else does.
    - Annatar 4y ago
      "This may be a silly question, but how would you think to install packages if not with pip?" Through the native software management subsystem: RPM, SVR4 packaging, pkgsrc, MSI... always use the native software management subsystem - that is what it is there for, for developers to deliver their software with.
  - Annatar 4y ago
    "Running virtualenvs is "fine" until you're not connected to the internet, a less-and-less common scenario thankfully." Any high security environment (read: the financial industry) will have most of the servers purposely not connected to the InterNet, to prevent people from doing exactly the above and from attackers hacking in. Energy and pharmaceutical industries - same thing. That's the norm, not the exception, so pretty much any industry which is critical for society at large won't allow access to the InterNet.

TomSwirly 4y ago

Did Python pee in your teacup once or what? (Why is Python hard to debug compared with shell? Python has a debugger - does Bash?)

Annatar 4y ago
Python "peed in my teacup" many, many times: every time I run Mercurial, Python shits on me from Earth's orbit because the piece of crap language is so slow. And that is just one example among many. "Bash"? Is that all you know, "bash"? I wasn't writing about that GNU crap of a shell, but of real, AT&T Bourne or Korn shell! Debugging shell is trivial with set -x. I can find a problem in a shell program in seconds.

xigoi 4y ago

You say that Python is slow, as if shell wasn't slow?

Annatar 4y ago
shell is ultra fast, and it's very easy to squeeze performance out of shell programs. Like I wrote, shell is a well understood programming language - it's been around for almost 50 years and generations and generations have grown up on it professionally.
- 411111111111111 4y ago
  To be fair, the startup speed of the shell is generally considered pretty slow/expensive in comparison to running everything in a single shell/executable.
  - Annatar 4y ago
    That's only a problem in real life if you're running SmartOS's pkgsrc build farm. And even then, there are techniques: Johnatan Perkin described them in length on his blog. Search for it.
- v3ss0n 4y ago
  You are just assuming. Try benchmarking shellscript and compare to python with same functionality and then come back.
  - Annatar 4y ago
    I am not assuming, I do this daily so I know what I'm writing about. And as if that were not enough, I have formal education in shell programming as part of my degree.
    - justinsaccount 4y ago
      Hah. Like the time you tried to tell people that grep -r was not real unix, and that they should use the vastly slower combination of find + xargs + grep? https://news.ycombinator.com/item?id=20633546 https://news.ycombinator.com/item?id=20633546 You are the embodiment of the Dunning–Kruger effect.