3 ms·

Meh, you can say the same about python, or a bash script for that matter.

jjav 3y ago
I did say the same about shell scripting. Python, no way. Now you have to start pip installing dozens of packages and then you run into dependency mess so then you reach for some tools to manage multiple environments and suddenly you're a few hours into what's become a project when all you wanted was to run a script.
- the_gipsy 3y ago
  It's definitely worse with C. Most projects just give you a general "you need X library". Unknown version. Check with your distro which of multiple (or none) package that might be. Then also the X-devel for the headers. Aaaaand then there's all the arcane configure script nightmares.
- squeaky-clean 3y ago
  You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? At least with python you can isolate those through venvs.
  - lelanthran 3y ago
    > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have and it wasn't a problem. I ran 32bit libs alongside 64bit libs for literal years without a problem.
  - anthk 3y ago
    -I $PATH_TO_INCLUDE -L $PATH_TO_LINK_AGAINST
  - jjav 3y ago
    > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have to say ... no. And I've worked on some very large C projects at times. Part of it is cultural. In the systems library space, there is a much stronger (nothing is perfect but I'll say much stronger) culture of compatibility awareness. Libraries don't break compatibility randomly without any planning unlike in less mature ecosystems (coughnpmcough). So you don't need to depend on libfoo 3.17.42 because neither 3.17.41 nor 3.17.43 work for you. That's not a thing. Part of it is how the system works. If you look under /usr/lib you'll notice libraries are versioned and have symlinks from major/minor version to them. Different versions coexist and you can link accordingly. Even if you have (rare) badly-behaved library authors who break compatibility, it's not an issue to have multiple versions and each program links to the one it needs.
- jethro_tell 3y ago
  Heh, python is stock now on the EL distros since dnf became the package manager. Kinda insane for the base of your os but, hey runs on servers wo who cares.

jjav 3y ago

I did say the same about shell scripting. Python, no way. Now you have to start pip installing dozens of packages and then you run into dependency mess so then you reach for some tools to manage multiple environments and suddenly you're a few hours into what's become a project when all you wanted was to run a script.

the_gipsy 3y ago
It's definitely worse with C. Most projects just give you a general "you need X library". Unknown version. Check with your distro which of multiple (or none) package that might be. Then also the X-devel for the headers. Aaaaand then there's all the arcane configure script nightmares.
squeaky-clean 3y ago
You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? At least with python you can isolate those through venvs.
- lelanthran 3y ago
  > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have and it wasn't a problem. I ran 32bit libs alongside 64bit libs for literal years without a problem.
- anthk 3y ago
  -I $PATH_TO_INCLUDE -L $PATH_TO_LINK_AGAINST
- jjav 3y ago
  > You've never run into a problem where 2 C projects require a some shared system library but require incompatible versions? I have to say ... no. And I've worked on some very large C projects at times. Part of it is cultural. In the systems library space, there is a much stronger (nothing is perfect but I'll say much stronger) culture of compatibility awareness. Libraries don't break compatibility randomly without any planning unlike in less mature ecosystems (coughnpmcough). So you don't need to depend on libfoo 3.17.42 because neither 3.17.41 nor 3.17.43 work for you. That's not a thing. Part of it is how the system works. If you look under /usr/lib you'll notice libraries are versioned and have symlinks from major/minor version to them. Different versions coexist and you can link accordingly. Even if you have (rare) badly-behaved library authors who break compatibility, it's not an issue to have multiple versions and each program links to the one it needs.
jethro_tell 3y ago
Heh, python is stock now on the EL distros since dnf became the package manager. Kinda insane for the base of your os but, hey runs on servers wo who cares.