Yes but every time I've seen it, it's in a small scope, it's very obvious the type of the variable and what it's doing. It's really not as bad as it seems once you spend some time in go.

I felt like you did and I totally get it it. It isn’t what it seems like, though.

It’s actually very pragmatic and once you embrace it, it makes writing and reasoning about Go much easier than you’d expect.

The way you write Go isn’t like most languages I’ve encountered. You write a lot of local variables which typically come from well-named structs and functions, so keeping track of what’s what is extremely low effort. Tracing what something is happens very naturally, and arguably easier because there’s less data to parse.

It’s counter intuitive, but I was extremely resistant to it and now I like it (when writing Go) quite a bit. I don’t do this in other languages I write (like TypeScript or Rust); it’s definitely a Go-ism.

There's a convention to prefer short (1-3 characters) abbreviated identifiers for trivial things. For example, a loop variable:

    i := 0

But a more complex thing might get a fuller name:

    producer := NewProducer()

In the earlier case with the HTTP handlers, "r" and "w" are conventions. They appear so often that it's counterproductive to give them full names. People who read the code would be confused.

Before Go, I did a lot of Java and Ruby, and felt like you did, and went against the conventions. But the code I wrote back when I started with Go now looks foreign to me.

Variable naming conventions are different from syntax, right? The variables in your own code will be the ones you named.

I think this is more prevalent in Go though because go forces you to make many more local variables (since error handling prevents you from composing expressions), and when you need lots of useless local variables for intermediate values with no externally imposed meaning people tend to fall back to things that are easy to write.

Choosing to name variables with a single character has nothing to do with syntax. At most it could be considered idiomatic, but there's no reason to slavishly follow every idiomatic choice, just as there isn't in natural language.