Recent searches
Search options
Programming thought: there's an underappreciated aspect to Go's syntax that I miss in almost all other languages, and might be the single biggest reason I still use Go so frequently even though there are plenty of other languages that I prefer that might be just as good (otherwise) for a specific task. And that's the *consistency* and *grep-ability* of the language. 
Most developers run into the problems this causes in other languages, but they don't actually think about it or know what the problem is, they just use tools (ie. IDEs, language servers, etc.), without realizing that this is a problem in the language itself. But what happens if you wind up on a system where you don't have your favorite IDE or plugin or what not?
If I'm looking at a function call that's not doing what I expect in Go, I can "grep func Foo(" and go straight to the definition. But what if I were using, say, Javascript? Is it "Foo = (" or "function Foo("? Or maybe "Foo = function("? Sure, it's not the end of the world, but it makes you context switch and slows you down.
EDIT: Actually, bad example, Go does support anonymous function assignment too, but still, the pattern holds for other stuff and it's fewer ways you can do that in Go.
The same is true on a more meta level: all definitions involve a keyword and then the thing, or you can just set a literal. Eg. a struct literal looks like this: "foo := struct{a: b}{}", defining a type looks like this: "type struct{a: b}"—notice the similarities? The struct definition is *identical* and what comes before it determines if it's a type definition or a literal assignment. Other languages have special keywords to differentiate between the two, and no way to find a type definition.
Ie. in Rust in Rust if you want to define a struct you use the struct keyword and if you want to define an interface (more or less) you use the "trait" keyword. What if you see an identifier and don't know what type it is? How do you find its declaration? It's not the end of the world, it's just a little annoyance that makes it necessary to add more tools if you want your day to not be filled with problems.
Anyways, that's all, there are literally dozens of times a day where the consistency of the language makes my day easier or harder depending on what I use. They're all small annoyances that don't really matter in and of themselves, but over the course of a day it saves a ton of time, and requires less tooling to work around the issue, which means more consistency between different environments and a smaller footprint for more bugs that will annoy me later. The syntax keeps things simple.
@sam When casual users express annoyance due to lack of features and lack of sophisticated ways of expressing something, they often miss that the reductionist simplicity makes it very easy to maintain large systems at scale.
Reflecting on large scale changes, simple stream processing like sed and similar can take one very far. That there is generally one, low syntax morphology for an idea makes such things trivial. And this has left almost no need for example-based refactoring.
@sam Refactoring needs are bimodal for me: simple stream processing or small programs driven by rewriting AST and emitting it back out, which is trivially easy with the ecosystem.
Also the simple organization concept of packages and imports. This makes determining where an identifier comes from trivial. Importing * from another namespace into the current one is a thing in other language ecosystems that I find intolerable (thankfully dot imports are effectively not used in Go).
@sam I did some challenged on https://www.codewars.com/ a while ago in both JS and Go
What I noticed was that often there would be a very clever one line solution in JS
but many many variations
Whereas the Go version would often just have one obvious way of doing it - everyone came up with the same answer.
This makes GO so much more readable,
