5 ms·

This trend towards huge dependency trees has started to turn me off getting serious about learning software development. It seems like unless you want to make a

by dx87 6y ago

This trend towards huge dependency trees has started to turn me off getting serious about learning software development. It seems like unless you want to make a toy program, you end up with hundreds of dependencies, most of which are made by volunteers who could decide they don't feel like working on it any more. Even having someone paid to do the work doesn't seem like it matters anymore when you consider that Mozilla just laid off a bunch of technical employees to focus on whatever else. Are there any other solo devs who get "dependency anxiety" and don't want to start working on a project because you worry that you'll have wasted your time if one of the hundreds of dependencies breaks something, and there is nobody to fix it (like a crypto library for example)?

randall 6y ago
The flip side is 12 people could run Instagram before acquisition.
chadash 6y ago
I'm sorry to hear you feel afraid to learn more software development, but i think these concerns are largely unfounded. First of all, dependencies don't break just because they are unmaintained. If it worked ten years ago, it should still work now. For particularly complicated dependencies, there's a likelihood that they have bugs. But if they are popular, these bugs are often either things you probably won't ever come across or can work around if you do. Finally, the beauty of open source software is that you can fix things yourself! Found a package from 10 years ago that works 99% of the time, but you just need to fix one thing or add one tiny feature? Not a problem, you fork the repo and add what you need.
- fermienrico 6y ago
  > Finally, the beauty of open source software is that you can fix things yourself! Don't you need proper domain knowledge to hack into the some obscure error for svg conversion inside of cairo? All you were trying to do is to display the company logo.svg from your graphics department who exported it on Illustrator version 5.0 because our company is too poor to go to subscription model for Adobe. May be something goofy in the svg data. You spend next days fixing this open source package, ranting on stackoverflow and finally have to concede and file an bug report on Github. It gets rejected because you have not gathered all the necessary details to file a bug report including proper stack traces and operating system information.
  - krisoft 6y ago
    if all you want to display is one logo then you fix the logo not cairo. You are more in trouble if your busines is accepting svg-s your users upload and only a minuscule amount breaks for unknown reasons.
- dx87 6y ago
  Gotcha, thanks for the feedback. I've never done professional software development, it's just something I picked up to broaden my skillset, so it's good to know that the concerns aren't really an issue in practice. Regarding fixing bugs in the dependencies, I think that's like a chicken/egg problem for me. I use the dependencies because I don't have the time or skill yet to make the functionality on my own, which means I also don't have the time/skills to fix bugs in the dependencies. I think I probably have to buckle down and get over that hump to be confident enough to make bigger projects that need more dependencies.
  - smichel17 6y ago
    Skillset -- reading other people's code - especially if you can get to the point where you understand it well enough to fix bugs in it - is a great way to work on building your skillset. Time -- yes.
  - james_s_tayler 6y ago
    Part of the skillset is evaluating dependencies on how well they fit with your goals both technical and strategic and what level of risk/benefit they pose, and how those dependencies are places in their respective ecosystem. Usually any ecosystem has a core set of dependencies that are heavily relied on by most or a lot of projects as the go-to solution for a given problem. Then there are often sets of dependencies where there are several popular well maintained choices to pick from depending on your needs. Where it gets a little trickier is things that are a bit more niche. That being said, most software development just wouldn't be possible without standing on the shoulders of giants so to speak cos it's just so time consuming. They're far more of a benefit than a detriment but you have to learn to assess them and make choices based on your individual considerations.
