We need a vibe shift on dependencies in programming.

Mitsuhiko's blog is a resource for developers and technology enthusiasts seeking to deepen their understanding of programming languages, software architecture, and emerging technologies. With a focus on practical tips, code examples, and industry insights, it provides  guidance and inspiration for professionals looking to stay ahead in the rapidly evolving field of software development. Through  tutorials, technical discussions, and  analyses, the blog fosters a community of learning and innovation among its readers.

Armin Ronacher

The post discusses the issue of dependency churn in software development, particularly in the Rust ecosystem. It highlights how dependencies can lead to constant updates and security issues, suggesting that developers should consider writing their own code for small functions to reduce maintenance overhead. The author advocates for a cultural shift towards valuing fewer dependencies and more stable, self-written code.

Build It Yourself

Reminds me of the is-even npm package. There are a lot of cases where the developer shouldn’t be reaching for a package when they should just write it themselves.

You also should consider project budget, time and scope. You must deliver what you signed with client with reasonable time and if it’s true there will be compromise you will take to include dependecies in your project. Don’t invent the wheel again and again. It makes sense only for project in which you will be maintaining the code for years.

I think it’s always a gamble. 
Sometimes, you think “ah, I’ll just do it myself” and you end up maintaining that minor functionality for several, resulting in a lot of unnecessary costs. 
Other times, you read about a library being hacked and you think “Wait, didn’t I use that in several projects…?” 
You neither want to have 800 dependencies for you todo app, nor do you want to invent the wheel every week. It has to always be considered from case to case and there are a lot of factors to consider.

Take it from the Go playbook
<blockquote>
A little copying is better than a little dependency.
</blockquote>
I recently did it for my neovim config. Made my own and now I know where everything is. I read, understood, and copied the ideas from other plugins and nvim “flavors” that I likes and wanted to use.
Very few plugins, performant, has exactly what I need, it doesn’t break once a month like the previous experiences I had.