Fuck that. It’s awesome! I want to have lazy initialized globals. It’s that package. I want code to shorten my builder pattern I import that. I need a typed concurrent work steel queue. No problem.
I look at a c project. Everywhere custom macros to do the most basic shit. I want to parse an xml in c? Better use a sax Parser and put all the data into globals. Cryptography? Better implement that ourselves… Using a library would be too much of a hassle.
NPM is already on the “isn’t” side of it. Specially with all the malware going around. Who has time to read the code of the dependencies of the dependencies of their dependencies? For every single version. It’s just not possible…
I guess the main concern with this is security. You’re literally running code you don’t even know about on your machine, probably next to personal files or your company’s code base.
A simple http call to publish all your private code wouldn’t be hard to sneak in a 6th level dependency.
There’s a password manager I use, but the CLI tooling sucks. Thankfully, there’s a third party CLI tool in a language I know fairly well, and because I’m a little paranoid, I reviewed the code. Then I reviewed the code of the libraries it imported. And then the code of the libraries of the libraries it imported. Thankfully, that was as far as it went, and I was mainly looking for any code that made network calls… it was manageable, just barely.
And I made some improvements and submitted PRs, only some of which were accepted, but I used them so I maintained a fork. Which was lucky, because a few months later upstream changed their parseargs library to a framework, and the dependencies exploded. 6 layers deep, and dozens of new dependencies - utterly unauditable without massive effort. I caught it only because of the rebase from upstream. I abandoned the rebase and now maintain a hard fork, of which I’m the only user AFAIK.
The moral of the story is that introducing dependencies under the guise of “reuse” is a poisoned fruit, a Trojan Horse. It sounds good, but isn’t worth it in the long run. The Go team got it right with their proverb: a little copying is better than a little dependancy.
Honestly, I don’t like the Go way. If they are going to have that philosophy, at least they should have provided a strong core with high level functions and generics. From the start. Not 5 years later.
Fuck that. It’s awesome! I want to have lazy initialized globals. It’s that package. I want code to shorten my builder pattern I import that. I need a typed concurrent work steel queue. No problem.
I look at a c project. Everywhere custom macros to do the most basic shit. I want to parse an xml in c? Better use a sax Parser and put all the data into globals. Cryptography? Better implement that ourselves… Using a library would be too much of a hassle.
I mean, it’s awesome until it isn’t.
NPM is already on the “isn’t” side of it. Specially with all the malware going around. Who has time to read the code of the dependencies of the dependencies of their dependencies? For every single version. It’s just not possible…
I guess the main concern with this is security. You’re literally running code you don’t even know about on your machine, probably next to personal files or your company’s code base.
A simple http call to publish all your private code wouldn’t be hard to sneak in a 6th level dependency.
So, to expound on this a little…
There’s a password manager I use, but the CLI tooling sucks. Thankfully, there’s a third party CLI tool in a language I know fairly well, and because I’m a little paranoid, I reviewed the code. Then I reviewed the code of the libraries it imported. And then the code of the libraries of the libraries it imported. Thankfully, that was as far as it went, and I was mainly looking for any code that made network calls… it was manageable, just barely.
And I made some improvements and submitted PRs, only some of which were accepted, but I used them so I maintained a fork. Which was lucky, because a few months later upstream changed their parseargs library to a framework, and the dependencies exploded. 6 layers deep, and dozens of new dependencies - utterly unauditable without massive effort. I caught it only because of the rebase from upstream. I abandoned the rebase and now maintain a hard fork, of which I’m the only user AFAIK.
The moral of the story is that introducing dependencies under the guise of “reuse” is a poisoned fruit, a Trojan Horse. It sounds good, but isn’t worth it in the long run. The Go team got it right with their proverb: a little copying is better than a little dependancy.
Honestly, I don’t like the Go way. If they are going to have that philosophy, at least they should have provided a strong core with high level functions and generics. From the start. Not 5 years later.