- chrismorgan 6y ago
  Dependencies do break because they are unmaintained. All the time. If it worked ten years ago, there is no guarantee whatsoever that it will work now, unless you: (a) run it in an environment of ten years ago (otherwise other platform dependencies may be unavailable, or platform behaviour may have changed); (b) ensure that environment is already fully set-up (otherwise internet systems from which it fetches other dependencies may be unavailable, e.g. due to a service being taken down or certificate changes); and (c) are using strictly offline-capable software (e.g. if a commercial library does an activation/licensing server check, that may fail). In other words, to be confident, you need to freeze a snapshot of the entire system, which is obviously terrible for security. If these conditions are not met, things may or may not work. Some platforms will be more robust over time than others. Scripting languages are generally atrocious, with an installability half-life well under ten years (I’m going to guess something around five years). Compiled languages are a mixed bag. Rust is one of the best options out there, so long as it’s pure Rust code only and doesn’t include any bindings on more build-fragile code. I shall give a few examples of the sorts of problems that can occur and have occurred to me in the last decade. • In 2012 I wanted to install IE6 on a Windows 2000 machine (don’t ask). But the underlying infrastructure at Microsoft was gone, so even if I had the full installer, it failed to install. • A few years ago I wanted to install something that depended (transitively) on some key foundational Perl package, but due to recent Linux kernel changes that package’s tests no longer passed. (Perl defaults to running the tests when you install. You can disable that, but clearly the software isn’t running as expected.) Fortunately the package was maintained, so I just had to install the newer version, overriding the stated dependencies. • You could be trying to install something with Node.js and it doesn’t work beyond Node 0.12 or 4 or something, so you’ll need to figure out how to get that old version of Node before you have any hope of running the project. And that probably means “figure out how to build it from source”, which is harder than you might hope, because it probably depends on old versions of libraries that used to be easy to get from your OS’s package manager, but are now unavailable, so you’ll have to build them from scratch too, recursively. • I used to use Hyde to generate my website. A couple of years ago, five years or so after it was abandoned, it had become very tedious at best to install anew, due to being part of the declining Python 2 ecosystem. A few years ago I think I tried setting it up on Windows and gave up after a while, though that’s hardly a fair comparison on its own. On my server, I had used https://aur.archlinux.org/packages/hyde-git https://aur.archlinux.org/packages/hyde-git to install it, but that’s no longer installable, because it depended on packages in the community repository that have been removed and have not resurfaced in AUR. This is probably not insurmountable, as you can probably install the package in other ways, but it indicates that the way that I had installed it has broken. I had two or three more examples in mind, but I’ve just been called for lunch. So just one more note: use lockfiles, they’ll normally make things more robust, but be ready to need to update some of those dependencies in order to get things to work at all a few years down the track, and you’ll be practising trial and error over which.
- kabacha 6y ago
  When I started Python development I felt exactly like OP did. There was this unmaintained library that didn't support Python3 and was breaking everything — turns out it took 15 minutes to change few print and import statements to get it working perfectly.
jacquesm 6y ago
Hah! Try node.js for anything non-trivial and shudder.
- geuis 6y ago
  It’s entirely possible to write good and efficient software with node without requiring an excess of dependencies. It just requires strong responsibility and good practices.
  - jacquesm 6y ago
    Ok, I concede it is possible. Just like going to the moon is possible. But in practice everything I see that pulls in the node ecosystem even peripherally suffers from this. 100's of dependencies are not rare at all, and some of those on the most obscure packages.
    - geuis 6y ago
      You aren’t wrong. After years of seeing things going that way, I’m hyper critical of any new additions I make to my own software or anything my team is working on.
  - errantspark 6y ago
    Couldn't agree more. To expand on the point a bit I feel that Node (and JS in general, and other wildin' langs like C++ too) mostly have disadvantages that can be circumvented with discipline while keeping their advantages intact. Go and related crew on the other hand impose discipline as a language feature, and if you circumvent it (if you even can) you're missing much of the point of the language.
- dx87 6y ago
  Yeah, I've been using Rust for hobby stuff for the past few years, and I never paid much attention to how many dependencies get pulled in. I checked recently with the postgres crate, and that one crate resulted in just under 100 dependencies being pulled in.
