161–170 of 220 posts
Earlier quoted context omitted.
These aren’t always separate. Some distos might try to support multiple versions of a library. That could require installing it to different prefixes instead of the default. Thus, the build system will have to comprehend that.
Not everything in the world revolves around Linux. Distros terrible choices around shared library architecture has nothing to do with build systems for most languages.
Earlier quoted context omitted.
The title is provocative and attention grabbing. -- It's completely fair game to react to the provocation rather than the substance of the article itself. (Or, rather, it's silly to use attention grabbing rhetoric, then complain that people paid attention to the rhetoric). I'd prefer instead a more balanced title like "Remember to Consider the Costs When Using Package Managers", or whatever.
> It's completely fair game to react to the provocation rather than the substance of the article itself. Yeah, but its down right stupid to do so. The title isn't even misleading or part of a Motte-and-bailey argument. People just hear "Package Managers are Evil" and assume that the author means you shouldn't use third party dependencies. Which is NOT what's being argued. But I guess you'd know that, if you read pass…
I think you're splitting hairs if you're saying that these points from the article argue against package managers but don't argue against using third party dependencies.
I similarly think you're splitting hairs if to consider "package managers are useful?" and "third party dependencies are useful?" as distinct points.
Earlier quoted context omitted.
The Author isn't arguing for not using third party dependencies. He's arguing for developers to be more conscious of the dependencies they use, by manually vetting and handling them. That screams "I've been down the package manager route and paid the price". Not inexperience.
> He's arguing for developers to be more conscious of the dependencies they use "be careful all the time" doesn't scale. Half of all developers have below-average diligence, and that's a low bar. No-one is always vigilant, don't think that you're immune to human error. No, you need tooling, automation to assist. It needs to be supported at the package manager side. Managing a site where many files are uploaded, and t…
NPM is also quite a wild west when it comes to publishing packages, any kid can make an account and publish 'left-pad' kind of crap.
We already have quite safe and working setup with APT and software repositories for Debian, Ubuntu etc. While it is not so easy to publish your software to Debian, you get dedicated maintainer and all kinds of requirements you have to fulfill.
But this way all the issues with trust are if not mitigated, they are minimized and for example XZ Utils hack didn't make it to production systems and it took 3 years to prepare and pull it off.
Earlier quoted context omitted.
Those are library/package collections which contain multiple different packages, not the packages themselves. And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions.
> And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions. I'm talking about post 1.0 language choices: - Choose backwards compatibility. Packages frozen in time, you get "Packages go to std to die." - Choose to break backwards compatibility. The ecosystem is split, some choose to go Odin 2 some are Odin 3.
"When using Go for example, you don’t need any third-party libraries to make a web server, Go has it all there and you are done." Fine, now what if you need to connect to a database, or parse a PDF, or talk to a grpc backend. What a hilariously short-sighted example. To me, this whole article just screams inexperience.
Inexperience of an author who develops quite successful programming language for like 10 years? Quite a bold statement. Actually his perspective is quite reasonable. Go is in the other part of the spectrum than languages encouraging "left-pad"-type of libraries, and this is a good thing.
I see this a lot with Rust where I will depend on one or two external crates for a simple application and then I am shocked to see dozens of dependencies being pulled in when I go to build. I actually think Cargo's support for feature gates and conditional compilation could in theory be a strong mitigation against this as crates can avoid pulling in dependencies unless you actually need a feature that relies on them,…
Rust’s big issue here is the anemic standard library. I think overall the strategy makes some amount of sense; since there’s so much crazy alchemy like depending on nightly, no_std, etc in Rust, including stuff in std has more downside in Rust than in a language that’s more stable like Go. But it’s annoying to have to deal with 3 different time libraries and 3 different error creation libraries and 2 regex libraries…
Earlier quoted context omitted.
It doesn't necessarily "manage" the packages. It just sees them in your project and compiles them. You manage them yourself.
If that's what happens, I think in the following claim: > Odin's compiler knows what a package is and will compile it into your program automatically. ...the word "automatically" should be dropped. Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that.
They often don't though. Rust, C, C++ need either long command line invocations or a build system for anything beyond hello world. Zig needs a build file for anything beyond hello world.
With Odin, you just invoke "odin build ." and all your dependencies are taken in without needing a build system, build file, make file, etc...
Earlier quoted context omitted.
> It's completely fair game to react to the provocation rather than the substance of the article itself. Yeah, but its down right stupid to do so. The title isn't even misleading or part of a Motte-and-bailey argument. People just hear "Package Managers are Evil" and assume that the author means you shouldn't use third party dependencies. Which is NOT what's being argued. But I guess you'd know that, if you read pass…
In the article, the author does say "I am not advocating to write things from scratch", while also describing third party dependencies as liabilities (e.g. security vulnerabilities), that people are too trusting of third party dependencies, that people overestimate the quality of third party dependencies. I think you're splitting hairs if you're saying that these points from the article argue against package managers…
Third party dependencies absolutely are liabilities. You are liable to vet them, inspect their licenses and keep them updated while ensuring that they continue working with your existing code.
This is not something package managers help you do. Package managers like NPM make it trivial to skip these steps entirely.
What is being argued for, is a more thoughtful approach to handling third party dependencies. Or at the very least, the need for people to realise that there are costs associated with bringing third party dependencies into your codebase.
Its not splitting hairs at all. Its more of an presumption on the part of a large number of readers, that the 2 points argued conflate to "Package manager suck, because third party dependencies suck and you should write everything from scratch instead".
Earlier quoted context omitted.
> It's completely fair game to react to the provocation rather than the substance of the article itself. Yeah, but its down right stupid to do so. The title isn't even misleading or part of a Motte-and-bailey argument. People just hear "Package Managers are Evil" and assume that the author means you shouldn't use third party dependencies. Which is NOT what's being argued. But I guess you'd know that, if you read pass…
Sorry but I lack any respect for authors that use clickbaits. Call them put and move on seem the best approach.
You should try reading the article before passing judgement.
Its not like the article is called "5 facts that will make you hate package managers. Number 5 will shock you"