4 ms·

> People have been making jokes about node_modules for a decade now, but this problem is just as bad in Rust codebases I've seen I agree... but I think this is

by slily 3y ago

> People have been making jokes about node_modules for a decade now, but this problem is just as bad in Rust codebases I've seen I agree... but I think this is more indicative of a cultural problem than a language design/standard library scoping problem. A compact standard library is more resistant to scope creep. I don't want every language to end up like C++, and I think keeping the scope of the standard library small helps avoid that. On the other hand, popular third-party libraries that provide common functions have too many third-(fourth-?)party dependencies. Keeping dependency trees small should be a priority for such tools, but convenience trumps all right now so it isn't valued as it should be.

no_wizard 3y ago
one way to approach this with compromise is to keep the shipped standard library small, but have officially maintained packages from the language foundation for exceedingly common functionality. That gives an avenue for exploration, and tight controls and quality control on packages, without bloating the standard library.
- MBCook 3y ago
  What’s so bad about “bloating the standard library”? Java has an incredible amount of stuff and it’s incredibly useful. The compiler should be able to eliminate the unused parts during compilation, it’s not like adding JSON to the standard library is going to make a “hello world” program bigger.
  - shit_game 3y ago
    >The compiler should be able to eliminate the unused parts during compilation, it’s not like adding JSON to the standard library is going to make a “hello world” program bigger. I agree. I would argue against keeping standard libraries terse as an appropriate goal for a language because terse (or alternatively, inadequate) standard libraries are exactly what necessitate third party libraries for common functionality, which in turn lead to this dependency hell that so many people dislike so much. Not to say that a standard library should do absolutely everything, but the more capable a language is out of the box, the fewer third party libraries a language ecosystem will come to rely on, meaning that methodologies will be more consistent in more code and dependency management will be simpler.
  - theLiminator 3y ago
    Mostly because it holds the language back due to backwards compatibility concerns.
- theLiminator 3y ago
  I wish languages took this approach, not sure why they largely don't.
coldtea 3y ago
>A compact standard library is more resistant to scope creep I don't see "scope creep" as a problem. I see "Lack of standard library support for X brought 5 competing libraries for the same X functionality, no de facto standard, and projects using incompatible implementations and versions, maintained in different states of disarray" as a problem. Never had a problem with Python standard library having "scope creep" for example. Where I do have problem is where there are several competing libraries and no single well supported one you can always depend on for some - which happens for things not in the standard library.
- tialaramex 3y ago
  > which happens for things not in the standard library. So to be clear you don't use Requests right? Because there is HTTP client handling right in the Python standard library, and yet it sure seems like most Python programmers use Requests, because it's better.
  - coldtea 3y ago
    Did you miss the part where I say "[and] no de facto standard"? Requests is a de facto standard, and I do use it. But besides having a clear, well maintained, de facto standard being OK too (as I wrote), it's also great that I don't have to use Requests, as I can write for urllib3 and know that my project will just work everywhere with no added deps - which I do for simpler stuff. Heck Requests itself is using urllib under the covers, which also has some benefits of uniform implementation of protocols and such.
    - tialaramex 3y ago
      You said that the stdlib needs to provide it first, you were very clear about that. So a "de facto standard" can't in fact exist, such claims while they probably feel correct to you make a mockery of your demand that the stdlib should do it first - if it did then Requests can't exist. And for what it's worth I agree with you about that doing it first, on the whole a stdlib should aim to do it first if they're doing it at all. Take Microsoft's belated decision to ship a JSON implementation for .NET. Obviously meanwhile a de facto standard took hold, Newtonsoft, and of course the Microsoft library isn't a drop-in replacement. Result, more complexity, more training, negligible real benefit. I just disagree that they should aim to do it all.
duped 3y ago
If cargo did literally any garbage collection then it wouldn't be a problem. Most of the nonsense in a target/ directory are stale incremental build artifacts.
- menaerus 3y ago
  The problem as I understand it is not about the stale dependency artifacts in xyz directory but with the (transitive) (hell) dependency management itself. cargo makes it incredibly easy to pull in the shitload of dependencies of whom you don't have a slightest idea.
pornel 3y ago
The problem is that a typical built-in standard library can't change or remove any APIs, even the ones that turned out to be mistakes or became obsolete, without breaking users. Eventually all the fancy standard parts of it get easier, faster, cleaner 3rd party replacements, and everyone is saddled with a dilemma of using the meh stdlib or a 3rd party dependency anyway. OTOH functionality shipped as external libraries can be versioned, upgraded, and replaced by users individually, on their own schedule. The obsolete cruft can be pulled in by old projects that still need it, without burdening new projects with the same old APIs (but they still can interoperate, because multiple versions of the same library can coexist!) For very long-lived languages (which Rust has ambition to be) a one-size-fits-all built-in big standard library is a big risk. The bigger it is, the less obvious and less timeless the APIs are. A basic Vec is easy to get right on the first try, but networking is a moving target, fashions for file formats come and go, threads/green threads/callbacks/promises/await come and go, parsers can be designed in many differently-bad ways, and OSes change — we don't have non-binary files any more, but ossified languages do! WASM/WASI has upturned even Rust's barebones standard library, and Fuchsia would even more. This risk of maintaining mistakes forever eventually makes maintainers of the standard library overly cautious, and design very defensive opaque non-committal APIs. IMHO languages should not have any single built-in unversioned library at all. Pull in what you use, in a version that makes sense this year, without the baggage that every API has to remain unchanged forever, and still be sensible and efficient half a century later, even on an OS that doesn't exist yet on hardware that hasn't been invented yet.