- 6y ago
duxup 6y ago
And at the same time this system allows for a few people or person to do amazing things rather than build from the ground up.
geuis 6y ago
Don’t let it turn you off. Just don’t join the club. I’ve been doing software dev for close to 20 years. I’ve been watching various frameworks come and go for years. Somehow React gained precedence in web land, but based on the last 6 years of dealing with that hot mess it’s just an even deeper level of dependency hell but go a single framework. The recent work I’ve been doing has been entirely back to basics. It’s extremely satisfying to write web software again that’s fast, easy to deploy, and easy to debug.
stormbeard 6y ago
Mature projects make sure to depend on "well maintained" projects for this reason. However, in general dependencies don't just spontaneously break. If you're serious about the project and have to upgrade due to security vulnerabilities, you typically rely on stable branches whose purpose is to prevent breakages like the ones you're worried about.
bschwindHN 6y ago
We're all building off the work of others, unless you start with silicon from sand. Just choose your dependencies wisely. A web framework might not be around in a year but your OS's socket interface will. And if a dependency breaks, _you_ can be the one to fix it. Just, you know, don't depend on closed source code.
madhadron 6y ago
So don't use huge dependency trees. I largely keep to the standard library of a language plus very precise libraries that handle a lot of complicated logic in one domain like, say, XML handling. Also, some things are going to be around for the foreseeable future, like POSIX, Win32, or PostgreSQL. Debian Linux isn't going away any time soon, nor is TCP/IP. Too much of our economy depends on TLS for it to be horribly abandoned for long. After a decade or so you will get a feel for what things you can assume will be there for you and what things are ephemeral.
- badRNG 6y ago
  Where I work, anything that is outside of the standard library and some certain security-approved dependencies requires a miserable approval process where an authorization package has to be submitted to security who will require upgrades anytime a CVE with a high enough assessed criticality is posted for the dependency (or other concerns regarding the source arise.) This approval is revisited on a regular period (or added to the standard list of approved dependencies.) The net effect is that there isn't dependency creep where any team can just continuously add dependencies to a project without their ongoing justification and visibility. For personal projects, I'm very liberal with using dependencies that can get something in my mind functioning quickly before my motivation dries up. I think I shared the OP's anxiety regarding at least the longevity of what I write until I came to peace with the fact that my software will not function forever, and likely not for the rest of the decade. Relevant Tom Scott vid: https://www.youtube.com/watch?v=BxV14h0kFs0 https://www.youtube.com/watch?v=BxV14h0kFs0
  - deleted 6y ago
    [deleted]
- tonyedgecombe 6y ago
  POSIX, Win32, or PostgreSQL Interestingly some of my Win32 code broke this week after the latest update was released. It was in a fairly obscure part of the system and I was pushing at the border of what was possible. None the less I have 500 customers running around with their hair on fire at the moment and it's making me wonder why I am continuing in this business.
