>Did you use golang on a monorepo for example?

No. I have met monorepo on my path only once (not a golang one, it was mix of java and jruby) and I hope I will never see one again.

golang fails miserably in a monorepo setting, which is ironic because it was designed at Google, and Google are known for their monorepo.

>which is ironic because it was designed at Google, and Google are known for their monorepo.

Google is huge. I'm fairly sure they use different approaches to code organisation in different teams\departments.

Anyhow - I'd rather thank them for that. Now chances I'll have to deal with monorepo are lower. I'm going to think of this as a feature, not a bug, lol.

May I ask, what do you mean and why do you say so? What is wrong with golang in monorepos?

Because interfaces are nominally typed, it's very simple to accidentally implement interfaces that are defined in other parts of the code base, even though they are not related to your project. This makes searching for implementors of a given interface in a project show implementors you don't care about, which makes navigation and discoverability very tedious.

Furthermore, golang does not have a proper format for docstrings like Java or C#. When refactoring, the IDE tries to be smart and parse all comment strings as they are doc strings, and when you want to rename a struct, you're going to get a huge dialog with so many entries which can be false positives, and you have to go through them manually to check whether or not they apply. Same as with the interface issue, similar struct names may appear all across the code base which makes this refactoring very tedious.

There are other issues of course, like the fact that golang has no constructors, and structs are defined adhoc, meaning adding a new field to it needs more hunting across the code base to make sure you don't miss defining and break something.