2 ms·

> tie things to technical merits than engage with the problem at a sociopolitical level. This hits the nail on the head. The real advantage of monorepos is tha

> tie things to technical merits than engage with the problem at a sociopolitical level. This hits the nail on the head. The real advantage of monorepos is that they are reproducible. Many-small-repos aren't. A monorepo, ideally one like bazel[1] pushes will produce the same bitstream every time you put "make". Projects terminated, going in a different direction, servers moved, down, forked, ... it all just doesn't matter. Your stuff works. Network or no network. The problem is that these repos allow programmers to be very undisciplined in a way that sabotages projects. In a monorepo you are updating libraries. In every individual project. That's a big plus, when it comes to "my software works", but of course it is work. Your software doesn't suddently stop working, but that's because it doesn't change, which means it won't change unless you make it change. Which means, new database driver ? You're upgrading it. No apt-get, no sysadmin deploying a shared library or dll install doing it for you. There is always a strong drive by higher up programmers and managers to fix "undisciplined" programming, and ... I've never seen this work. Or at least, I've never seen this do more than move the problem. The thing I don't understand about some languages, like Golang, is the (ridiculous) insistence on hermetic binaries (not using anything on the system, not even libc), and yet their very strong insistence on non-hermetic source (even to the point of sabotaging the tools for people who wish to do it, and sabotaging to some extent the community to achieve this). Either do one, or the other. I feel like C/C++'s support of both approaches is a superior option. You want shared (nobody does, but hey that's my opinion) ? You can do that. You want everything hermetic ? Not a problem. In my opinion sharing things between projects is a mistake. [1] https://bazel.build/ https://bazel.build/

WorldMaker 8y ago
There are just as many tools for reproducible builds of polyrepos, between various package management strategies and CI tools. > Projects terminated, going in a different direction, servers moved, down, forked, ... it all just doesn't matter. Your stuff works. Network or no network. I think it becomes a forest/trees thing. People that prefer a monorepo are most focused on the forest, and people that prefer polyrepos are most focused on the individual trees. The end goal is usually the same (a healthy forest), and done right both approaches are generally isomorphic (the "canopy" of the forest looks generally the same to the users either way). To push the metaphor perhaps to the breaking point, a lot of the arguments between monorepos and polyrepos break down into management of the "root system" in the forest. Monorepos often don't care as much how deeply the roots are entangled between trees so long as the forest is healthy, and polyrepos tend to encourage a more "bonsai" approach of tending to each tree on its own. Either way, it rarely seems to affect the "canopy" (end user experience) of the forest, but can matter a great deal to things like technical debt and project management structure and project deadlines.

WorldMaker 8y ago

There are just as many tools for reproducible builds of polyrepos, between various package management strategies and CI tools. > Projects terminated, going in a different direction, servers moved, down, forked, ... it all just doesn't matter. Your stuff works. Network or no network. I think it becomes a forest/trees thing. People that prefer a monorepo are most focused on the forest, and people that prefer polyrepos are most focused on the individual trees. The end goal is usually the same (a healthy forest), and done right both approaches are generally isomorphic (the "canopy" of the forest looks generally the same to the users either way). To push the metaphor perhaps to the breaking point, a lot of the arguments between monorepos and polyrepos break down into management of the "root system" in the forest. Monorepos often don't care as much how deeply the roots are entangled between trees so long as the forest is healthy, and polyrepos tend to encourage a more "bonsai" approach of tending to each tree on its own. Either way, it rarely seems to affect the "canopy" (end user experience) of the forest, but can matter a great deal to things like technical debt and project management structure and project deadlines.