> What do you consider syntactic bureaucracy?

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.

Ah, so in this framing, syntax is another way of saying amount of code?

Here's some Rust code

    pub fn read(&self) -> u64 {
      self.counts.values().fold(0, |acc, x| acc + x)
    }

Here's some analogous Go code

    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.

YMMV, of course. None of this is objective.

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!