|
|
|
|
|
|
by mlthoughts2018
2676 days ago
|
|
|
It’s totally disingenuous to compare general purpose languages like Go or Dart which were designed from the beginning to be general purpose, to the types of limited-purpose languages discussed earlier. If you look upon an internal business problem and propose that the right starting point for that business problem is to design essentially a single-use language from the ground up, that is a red flag. If you decide to create a new language as a goal unto itself or as a product, like Go, Swift, Kotlin, etc., then I’d say it’s a silly waste of time but not at all the same sort of red flag as responding to a specific business need by first building a whole language. As for Google’s monorepo, I’m not getting drawn into more bike shedding about it. There absolutely exist polyrepo off-the-shelf solutions that would performantly handle their use case without the weird limitations of their custom tooling. Happy to agree to disagree with you about it. |
|
|
1. Facebook (lot of ex-Googlers, so fair if you want to criticize it as a culture thing)
2. Microsoft - they've driven mono repo on Git & have migrated Windows polyrepo flow to a mono repo one. They also gathered metrics & on the whole & users overall (30% dissatisfaction rate for completely altering the workflow over a weekend doesn't seem terrible).
3. Apple kind of. Everyone has their repo but each project submits into 1 giant repo for build purposes. Even still dependency problems crop up (team submits project A but another team forgets or is unable to submit project B that A relies on) that wouldn't in a single monolithic codebase
I work on polyrepo projects and I found the tooling to be quite lacking. Moreover it's been a giant PITA to communicate how to maintain this system to other people. A mono repo would be much easier.