Re: Go (golang) packaging, part 2
Russ Allbery <firstname.lastname@example.org> writes:
> I keep being tempted to go off on a rant about how we have all of
> these modern, sophisticated, much more expressive programming
> languages, and yet still none of them handle ABI versioning as well as
> C does. Normal versioning problems that we just take for granted in C,
> such as allowing the coexistence of two versions of the same library
> with different ABIs on the system at the same time without doing the
> equivalent of static linking, vary between ridiculously difficult and
> completely impossible in every other programming language that I'm
> aware of (with the partial exception of C++ where it is possible to
> use the same facilities as C, just considerably more difficult).
> In fact, most new languages seem to be *regressing* here.
I don't think it's as clear-cut as that.
Debian handles multiple versions of C libraries at _runtime_ well, but I
think its support for C libraries still leaves a good deal to be
desired: it doesn't let you install multiple versions of -dev packages,
and it doesn't provide much in the way of tools to help you manage
multiple versions of libraries-and-headers that you've installed outside
the packaging system.
I think, for someone who wants an OS for software development, and wants
or needs to program against library versions newer than those that
Debian ships, Debian has better support for some of the newer languages
than it does for C.
(For example, as I understand it Python's virtualenv/venv stuff lets you
express "I want to see the standard library shipped with Debian's
Python, but otherwise only the locally-installed libraries I specify".
That's annoying to do with C because all the headers are jumbled
together in /usr/include.)