[mlthoughts2018]

> “So if Google or Facebook write themselves a new language (or two), I'm guessing you are ok with that?”

What gives you that impression? It would be equally (perhaps more) red flag if Google permitted this in-house, much like Google’s in-house monorepo tooling that grew out of a series of historical Perforce accidents is a huge red flag of dysfunction.

[willtim]

> It would be equally (perhaps more) red flag if Google permitted this in-house

But Google and Facebook have permitted this in-house (Go,Dart,Hack,Reason etc). They have since open-sourced them, but these projects are still run from within. I don't see this as a red flag, these languages all have good reasons to exist.

> Google’s in-house monorepo tooling that grew out of a series of historical Perforce accidents is a huge red flag of dysfunction

Google probably has the largest repo in the world, no off-the-shelf product is going to work. I fail to understand why building their own tools to accommodate their own special needs is a red flag of dsyfunction?

[mlthoughts2018]

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.

[vlovich123]

Before working at Google I would have agreed with you. After working, not too sure. There's tradeoffs of course but I'm not quite as certain that it's the wrong tradeoff. Considering every similarly-sized company does the same thing it seems like it has real advantages at scale. Notably:

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.

[willtim]

I do not see Go or Dart as being general purpose, we will have to agree to differ.

[scott_s]

Google has down exactly this: https://golang.org/