> Go is one of the least expressive languages I've ever used
That is by design, and when it comes to "programming in the large" - a winning formula. I keep repeating this response: I worked on a Perl codebase with a medium-sized team. Perl is very expressive, and my teammates did not hold back. I can tell you that is a nightmare to debug or add a new edgecase to a "clever" Perl 1-liner, usually it involved making the code "less expressive". So, I'll take Go over the more expressive languages in a team setting any day.
It's a spectrum, though. A language can be between 0 expressiveness (Go) and 100 expressiveness (Perl, maybe Lisps), and claiming that the only way to avoid the mysterious evil team member who will wreck your codebase is to patronizingly limit them "for their own sake" is insulting
Often times the developers moaning about complex code basically learned if statements and for loops and then were done learning.
But we still have to write code that these people understand. It makes no damn sense.
Sometimes, sure, people write horribly complex code, but sometimes it's just developers who have stopped learning. They see something that isn't immediately familiar and discard it as too complex and make no attempt at trying to learn.
What I don't get is why we have to pander to these people.
This is a mischaracterization. We write simple code not for simple people, but because grokking gratuitously abstract code isn't a good use of anyone's cognitive resources--no matter how smart you are, you will have more mental capacity to put toward real problems if you're working in a simple codebase rather than an unnecessarily abstract codebase.
Not for their sake - for mine. I avoid people and places that make my life unnecessarily difficult, especially if I have to do support and can be called at 3am to resolve urgent issues.
My needs are pretty basic: I like code that is easy to understand and easy to change more than writing code that leaves a smug smile on my face. I read more code than I write, so YMMV.
The fewer surprises, the better for me, and so far, the collaborative codebases I've encountered the least number of surprises have consistently been in Go (the other languages I've been paid to work with are Javascript, Perl, Python, Java, and Scala).
Huh? What do you consider syntactic bureaucracy? Go has like 25 keywords and no sigils -- the least "syntactically bureaucratic" language I'm aware of!
> Go is one of the least expressive languages I've ever used.
This is definitely true. Of course expressiveness is not strictly a virtue!
I would assume "amount of syntax required to express a given concept," with the use of the word "bureaucracy" implying that some concepts require too much syntax relative to their complexity (something that depends on your values). The classic example being mapping over a slice.
func (w *Whatever) Read() uint64 {
var total uint64
for _, v := range w.values {
total += v
}
return total
}
The former is certainly fewer characters than the latter. But to me it represents _more_ syntactic bureaucracy, not less. There are more sigils, more language concepts I need to understand, more _types of syntax_ to express the same thing. It's 20% of the SLoC, but parsing it requires more implicit knowledge, and takes no less time, versus parsing the latter.
Ah, that's interesting! I'm not the person who used "syntactic bureaucracy" but I did interpret it roughly like that, yes. I'm not sure what phrase I would use to describe "more syntactical constructs" as you're saying, but it's interesting how we saw the term differently.
Similarly, even though I'm not a big fan of Rust, I would personally prefer to encounter the Rust snippet. The way I read code, I'm already building up mental models of things in my head, so adding more (e.g. what fold is) isn't that big of a deal to me. I think I'm a person who is able to look at a function call and not have the desire to dig into its source, though, which I don't think is the way everybody (and most certainly not the designers of Go) feels. Plus once I understand the concept, even if it's a lot less universally applicable than fold, I can reuse my understanding of it throughout the system and possibly throughout multiple systems.
Like you said, I think this is largely a subjective thing. I just find it objectionable when people, on either side of the fence, come in and say "abstracting over concepts and possibly making them first class is always better" or "...always worse."
One interesting thing about Go is that functions are more or less the only way to build abstractions and encapsulate computational complexity. So when you're reading code, if it's not a function call, you can more or less predict it's (fixed) cost. And good function signatures, good program design, where dependencies are explicit and side effects are minimized, does I think let you reliably make assumptions about functions without reading their source. But yeah I see your perspective!
That is by design, and when it comes to "programming in the large" - a winning formula. I keep repeating this response: I worked on a Perl codebase with a medium-sized team. Perl is very expressive, and my teammates did not hold back. I can tell you that is a nightmare to debug or add a new edgecase to a "clever" Perl 1-liner, usually it involved making the code "less expressive". So, I'll take Go over the more expressive languages in a team setting any day.