Likely controverisal take:
Languages with first-class package managers that make it really easy to use dependencies are a case where ease-of-use and usability might be actively harmful. It encourages developers to NOT audit their dependencies, and eventually leads to node_modules, which eventually leads to leftpad. Having fewer dependencies because adding depenedencies is annoying is not actually necessarily a bad thing.
@sir except if one does integrate the review tool, social network and editor, somekind of integrated dev environment.
@sir that is make very easy to re-use existing libraries but stay aware of existing issues and reviews (unlike pypi and npm)
@sir they also inherently create a need for tools like venv to curate multiple applications on the same host.
i'm *amazed* i haven't needed to do this for perl at any point. maybe CPAN really is that good.
@mngrif @sir my experience with the python ecosystem is that everything that touches django is pure shit, and the rest is okay and you can just install your distro’s packages. most non-django projects don’t have the 20 layers deep dependency trees that are so common in other languages with their own package management.
(in general, things having usable library/module packages in major linux distributions is a sign of a working ecosystem, which is why rust, go, ruby and node are all failing horribly)
if you have to pin versions and keep copies of your dependencies to ensure that your software works, you have bad software development practices that will result in bad and insecure software.
even if it’s written in rust.
The technical part can be summarised as literally 'curl -L | sed ... > file.name' and it has almost 5000 lines of dependencies in package-lock.json ...
This has basically confirmed for me that people have given up on actually understanding what they are doing and just producing any kind of output is considered acceptable. Doing something seems to trump thinking more often then not.
@sir I think having the builtin stdlib is what has kept python from getting completely into a node modules situation. Like pypackaging has plenty of issues but different ones
@sir They also tend to fall into one of the two categories: either you need packages for the things that should have been in the standard library anyways, or you only need packages that you would use even if it was hard to use packages. But sadly the second category is a lot rarer.
I would not necessarily agree with this.
Most standard libraries have accepted code with good intentions that turned out to be poorly designed and / or hard to use (think python asyncore for example). Because it's the standard library, those packages will likely live forever and maintain their bad interfaces indefinitely. I think batteries included should be the case for essentials, like crypto, testing, low level IO etc. but not much else.
@sir That's an interesting take, and I'm not sure that you're wrong... There is obviously a middle ground because god help me if I'm going to reimplement TLS every time I make a new web backend service or Rust's chrono every time I need to keep track of dates/times.
@sir I learned about the leftpad debacle just last summer. mindblow
But when you turn it around, it becomes rather absurd.
Lets assume a world in which all package managing in all common languages was easy and frictionless.
Would it then be 'good' if one language introduced artificial barriers or complexities for using packages?
Say, instead of
'from SecureRandom use UUID'
it now requires
'yes_i_have_evaluated SecureRandom and_i_hereby_solemly_swear_that_i_will_keep_an_eye_on UUID and_all_its_depedencies'
And to require any lib to be cryptographically signed by author, with an expiring key.
This adds security (lots) in exchange for friction.
Rather than virtual friction (that is dead easy to automate away).
To be certain, like any peer-to-peer system, you need to verify. The fast path is verify the signature against the signature of the maintainer (or FOAF) or verify the code recursively until you find trusted code.
I don't think the two are reconcilable.
@sir Agreed in the sense that it adds friction to introducing a dependency which likely means fewer dependencies and increases likeliness that the developer will actually look through the dependencies' source code.
But at the same time, said increased friction likely means that vulnerable dependencies end up being updated less frequently.
@sir Rust is the worst in that respect. You can easily NIH a bitstream writer or you can do it the rust way, use a black box unmaintained bitstream writer that you cannot touch. This made debugging a nightmare.
Or how you could write your own threading code or you could let rayon parallelize a for loop for you. And since it understands nothing about your code, you don't get the performance you'd expect.
But if you don't use all crates or use unsafe code, you're an enemy to the community.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!