> You seem to be writing that a simple language is somehow harder to scale for large teams
I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen other programs in complex languages get out of hand.
There is a sweet spot in terms of language simplicity/complexity and usability. Make it too simplistic (like golang) and the low modeling ability and inexpressiveness of the language will result in shifting the complexity into the code and onto the programmer, there's no running away from it, it's just reality. IMO, languages like Java, C#, and Kotlin do a much better job at balancing features with modeling power and expressiveness, without sacrificing simplicity.
> Verbose (and consistent) is exactly what you want for large teams. What's error prone about it?
I've seen many instances where errors are ignored by mistake, e.g.:
a, err := foo()
if err != nil { ... }
b, err := bar()
// oops, error not handled and compiler doesn't complain
c, err := baz()
if err != nil { ... }
not to mention things like
defer file.Close() // Error not handled
and more insidious occurrences (e.g. when was the last time you handled the error for fmt.Println()?)
Consistent is good, verbose just for the sake of being verbose isn't. And honestly golang is not that consistent (e.g. the entire nil interface is not nil issue is just bizzare)
> Do you have an example project that has problematic build times in Go?
At my employer, we use a monorepo and build with bazel. Builds routinely take several minutes, and even more on "less powerful" machines (e.g. 4 cores). Linking time is abysmal, and we routinely end up with 50+MB binaries. It's closed source so I can't share them.
> I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen other programs in complex languages get out of hand.
In my experience this kind of gatekeeping eventually breaks down due to deadlines and similar. There's also a slow rot that always creeps in, and unfortunately seniority doesn't always keep "clever" solutions and general over engineering out.
But it looks like we'll have to agree to disagree here.
> I've seen many instances where errors are ignored by mistake, e.g.:
It's true that there's sometime bugs due to mistyping err != nil sometimes. But I have not noticed that it's too often or that it's somehow is such a large problem that it out-weigh the benefits of the clarity and simple flow brings.
> At my employer, we use a monorepo and build with bazel.
Hard to compare with an anecdote like that, I just haven't heard much complaints regarding compile times, if anything the opposite, and certainly not that it's a significant problem in a pros/cons comparison.
> In my experience this kind of gatekeeping eventually breaks down due to deadlines and similar.
I don't disagree. That's why I said the sweet spot is much closer to Java/C#/Kotlin.
> But I have not noticed that it's too often
That's the problem though. Those silent difficult to detect bugs are what affect reliability and safety. With exceptions, you're going to have to explicitly ignore them, whereas with golang errors, it's much easier to misuse them. Not to mention the fact that golang errors are basically strings, which makes dealing with them very error prone.
> Hard to compare with an anecdote like that, I just haven't heard much complaints regarding compile times, if anything the opposite, and certainly not that it's a significant problem in a pros/cons comparison.
My guess is that most people don't use golang for large projects, and few who do don't care about the long compile times.
I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen other programs in complex languages get out of hand.
There is a sweet spot in terms of language simplicity/complexity and usability. Make it too simplistic (like golang) and the low modeling ability and inexpressiveness of the language will result in shifting the complexity into the code and onto the programmer, there's no running away from it, it's just reality. IMO, languages like Java, C#, and Kotlin do a much better job at balancing features with modeling power and expressiveness, without sacrificing simplicity.
> Verbose (and consistent) is exactly what you want for large teams. What's error prone about it?
I've seen many instances where errors are ignored by mistake, e.g.:
not to mention things like and more insidious occurrences (e.g. when was the last time you handled the error for fmt.Println()?)Consistent is good, verbose just for the sake of being verbose isn't. And honestly golang is not that consistent (e.g. the entire nil interface is not nil issue is just bizzare)
> Do you have an example project that has problematic build times in Go?
At my employer, we use a monorepo and build with bazel. Builds routinely take several minutes, and even more on "less powerful" machines (e.g. 4 cores). Linking time is abysmal, and we routinely end up with 50+MB binaries. It's closed source so I can't share them.