4 ms·

I think this is partially caused by the frankly anemic standard library some languages come with. Take node for example, it tooks years (almost a decade?) for "

I think this is partially caused by the frankly anemic standard library some languages come with. Take node for example, it tooks years (almost a decade?) for "fetch" to be available and you still can't connect to a database without external libraries, so you need to install those which then bring in their own dependencies because the standard library is so limited...

masklinn 3y ago
“Go” is cited as one of the problematic ecosystems and it’s generally considered a “batteries included” language. The problem is not anemic standard libraries, it’s ecosystems where vendoring is common, because will unvendor packages so you use whatever debian ships. Which on one hand is understandable, if they ship a security fix in one of their packages they want every dependent on the system to get that fix, on the other hand there’s no guarantees whatsoever the package works once unvendored.
- mananaysiempre 3y ago
  > there’s no guarantees whatsoever the package works once unvendored. And it’s precisely the job of the maintainer to ensure that it does, and more generally that all the various things that they ship together not conflict with each other. Assembling a coherent system despite each individual developer’s understandably narrow view—in explicit opposition to that view, if need be,—is and always was a distro maintainer’s job description. Unfortunately, the bug reporting story has become worse over time. GNU packages included a configuration-time override for the bug reporting email to accomodate distributions and other modifications, but in most software today you’ll more often see a hardcoded link to the upstream homepage. And of course people will often just ask Google for the bug tracker address instead. This leads to understandable annoyance on the part of upstream developers. (It still doesn’t make acting against their intent improper in any way, though.)
loloquwowndueo 3y ago
Do database drivers belong in a languages standard library? I think not, to be honest.
- RedShift1 3y ago
  php has PDO which is a nice abstraction over all the database drivers it has.
  - philipwhiuk 3y ago
    PDO is an abstraction over SQL implementations, which is only 'all databases' if you stopped looking at databases in the early 00s.
alexvitkov 3y ago
Not sure there's a corelation here, Node has a much more featureful library than say C, and there's still a dependency hell there and not in C.
- bkallus 3y ago
  C makes it too inconvenient to pull in 300 dependencies. I think the recipe for dependency hell is insufficient stdlib + decent included package manager.
- michaelt 3y ago
  C developers basically invented vendoring - loads of C libraries are distributed as "the whole library is in a single .h file, just copy it into your repo"
zozbot234 3y ago
TBH it's mostly caused by the lack of consistent semver use in the npm ecosystem, which in turn is driven by JavaScript being a highly dynamic language and not being designed for programming 'in the large'. The whole point of semantic versioning is to make it possible to auto-upgrade dependencies to the latest compatible version, at which point devendoring a dependency and packaging it separately starts to make a lot of sense. If every dependency upgrade requires a complex review of the code, there's no point in devendoring since it will just result in lots of bespoke package versions adding pointless clutter to the archive.

masklinn 3y ago

“Go” is cited as one of the problematic ecosystems and it’s generally considered a “batteries included” language. The problem is not anemic standard libraries, it’s ecosystems where vendoring is common, because will unvendor packages so you use whatever debian ships. Which on one hand is understandable, if they ship a security fix in one of their packages they want every dependent on the system to get that fix, on the other hand there’s no guarantees whatsoever the package works once unvendored.

mananaysiempre 3y ago
> there’s no guarantees whatsoever the package works once unvendored. And it’s precisely the job of the maintainer to ensure that it does, and more generally that all the various things that they ship together not conflict with each other. Assembling a coherent system despite each individual developer’s understandably narrow view—in explicit opposition to that view, if need be,—is and always was a distro maintainer’s job description. Unfortunately, the bug reporting story has become worse over time. GNU packages included a configuration-time override for the bug reporting email to accomodate distributions and other modifications, but in most software today you’ll more often see a hardcoded link to the upstream homepage. And of course people will often just ask Google for the bug tracker address instead. This leads to understandable annoyance on the part of upstream developers. (It still doesn’t make acting against their intent improper in any way, though.)

loloquwowndueo 3y ago

Do database drivers belong in a languages standard library? I think not, to be honest.

RedShift1 3y ago
php has PDO which is a nice abstraction over all the database drivers it has.
- philipwhiuk 3y ago
  PDO is an abstraction over SQL implementations, which is only 'all databases' if you stopped looking at databases in the early 00s.

alexvitkov 3y ago

Not sure there's a corelation here, Node has a much more featureful library than say C, and there's still a dependency hell there and not in C.

bkallus 3y ago
C makes it too inconvenient to pull in 300 dependencies. I think the recipe for dependency hell is insufficient stdlib + decent included package manager.
michaelt 3y ago
C developers basically invented vendoring - loads of C libraries are distributed as "the whole library is in a single .h file, just copy it into your repo"

zozbot234 3y ago

TBH it's mostly caused by the lack of consistent semver use in the npm ecosystem, which in turn is driven by JavaScript being a highly dynamic language and not being designed for programming 'in the large'. The whole point of semantic versioning is to make it possible to auto-upgrade dependencies to the latest compatible version, at which point devendoring a dependency and packaging it separately starts to make a lot of sense. If every dependency upgrade requires a complex review of the code, there's no point in devendoring since it will just result in lots of bespoke package versions adding pointless clutter to the archive.