I can't disagree with you, but you're also missing other issues related with having a big pile of dependencies. Maintainability being one. Runtime efficiency isn't the only problem that can be solved here.
I don't have a lot of experience with it myself, but I don't like the package/dependency management. I'm used to the JVM way where you bundle your third party libraries per project as opposed to installing them on your system.
Other than that, there is really not much that I don't like. I think it's one of the best languages I've tried and I wish it was more widely used in the industry.
I agree with the points you've made, but I would also posit that adding a dependency using this mutable package manager is making a commitment to maintain the integrity of that dependency, which is arguably more work than maintaining the handful of lines of code.
The disadvantage is very mild, and the advantage huge (modularity and ability to easily go embedded). If your dependency manager cannot express "program[+feature]", it is your dependency manager's problem.
What problems? Package dependency problems? The worse that I've had happen is having to deal with broken packages. The amount of times I haven't had to deal with figuring out dependencies makes it more then worthwhile, IMHO.
Adding a mechanism for dependencies which kind of sometimes sort of works but doesn't actually work is much much worse than just not implementing anything at all as you are much less likely to get anyone too put in the work required to do the hard thing they need to do for it to actually work.
Hi, I would like to know what's wrong with a lot of dependencies? One disadvantage I know is long compile time and maybe a little larger binary size, but I don't think it's too bad.
Every dependency is one more thing that can go wrong in my mind. I always drop them at every opportunity.
There are some exceptions. Like I really don't want form building to be in the standard library, and I don't want to write it myself.
It is nice when your package manager only takes a short manage to fetch and build though, and you can have more confidence that any mistakes will be your own (under your control) rather than someone else's.
Dependencies can be very good, they can provide enormous leverage to actually solve your problems and share the burden of common problems like parsing a json string or compressing to gzip or whatever. In theory at least.
On the other hand, I think a large part of the problem actually comes from dependency managers being a bit too good. It's easy to pull some library and not realize the dependency has massive root system of transitive dependencies, and once that gets settled in your code base it may be difficult to get out.
I think the real problem isn't dependencies themselves, but when dependencies are expected to have dependencies in themselves. I don't think what you get in the end is good, robust software. It gets a sort of flimsy quality where stuff keeps breaking and falling apart and that's just the way it is.
Hey, just found out I'm on HN thanks to the Raku blog.
What I meant with terrible package management is shared by all scripting languages. Having all dependencies always requires some sort of setup. Many scripting languages try to address that, e.g. with tools like pipenv, but things rarely work flawlessly. If you use a scripting language, you have to bother with this when you want to use the program, and I find that annoying. Rust does this to you too, and also there, it doesn't always work flawlessly, but at least that's a compile time problem. Once you have a binary, you don't need to deal with that anymore.
If you cannot just run a script, scripting languages lose most of their appeal. At least for me. And package managing has exactly this effect.
PS: also thanks for pointing out how to reduce that to two lines. :D
Dependency management is a huge weakness in golang and there isn't much point in debating it.
That said, my time in golang has crystalized something I'd been leaning towards anyway, that is dependencies are way more dangerous than we think they are. I find all of my code now (golang or otherwise) less likely to have dependencies, and therefore dependency management weaknesses are mitigated (not solved).
A lot of people in the comments here aren't happy with people using tons of dependencies, but what else do you expect from ecosystems that (a) make it easy to download and publish packages and (b) don't have much of (b') a standard library or (b'') set of blessed solutions?
This isn't a case of 'oh, python (javascript, etc) programmers are dumb and lazy'. If C++ had a packaging system and it wasn't so horrible to add third party dependencies we'd be seeing the same thing there.
The second biggest flaw is that it couples package management to a programming language, despite those being almost completely unrelated concerns.
reply