Reading @Jonathan_Blow's comment today about how younger programmers have become accustomed to continual software decay, I was reminded of this thread I wrote a few years ago:
Reading @Jonathan_Blow's comment today about how younger programmers have become accustomed to continual software decay, I was reminded of this thread I wrote a few years ago:
@cmuratori @Jonathan_Blow Question about this. In Odin's case they take a direct copy into their codebase, and for Rust we have Cargo where no dependencies versions are deleted. While it's true dependencies update, isn't it also true we can choose to not update?
Anyone can choose not to update anything - just buy a computer, install what you're going to use, then unplug it from the internet :) The question is what happens when you would like to update things, to get new features or security fixes, etc.
@cmuratori @Jonathan_Blow Didn't realise we're making that assumption. Yeah I agree. It also gets really bad when the tool is tightly coupled with your code like with Game engines. While it's technically 1 dependency, the entire surface area updates having huge consequences.
@cmuratori @Jonathan_Blow Could be argued the issue is not the number of dependencies, but the surface area ownership. The higher the surface area you don't own, the more likely it is to break. It just so happens the number of dependencies is the most common way to reduce surface ownership.