hamstercat 6y ago
You're assuming your hypothetical project is gonna work and be successful, and that dependencies breaking will be the end of it. In reality, most projects never go get that far, they go nowhere. Building successful software is a lot of work. Building the wrong thing, scope creep, not finding an audience are all much bigger problems. That being said, just start. Build something. Make it work. Learn. You can figure out problems with dependencies going out of support when you get there.
pseudoramble 6y ago
I wouldn't call it an anxiety really, but I've obtained some new perspective. I went from primarily working on app frontend for years using JS, and into a more API backend-ish role using .NET Core. In the former, dependency trees like this never really bothered me, probably because that was the culture around it in the JS world (at least at the time) and perhaps a bunch of other reasons. In the latter, I think .NET's ecosystem has a tradition of fewer external dependencies. It seems like it used to almost be a monolith, where basically Microsoft provided it, maybe a few major libraries existed, or you rolled your own, though that's just my impression of it. Another huge factor has changed my thinking on dependencies too. My employer has legal and security requirements around all dependencies. Anytime a new dependency is considered, it has to have the license reviewed which takes time, and known CVE's have to be addressed (patched or mitigated otherwise). I consider these good since it helps in the sense that the costs of dependencies forward, but certainly a pain. So I guess my perspective change is simply one of trying to understand the trade-offs. Some are well worth the cost because they're cheap, you won't get much benefit of your own, and will get benefit from a common one for everyone developing in it (testing libraries are one example). If a UI library is applicable to your project, of course a modern common one is a good choice, though you will pay for a lot of dependencies. Then there are other options which are more context-sensitive. Examples that come to mind are date/time libs, math libs, collection helper libs, etc. Sometimes they make sense to have, but oftentimes today can be substituted for a simpler function, though this can change with time too. This really just turned into a ramble. So I guess I'll conclude with this: if you're getting started and learning, maybe try and skip libraries until you really feel the pain and then introduce one when you need it. It may help to build up piece-by-piece and reduce the anxiety you feel about it.
draw_down 6y ago
The dirty secret is there are always more volunteers. Have you ever noticed people say open source “looks good” on your resume?
tclancy 6y ago
Oh, well here you go then: 0 1 Wish you the best.
gonzo41 6y ago
The way around this is to use dependencies sparingly and to just lock in a version. I can't say how many times in Java for instance I've pulled in a library used one or two features then shipped. A few years later in support security will start auditing stuff and ask for updates and upgrades for patching. To which there's usually a conversation along the lines of, "I'm sorry, Richfaces doesn't exist anymore." There are ways around this, it's like managing every risk. I think the dependency anxiety comes from a mixture of knowing that solving the problem would be to use a language like Java or Go, for their rich frameworks and simplicity. What holds you back and creates the anxiety is the downside that the tech stack stops being sexy and interesting. On crypto libraries, you've got options here. you can not do crypto in your app and push that into infrastructure and use some other app as a proxy to handle that work. This gives you freedom from issues because you can manage that layer by swapping in and out different ssl proviers/clients.
pansa2 6y ago
> unless you want to make a toy program, you end up with hundreds of dependencies One way to avoid this is to choose a programming language (e.g. Python or Go) that has a "batteries included" standard library. If you choose your dependencies from that standard library whenever possible, it's likely that they will be maintained for as long as the language itself. Using the standard library may not be the fastest way to solve your problem, and it won't be the "coolest", but it probably will be the approach with maximum longevity. Unfortunately this solution doesn't work quite as well if you're using a language with a poor standard library - for example when writing JavaScript code to run in the browser. I wrote one project using an open-source HTML canvas library, only to see the library abandoned shortly after. Since then, I've avoided those libraries in favor of using the raw canvas API - it's significantly more work, but it will be supported for decades instead of just a couple of years. I've decided to avoid Bootstrap and its "long-term support means 3 years" in the same way. > Even having someone paid to do the work doesn't seem like it matters anymore In fact, I think commercial solutions may be more likely to be abandoned than free ones. I'd trust Python's community of enthusiastic volunteers to maintain their language for longer than I trust Google to maintain Go.
- apta 6y ago
  > (e.g. Python or Go) golang is quite notorious for its dependencies pulling in tens or even hundreds of other dependencies
  - pansa2 6y ago
    Yes, Go suffers from the problem of every direct third-party dependency bringing in a large number of transitive dependencies. Almost every language does, because most developers don't mind. The reason I recommend Python or Go to people like the OP, who do mind, is that their strong standard libraries allow you to mitigate the problem by minimizing, or even eliminating, those direct third-party dependencies.
    - Quarkonout 6y ago
      I'd say because of the standard lib Python and Go suffer less than other languages. The third party libs benefit from the standard libs as well. Actually at my current job one of the tech leads decisions for choosing Go was exactly this.
II2II 6y ago
You aren't the only one. My reasons are quite similar, albeit from a different angle: I'm more concerned about my ability to understand the depth and breadth of these dependencies to make reliable software. It's a silly thing to be anxious about since I'm fairly certain that I am better than the average developer because of it, yet it also presents roadblocks on virtually any project I work on.
chadcmulligan 6y ago
There are other (non web) development systems that don't have huge numbers of dependencies - Delphi and Xcode are two that come to mind. You can add other projects to them if you so desire but if you want to learn programming with something out of the box Delphi is the one to look at imho. Delphi community edition is available for free https://www.embarcadero.com/products/delphi/starter https://www.embarcadero.com/products/delphi/starter. (An unpopular opinion - The web is a hierarchy of hacks and patches because the web browser was never made to do what it's being asked to do.) Edit: here's some YouTube courses that are very introductory https://www.youtube.com/watch?v=wsGpj-FVjGs&list=PLZZqoiUyRBsRTgdPJPr-eqAiOnKlP3CaP https://www.youtube.com/watch?v=wsGpj-FVjGs&list=PLZZqoiUyRB...
deleted 6y ago
[deleted]
TheKarateKid 6y ago
The huge dependency trees was a major turnoff for me when I started using the Javascript ecosystem like Node and React. When installing React, I received errors and depreciation warnings in the latest build available. What kind of confidence is that supposed to give me when something distributed by one of the largest tech company in the world seems unreliable? Even later, I've faced numerous issues where I had to manually find a fix online since a random dependency disappeared or new version was incompatible with the rest of my entire dev tree.

