this post was submitted on 19 Jun 2025
98 points (87.1% liked)
Programmer Humor
36878 readers
150 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The Go programming language documentation makes a big deal about how it "reads from left to right." Like, if you were describing the program in English, the elements of the Go program go in the same order as they would in English.
I say this as someone who likes Go as a language and writes more of it than any other language: I honestly don't entirely follow. One example they give is how you specify a type that's a "slice" (think "list" or "array" or whatever from other languages) of some other type. For instance a "slice of strings" would be written
[]string
. The[]
on the left means it's a slice type. Andstring
on the right specifies what it's a slice of.But does it really make less sense to say "a string slice"?
In Go, the type always comes after the variable name. A declaration might look like:
Similarly in function declarations:
Anyway, I guess all that to say I don't mind the Go style, but I don't fully understand the point of it being the way it is, and wouldn't mind if it was the other way around either.
Edit: Oh, I might add that my brain will never use the term "a slice of bytes" for
[]byte
. That will forever be "a byte slice" to me. I simply have no choice in the matter. Somehow my brain is much more ok with "a slice of strings", though.Go's syntax is vastly superior once you have more complicated signatures, then the left-to-right truly matters. For example a variable that contains a pointer to a function that takes a function and an int and returns another function (like a decorator).
In C the order becomes very hard to understand and you really have to read the thing several times to understand the type of fp:
int (*(*fp)(int (*)(int, int), int))(int, int)
In Go, you can just read from left to right and you can easily understand what f's type is:
f func(func(int,int) int, int) func(int, int) int
It's just much more readable.
See: https://go.dev/blog/declaration-syntax
To be fair, the C example could be detangled a lot by introducing a typedef:
True, but that requires writing an additional definition and hides the parameter types, which can be very interesting, and you'd need a typedef for every new param combination I guess. It feels like a solution for a problem that could have been avoided by a better signature syntax in the first place.