This definitely mirrors my experience on our Go codebase. Getting nontrivial features out the door generally requires hundreds of lines of code at a minimum, and sometimes thousands. We've taken to branching off of branches to keep code review moving quickly, but that creates new problems like cascading rebases all the way back down.

If there's some secret to architecture or tooling (e.g. feature flags) that people use to keep PR size down in Go codebases, would love to hear it.

Haven't worked in an enterprise Java setting before but would be curious to compare diff size there.

I work in an enterprise Java setting but I don't believe that this is a language specific issue. Our diff sizes vary by 3 orders of magnitude, so it would be meaningless to give an "average" line count. Each one is just large enough for a complete user story or defect fix, no more and no less. User stories have to be defined and broken down based on business value delivered to the customer regardless of how large or small the change is from an engineering standpoint.

I'm in the same boat, but I feel like the problem is tying the commits to the user stories. Ideally you'd be able to make multiple commits to implement a single user story where it can't be done with a small amount of code.

Sure there are multiple commits on a branch, but when we merge back to the trunk the whole user story has to go in one shot. We can't put a partial user story on the trunk because then it wouldn't be in a fit state to release.

Well, we can't commit half a visible feature, for sure, but my sense is that the parts that are too complicated to review in a single setting often either involve a preparatory refactoring or represent a code base that has excessive duplication.

There are things that just can't be split apart, I admit. I had to do a truly heinous refactoring of some code awhile back to migrate from floats to doubles that couldn't be accomplished via a global find and replace (unsafe casts and other crap). That was the largest commit I've ever landed, and the code wouldn't compile for half the time I worked in that branch. Come to think of it, that refactoring was harder than it had to be because of duplication and badly written code, but it would've been massive no matter what.

The expressiveness of a language directly impacts the amount of code you need to write for a feature.

Go is a concise language but it's not expressive - you'll write 4 lines to call a func and check an error.

This means that PRs are inevitably going to be larger than a language like Ruby or other languages with metaprogramming.

I think you have those backwards. Concise is expressing an idea in less words, expressiveness is the breadth of ideas that can be communicated. Go is not concise and does not try to be.

Just to play devil's advocate (in case this is what they were thinking), go's language definition is fairly concise, by design. Few keywords, little magic, leading to lower expressiveness per LoC.

When talking about lines of code written, "concise" is roughly "idea/length" whereas "expressiveness" is "sum of ideas", so yes, "concise" could be roughly seen as "expressiveness / LoC", but it's still the wrong word to use, as "expressiveness" specifically refers to the "breadth of ideas that can be represented and communicated". And either way, while the language spec is concise, the language itself is most definitely not

+1 totally, thanks for the heads up!

Lots of factors here. I find it more a matter of project style/age than language.

Adding whole new chunks of code, refactoring the public interface of widely used systems, etc. tend to result in large diffs - lots of 'churn'. Extending existing code, bugfixes, more localized refactoring and doc fixes - more 'stable' codebases - tend to result in smaller diffs.

Also some difference between e.g. git and perforce - branching is easier, so I can make smaller commits without worrying about breaking the dev branch...

Anecdotally, I agree it seems that Go codebases have considerable churn compared to other languages.

That being said, the churn is typically much easier to review and understand, and thus have confidence in, especially compared to Ruby or Python.