by dx87 6y ago

randall 6y ago

The flip side is 12 people could run Instagram before acquisition.

chadash 6y ago

I'm sorry to hear you feel afraid to learn more software development, but i think these concerns are largely unfounded. First of all, dependencies don't break just because they are unmaintained. If it worked ten years ago, it should still work now. For particularly complicated dependencies, there's a likelihood that they have bugs. But if they are popular, these bugs are often either things you probably won't ever come across or can work around if you do. Finally, the beauty of open source software is that you can fix things yourself! Found a package from 10 years ago that works 99% of the time, but you just need to fix one thing or add one tiny feature? Not a problem, you fork the repo and add what you need.

fermienrico 6y ago
> Finally, the beauty of open source software is that you can fix things yourself! Don't you need proper domain knowledge to hack into the some obscure error for svg conversion inside of cairo? All you were trying to do is to display the company logo.svg from your graphics department who exported it on Illustrator version 5.0 because our company is too poor to go to subscription model for Adobe. May be something goofy in the svg data. You spend next days fixing this open source package, ranting on stackoverflow and finally have to concede and file an bug report on Github. It gets rejected because you have not gathered all the necessary details to file a bug report including proper stack traces and operating system information.
- krisoft 6y ago
  if all you want to display is one logo then you fix the logo not cairo. You are more in trouble if your busines is accepting svg-s your users upload and only a minuscule amount breaks for unknown reasons.
dx87 6y ago
Gotcha, thanks for the feedback. I've never done professional software development, it's just something I picked up to broaden my skillset, so it's good to know that the concerns aren't really an issue in practice. Regarding fixing bugs in the dependencies, I think that's like a chicken/egg problem for me. I use the dependencies because I don't have the time or skill yet to make the functionality on my own, which means I also don't have the time/skills to fix bugs in the dependencies. I think I probably have to buckle down and get over that hump to be confident enough to make bigger projects that need more dependencies.
- smichel17 6y ago
  Skillset -- reading other people's code - especially if you can get to the point where you understand it well enough to fix bugs in it - is a great way to work on building your skillset. Time -- yes.
- james_s_tayler 6y ago
  Part of the skillset is evaluating dependencies on how well they fit with your goals both technical and strategic and what level of risk/benefit they pose, and how those dependencies are places in their respective ecosystem. Usually any ecosystem has a core set of dependencies that are heavily relied on by most or a lot of projects as the go-to solution for a given problem. Then there are often sets of dependencies where there are several popular well maintained choices to pick from depending on your needs. Where it gets a little trickier is things that are a bit more niche. That being said, most software development just wouldn't be possible without standing on the shoulders of giants so to speak cos it's just so time consuming. They're far more of a benefit than a detriment but you have to learn to assess them and make choices based on your individual considerations.
