4 ms·
> 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)
by 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 agoYes, 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 agoI'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.
- apta 6y ago> standard lib Python and Go suffer less than other languages Depends on what those "other languages" are. For example. golang has nothing on the Java standard library (e.g. what does golang have to even remotely compare with `java.util.concurrent`?)
- Quarkonout 6y ago> golang is quite notorious for its dependencies pulling in tens or even hundreds of other dependencies Plain wrong. Just stop trolling against Go. 1. The point is that you don't need as much third lib deps with Go or Python due to the huge and useful standard libs. 2. For exaclty this reason the third party dependencies don't need as much other third party dependencies.
- saagarjha 6y ago> Just stop trolling against Go. Please assume good faith when responding to people: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- majewsky 6y agoIn my experience, it's fairly easy to keep the number of deps down to a minimum when writing an average Go application. I have several apps that take less than 5 deps total (including recursive deps). However, there are a few outliers. Most famously, the Kubernetes client libraries are made of hundreds of packages because of how they're structured and autogenerated (due to lack of language-level generics).