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 Also languages with first-class packages tend to be really hard to package in actual distros.

@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 CPAN comes from a time where 1tb SSDs weren't really a thing, so I wouldn't be surprised if it was just designed better due to the constraints people were living with. Nowadays, there's no "need" to bother to think about good design, if you can "solve" the problem by just creating another 100mb directory with all the garbage your project needs.

@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)

@mngrif @sir version pinning, vendoring and build systems that require an internet connection are just symptoms of a widespread lack of discipline in each language’s developer communities.

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.

Controversial yes, true also yes.
I stumbled upon this project recently:

The technical part can be summarised as literally 'curl -L | sed ... >' 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.

@ck @sir

Why does it even download anything?! The file is already in the repository!

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

@ignaloidas @sir
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.

@ck @sir Well, asyncore is now deprecated. I think that python is almost at the point where you will probably use something only if it's too big to write it yourself with the exception of requests, which should get into the standard library.

@ignaloidas @sir
True, but had it not been accepted into the stdlib, it would have just died away years ago without having to receive maintenance and whats basically a language overhaul for over two decades now.

@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

@sir interesting.

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'

Silly, not?

@zig @sir something that would actually make some sense, is requiring all packages to be cryptographically signed (off) by implementor. The resulting checksum must be included in the relationfile.

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

@berkes @sir I will put together some notes about my idea. The short answer: imagine a content-addressable peer-to-peer code cooperation system, that include peer review and FOAF. Read on and unison. Maybe ETH can help, but I am still clue less about it.

@zig @sir Look at IPFS, or DAT. I am certain those are a perfect fit for libraries.

I had this idea for Rubygems on IPFS, but shelved it, because there is little need, and therefore no community or busineddmodel (well, other than yet another scammy ICO).

@berkes @sir What about a trust system? Do you trust the person that created the signature?

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.

@sir I love how easy it is for me to just add a library I have a decent reason to trust in JavaScript.

I hate how easy it is for other people to just add a library I have no reason to trust in JavaScript.

I don't think the two are reconcilable.

@sir The APL approach of "Why the fuck would you ever use a library?" wins the prize for militant extremism again!

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

@lynne @sir
inb4 "threading is bad, you shouldn't use it"

@lynne @sir I have no clue what ominous crates you use - but you can debug foreign crates.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!