chrismorgan 6y ago
Dependencies do break because they are unmaintained. All the time. If it worked ten years ago, there is no guarantee whatsoever that it will work now, unless you: (a) run it in an environment of ten years ago (otherwise other platform dependencies may be unavailable, or platform behaviour may have changed); (b) ensure that environment is already fully set-up (otherwise internet systems from which it fetches other dependencies may be unavailable, e.g. due to a service being taken down or certificate changes); and (c) are using strictly offline-capable software (e.g. if a commercial library does an activation/licensing server check, that may fail). In other words, to be confident, you need to freeze a snapshot of the entire system, which is obviously terrible for security. If these conditions are not met, things may or may not work. Some platforms will be more robust over time than others. Scripting languages are generally atrocious, with an installability half-life well under ten years (I’m going to guess something around five years). Compiled languages are a mixed bag. Rust is one of the best options out there, so long as it’s pure Rust code only and doesn’t include any bindings on more build-fragile code. I shall give a few examples of the sorts of problems that can occur and have occurred to me in the last decade. • In 2012 I wanted to install IE6 on a Windows 2000 machine (don’t ask). But the underlying infrastructure at Microsoft was gone, so even if I had the full installer, it failed to install. • A few years ago I wanted to install something that depended (transitively) on some key foundational Perl package, but due to recent Linux kernel changes that package’s tests no longer passed. (Perl defaults to running the tests when you install. You can disable that, but clearly the software isn’t running as expected.) Fortunately the package was maintained, so I just had to install the newer version, overriding the stated dependencies. • You could be trying to install something with Node.js and it doesn’t work beyond Node 0.12 or 4 or something, so you’ll need to figure out how to get that old version of Node before you have any hope of running the project. And that probably means “figure out how to build it from source”, which is harder than you might hope, because it probably depends on old versions of libraries that used to be easy to get from your OS’s package manager, but are now unavailable, so you’ll have to build them from scratch too, recursively. • I used to use Hyde to generate my website. A couple of years ago, five years or so after it was abandoned, it had become very tedious at best to install anew, due to being part of the declining Python 2 ecosystem. A few years ago I think I tried setting it up on Windows and gave up after a while, though that’s hardly a fair comparison on its own. On my server, I had used https://aur.archlinux.org/packages/hyde-git https://aur.archlinux.org/packages/hyde-git to install it, but that’s no longer installable, because it depended on packages in the community repository that have been removed and have not resurfaced in AUR. This is probably not insurmountable, as you can probably install the package in other ways, but it indicates that the way that I had installed it has broken. I had two or three more examples in mind, but I’ve just been called for lunch. So just one more note: use lockfiles, they’ll normally make things more robust, but be ready to need to update some of those dependencies in order to get things to work at all a few years down the track, and you’ll be practising trial and error over which.
kabacha 6y ago
When I started Python development I felt exactly like OP did. There was this unmaintained library that didn't support Python3 and was breaking everything — turns out it took 15 minutes to change few print and import statements to get it working perfectly.

jacquesm 6y ago

Hah! Try node.js for anything non-trivial and shudder.

geuis 6y ago
It’s entirely possible to write good and efficient software with node without requiring an excess of dependencies. It just requires strong responsibility and good practices.
- jacquesm 6y ago
  Ok, I concede it is possible. Just like going to the moon is possible. But in practice everything I see that pulls in the node ecosystem even peripherally suffers from this. 100's of dependencies are not rare at all, and some of those on the most obscure packages.
  - geuis 6y ago
    You aren’t wrong. After years of seeing things going that way, I’m hyper critical of any new additions I make to my own software or anything my team is working on.
- errantspark 6y ago
  Couldn't agree more. To expand on the point a bit I feel that Node (and JS in general, and other wildin' langs like C++ too) mostly have disadvantages that can be circumvented with discipline while keeping their advantages intact. Go and related crew on the other hand impose discipline as a language feature, and if you circumvent it (if you even can) you're missing much of the point of the language.
dx87 6y ago
Yeah, I've been using Rust for hobby stuff for the past few years, and I never paid much attention to how many dependencies get pulled in. I checked recently with the postgres crate, and that one crate resulted in just under 100 dependencies being pulled in.
6y ago

duxup 6y ago

And at the same time this system allows for a few people or person to do amazing things rather than build from the ground up.

geuis 6y ago

Don’t let it turn you off. Just don’t join the club. I’ve been doing software dev for close to 20 years. I’ve been watching various frameworks come and go for years. Somehow React gained precedence in web land, but based on the last 6 years of dealing with that hot mess it’s just an even deeper level of dependency hell but go a single framework. The recent work I’ve been doing has been entirely back to basics. It’s extremely satisfying to write web software again that’s fast, easy to deploy, and easy to debug.

stormbeard 6y ago

Mature projects make sure to depend on "well maintained" projects for this reason. However, in general dependencies don't just spontaneously break. If you're serious about the project and have to upgrade due to security vulnerabilities, you typically rely on stable branches whose purpose is to prevent breakages like the ones you're worried about.

bschwindHN 6y ago