by slily 3y ago

no_wizard 3y ago

one way to approach this with compromise is to keep the shipped standard library small, but have officially maintained packages from the language foundation for exceedingly common functionality. That gives an avenue for exploration, and tight controls and quality control on packages, without bloating the standard library.

MBCook 3y ago
What’s so bad about “bloating the standard library”? Java has an incredible amount of stuff and it’s incredibly useful. The compiler should be able to eliminate the unused parts during compilation, it’s not like adding JSON to the standard library is going to make a “hello world” program bigger.
- shit_game 3y ago
  >The compiler should be able to eliminate the unused parts during compilation, it’s not like adding JSON to the standard library is going to make a “hello world” program bigger. I agree. I would argue against keeping standard libraries terse as an appropriate goal for a language because terse (or alternatively, inadequate) standard libraries are exactly what necessitate third party libraries for common functionality, which in turn lead to this dependency hell that so many people dislike so much. Not to say that a standard library should do absolutely everything, but the more capable a language is out of the box, the fewer third party libraries a language ecosystem will come to rely on, meaning that methodologies will be more consistent in more code and dependency management will be simpler.
- theLiminator 3y ago
  Mostly because it holds the language back due to backwards compatibility concerns.
theLiminator 3y ago
I wish languages took this approach, not sure why they largely don't.

coldtea 3y ago

>A compact standard library is more resistant to scope creep I don't see "scope creep" as a problem. I see "Lack of standard library support for X brought 5 competing libraries for the same X functionality, no de facto standard, and projects using incompatible implementations and versions, maintained in different states of disarray" as a problem. Never had a problem with Python standard library having "scope creep" for example. Where I do have problem is where there are several competing libraries and no single well supported one you can always depend on for some - which happens for things not in the standard library.

tialaramex 3y ago
> which happens for things not in the standard library. So to be clear you don't use Requests right? Because there is HTTP client handling right in the Python standard library, and yet it sure seems like most Python programmers use Requests, because it's better.
- coldtea 3y ago
  Did you miss the part where I say "[and] no de facto standard"? Requests is a de facto standard, and I do use it. But besides having a clear, well maintained, de facto standard being OK too (as I wrote), it's also great that I don't have to use Requests, as I can write for urllib3 and know that my project will just work everywhere with no added deps - which I do for simpler stuff. Heck Requests itself is using urllib under the covers, which also has some benefits of uniform implementation of protocols and such.
  - tialaramex 3y ago
    You said that the stdlib needs to provide it first, you were very clear about that. So a "de facto standard" can't in fact exist, such claims while they probably feel correct to you make a mockery of your demand that the stdlib should do it first - if it did then Requests can't exist. And for what it's worth I agree with you about that doing it first, on the whole a stdlib should aim to do it first if they're doing it at all. Take Microsoft's belated decision to ship a JSON implementation for .NET. Obviously meanwhile a de facto standard took hold, Newtonsoft, and of course the Microsoft library isn't a drop-in replacement. Result, more complexity, more training, negligible real benefit. I just disagree that they should aim to do it all.

duped 3y ago

If cargo did literally any garbage collection then it wouldn't be a problem. Most of the nonsense in a target/ directory are stale incremental build artifacts.

menaerus 3y ago
The problem as I understand it is not about the stale dependency artifacts in xyz directory but with the (transitive) (hell) dependency management itself. cargo makes it incredibly easy to pull in the shitload of dependencies of whom you don't have a slightest idea.

pornel 3y ago

The problem is that a typical built-in standard library can't change or remove any APIs, even the ones that turned out to be mistakes or became obsolete, without breaking users. Eventually all the fancy standard parts of it get easier, faster, cleaner 3rd party replacements, and everyone is saddled with a dilemma of using the meh stdlib or a 3rd party dependency anyway. OTOH functionality shipped as external libraries can be versioned, upgraded, and replaced by users individually, on their own schedule. The obsolete cruft can be pulled in by old projects that still need it, without burdening new projects with the same old APIs (but they still can interoperate, because multiple versions of the same library can coexist!) For very long-lived languages (which Rust has ambition to be) a one-size-fits-all built-in big standard library is a big risk. The bigger it is, the less obvious and less timeless the APIs are. A basic Vec is easy to get right on the first try, but networking is a moving target, fashions for file formats come and go, threads/green threads/callbacks/promises/await come and go, parsers can be designed in many differently-bad ways, and OSes change — we don't have non-binary files any more, but ossified languages do! WASM/WASI has upturned even Rust's barebones standard library, and Fuchsia would even more. This risk of maintaining mistakes forever eventually makes maintainers of the standard library overly cautious, and design very defensive opaque non-committal APIs. IMHO languages should not have any single built-in unversioned library at all. Pull in what you use, in a version that makes sense this year, without the baggage that every API has to remain unchanged forever, and still be sensible and efficient half a century later, even on an OS that doesn't exist yet on hardware that hasn't been invented yet.