Hacker News Reader

Comment by the_gipsy | Hacker News Reader

You played this on C, but there is nothing about C that makes this special. You can do this with python, javascript, rust, go... except java maybe. Just imply that the compiler and build systems are installed. There is nothing special in C about implementing some terminal escape sequences that couldn't be done elsewhere.

Actually, C is worse: it could all be any compiler/version, make version, or ncurses lib version - nothing is fixed, not even documented. At least in other language there is some standard way of pinning dependencies.

View on HN

> You played this on C, but there is nothing about C that makes this special.

Yes there is something special about C (on Unix/Linux). C is the mother tongue of Unix so it's more intertwined with the system than anything else (other than shell scripting also). You'll nearly always have cc installed. The libraries you need are often in /usr/lib as part of the OS install.

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

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.

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.

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.

> 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.

-I $PATH_TO_INCLUDE -L $PATH_TO_LINK_AGAINST

> 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.

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.

A lot of pain comes from OS apis which are not supported in the standard library, like graphics, audio, and media. These inevitably need libraries and frameworks to work cross-platform.

This is also true in C... you make an excellent point: that for toy programs the default stdlib for any given language is often sufficient.

Reply on news.ycombinator.com