We're all building off the work of others, unless you start with silicon from sand. Just choose your dependencies wisely. A web framework might not be around in a year but your OS's socket interface will. And if a dependency breaks, _you_ can be the one to fix it. Just, you know, don't depend on closed source code.

madhadron 6y ago

So don't use huge dependency trees. I largely keep to the standard library of a language plus very precise libraries that handle a lot of complicated logic in one domain like, say, XML handling. Also, some things are going to be around for the foreseeable future, like POSIX, Win32, or PostgreSQL. Debian Linux isn't going away any time soon, nor is TCP/IP. Too much of our economy depends on TLS for it to be horribly abandoned for long. After a decade or so you will get a feel for what things you can assume will be there for you and what things are ephemeral.

badRNG 6y ago
Where I work, anything that is outside of the standard library and some certain security-approved dependencies requires a miserable approval process where an authorization package has to be submitted to security who will require upgrades anytime a CVE with a high enough assessed criticality is posted for the dependency (or other concerns regarding the source arise.) This approval is revisited on a regular period (or added to the standard list of approved dependencies.) The net effect is that there isn't dependency creep where any team can just continuously add dependencies to a project without their ongoing justification and visibility. For personal projects, I'm very liberal with using dependencies that can get something in my mind functioning quickly before my motivation dries up. I think I shared the OP's anxiety regarding at least the longevity of what I write until I came to peace with the fact that my software will not function forever, and likely not for the rest of the decade. Relevant Tom Scott vid: https://www.youtube.com/watch?v=BxV14h0kFs0 https://www.youtube.com/watch?v=BxV14h0kFs0
- deleted 6y ago
  [deleted]
tonyedgecombe 6y ago
POSIX, Win32, or PostgreSQL Interestingly some of my Win32 code broke this week after the latest update was released. It was in a fairly obscure part of the system and I was pushing at the border of what was possible. None the less I have 500 customers running around with their hair on fire at the moment and it's making me wonder why I am continuing in this business.

hamstercat 6y ago

You're assuming your hypothetical project is gonna work and be successful, and that dependencies breaking will be the end of it. In reality, most projects never go get that far, they go nowhere. Building successful software is a lot of work. Building the wrong thing, scope creep, not finding an audience are all much bigger problems. That being said, just start. Build something. Make it work. Learn. You can figure out problems with dependencies going out of support when you get there.

pseudoramble 6y ago

I wouldn't call it an anxiety really, but I've obtained some new perspective. I went from primarily working on app frontend for years using JS, and into a more API backend-ish role using .NET Core. In the former, dependency trees like this never really bothered me, probably because that was the culture around it in the JS world (at least at the time) and perhaps a bunch of other reasons. In the latter, I think .NET's ecosystem has a tradition of fewer external dependencies. It seems like it used to almost be a monolith, where basically Microsoft provided it, maybe a few major libraries existed, or you rolled your own, though that's just my impression of it. Another huge factor has changed my thinking on dependencies too. My employer has legal and security requirements around all dependencies. Anytime a new dependency is considered, it has to have the license reviewed which takes time, and known CVE's have to be addressed (patched or mitigated otherwise). I consider these good since it helps in the sense that the costs of dependencies forward, but certainly a pain. So I guess my perspective change is simply one of trying to understand the trade-offs. Some are well worth the cost because they're cheap, you won't get much benefit of your own, and will get benefit from a common one for everyone developing in it (testing libraries are one example). If a UI library is applicable to your project, of course a modern common one is a good choice, though you will pay for a lot of dependencies. Then there are other options which are more context-sensitive. Examples that come to mind are date/time libs, math libs, collection helper libs, etc. Sometimes they make sense to have, but oftentimes today can be substituted for a simpler function, though this can change with time too. This really just turned into a ramble. So I guess I'll conclude with this: if you're getting started and learning, maybe try and skip libraries until you really feel the pain and then introduce one when you need it. It may help to build up piece-by-piece and reduce the anxiety you feel about it.

draw_down 6y ago

The dirty secret is there are always more volunteers. Have you ever noticed people say open source “looks good” on your resume?

tclancy 6y ago

Oh, well here you go then: 0 1 Wish you the best.

gonzo41 6y ago

