4 ms·
I've mostly switched to Go for new projects, but if that weren't the case I suspect I'd be using Deno a lot. The biggest downside I can see is the lack of packa
by anderspitman 5y ago
I've mostly switched to Go for new projects, but if that weren't the case I suspect I'd be using Deno a lot. The biggest downside I can see is the lack of packages, and I normally avoid dependencies like the plague so that doesn't really bother me. I'd guess any useful enough to justify their existence will be ported soon.
- TameAntelope 5y ago> and I normally avoid dependencies like the plague I cannot imagine how you are capable of effectively getting meaningful things done with this mindset.
- dgb23 5y agoNot GP but it really depends on where you draw the line. Keeping dependencies to a realistic minimum is a very pragmatic and robust decision.
- tomnipotent 5y ago> Keeping dependencies to a realistic minimum is a very pragmatic and robust decision. For libraries and frameworks, agree completely. But for LOB software, do what you have to do.
- christophilus 5y agoWith Go, you can do a whole lot without anything other than your database package. This is also true in C# (or was 10 years ago when I used to write it).
- anderspitman 5y agoYep. I'll quote myself from last year[0]: > I think I've managed to get by with less dependencies in Go than any other language. It somehow walks the line between JavaScript leftpad and Python "stdlib is where modules go to die". > I don't think there's been a single instance where I've thought "why can't stdlib do this?" nor "why the heck is this in stdlib?" [0]: https://news.ycombinator.com/item?id=25806114 https://news.ycombinator.com/item?id=25806114
- nine_k 5y agoI suppose that with a good stdlib, you can make a lot of useful while only depending on it. E.g. as long as you mostly consume and provide HTTP-based APIs, you're likely fine with just stdlib.
- hackerfromthefu 5y agoI cannot imagine how projects with hundreds to thousands of dependencies get supported long-term. I think the answer for things built on npm is that it's someone else's problem and the projects tend to have short lives unless they are super successful to afford constant churn maintenance. There's parables here to fast fashion and all the other crappily made stuff that sells well but end in landfill way before it should, destroying our planet quicker.
- TameAntelope 5y agoI’ve found building “high quality” things is an exercise for people with too much money who don’t really care if what they build helps people. It’s a lot faster and more effective to use free labor from open source projects if what you care about is building useful things quickly.
- hackerfromthefu 5y agoAgain, the point I am making is short term vs long term. Also I don't believe that e.g. Node is actually faster than more robust alternatives, with large, well designed, stabler, battle tested, base class libraries, that come with consistent homogenous licenses that won't be deprecated. If you are actually skilled at e.g. C# .NET you can go as fast or faster in my opinion, yet still have much better long term maintainability. Respect for avoiding dependencies is the sort of thing you learn when you get longer experience supporting not just initially building systems, and culturally I think the javascript ecosystem attracts people who are junior in terms of that experience.
- TameAntelope 5y agoPeople who avoid dependencies are, in my experience, junior devs who forget why they get to write software for a living. Senior devs understand the value of delegation, especially outside of the company, for work that isn’t your core competency. You aren’t often allowed on successful and productive teams for very long if you just throw out an entire category of efficiency. I know no dev would last very long on a team I run if they wasted my team’s time rewriting something we could pull off the shelf.
- anderspitman 5y agoI'm pretty happy with the projects I've managed to ship as a solo developer using minimal dependencies. Over my career I've tried every level of dependency from left-pad to NIH. The sweet spot for me is somewhere in the middle, but leaning towards NIH. Typically my approach is to attempt implementing something myself before using a library, unless it's something I already know I'm going to need one. If I notice myself going too far down the rabbit hole, I back up and use a lib. At the very least I end up with a greater appreciation for what the dependency is saving me. But often I find you don't actually need more than a small subset of a given library, and my homemade solution keeps chugging along for years. I still mostly agree with my thoughts from a couple years ago: https://apitman.com/11/#dependencies https://apitman.com/11/#dependencies