The way around this is to use dependencies sparingly and to just lock in a version. I can't say how many times in Java for instance I've pulled in a library used one or two features then shipped. A few years later in support security will start auditing stuff and ask for updates and upgrades for patching. To which there's usually a conversation along the lines of, "I'm sorry, Richfaces doesn't exist anymore." There are ways around this, it's like managing every risk. I think the dependency anxiety comes from a mixture of knowing that solving the problem would be to use a language like Java or Go, for their rich frameworks and simplicity. What holds you back and creates the anxiety is the downside that the tech stack stops being sexy and interesting. On crypto libraries, you've got options here. you can not do crypto in your app and push that into infrastructure and use some other app as a proxy to handle that work. This gives you freedom from issues because you can manage that layer by swapping in and out different ssl proviers/clients.

pansa2 6y ago

> unless you want to make a toy program, you end up with hundreds of dependencies One way to avoid this is to choose a programming language (e.g. Python or Go) that has a "batteries included" standard library. If you choose your dependencies from that standard library whenever possible, it's likely that they will be maintained for as long as the language itself. Using the standard library may not be the fastest way to solve your problem, and it won't be the "coolest", but it probably will be the approach with maximum longevity. Unfortunately this solution doesn't work quite as well if you're using a language with a poor standard library - for example when writing JavaScript code to run in the browser. I wrote one project using an open-source HTML canvas library, only to see the library abandoned shortly after. Since then, I've avoided those libraries in favor of using the raw canvas API - it's significantly more work, but it will be supported for decades instead of just a couple of years. I've decided to avoid Bootstrap and its "long-term support means 3 years" in the same way. > Even having someone paid to do the work doesn't seem like it matters anymore In fact, I think commercial solutions may be more likely to be abandoned than free ones. I'd trust Python's community of enthusiastic volunteers to maintain their language for longer than I trust Google to maintain Go.

apta 6y ago
> (e.g. Python or Go) golang is quite notorious for its dependencies pulling in tens or even hundreds of other dependencies
- pansa2 6y ago
  Yes, Go suffers from the problem of every direct third-party dependency bringing in a large number of transitive dependencies. Almost every language does, because most developers don't mind. The reason I recommend Python or Go to people like the OP, who do mind, is that their strong standard libraries allow you to mitigate the problem by minimizing, or even eliminating, those direct third-party dependencies.
  - Quarkonout 6y ago
    I'd say because of the standard lib Python and Go suffer less than other languages. The third party libs benefit from the standard libs as well. Actually at my current job one of the tech leads decisions for choosing Go was exactly this.

II2II 6y ago

You aren't the only one. My reasons are quite similar, albeit from a different angle: I'm more concerned about my ability to understand the depth and breadth of these dependencies to make reliable software. It's a silly thing to be anxious about since I'm fairly certain that I am better than the average developer because of it, yet it also presents roadblocks on virtually any project I work on.

chadcmulligan 6y ago

There are other (non web) development systems that don't have huge numbers of dependencies - Delphi and Xcode are two that come to mind. You can add other projects to them if you so desire but if you want to learn programming with something out of the box Delphi is the one to look at imho. Delphi community edition is available for free https://www.embarcadero.com/products/delphi/starter https://www.embarcadero.com/products/delphi/starter. (An unpopular opinion - The web is a hierarchy of hacks and patches because the web browser was never made to do what it's being asked to do.) Edit: here's some YouTube courses that are very introductory https://www.youtube.com/watch?v=wsGpj-FVjGs&list=PLZZqoiUyRBsRTgdPJPr-eqAiOnKlP3CaP https://www.youtube.com/watch?v=wsGpj-FVjGs&list=PLZZqoiUyRB...

deleted 6y ago

[deleted]

TheKarateKid 6y ago

The huge dependency trees was a major turnoff for me when I started using the Javascript ecosystem like Node and React. When installing React, I received errors and depreciation warnings in the latest build available. What kind of confidence is that supposed to give me when something distributed by one of the largest tech company in the world seems unreliable? Even later, I've faced numerous issues where I had to manually find a fix online since a random dependency disappeared or new version was incompatible with the rest of my entire dev tree.