Specific reasons go is more readable than your run of the mill language off the top of my head:
1. Culture of small api surfaces. The number one cause of complexity is having large apis with many arguments and knobs and whistles. Every time you interact with a large api you pay a decision/comprehension tax. Go culls this dramatically.
2. Small api in the language itself. When reading and writing the language itself you do not have to scratch your head at new creative constructs. This is the most commonly cited reason, and it’s a real reason.
3. No inheritance. The lack of immense hierarchies of data structures means it’s dead simple to find out where the implementation for a given function lives.
4. Gofmt
5. Simple error handling. Easy to wrap with all the contextual info you would need to fix a bug.
6. preference for short names. This visually lightens the page when you’re reading code, enhancing clarity.
7. Packages. You always know when code is being imported from somewhere else and precisely where it’s imported from, as you must reference the package every time you reference its code.
8. No constructors.
So no, it’s not a misconception, go actually is very readable and more so than most languages.
Agree, this is something many other langauges/systems can learn from.
> 2. Small api in the language itself. When reading and writing the language itself you do not have to scratch your head at new creative constructs.
Mixed feeling here. Sacrificing expressiveness isn't always worth it. The right tradeoffs are difficult to find, but IMO go is too far in the direction of offering too few useful constructs.
> 3. No inheritance. The lack of immense hierarchies of data structures means it’s dead simple to find out where the implementation for a given function lives.
I actually disagree here. Its no easier than any other language (and often harder), because your function or struct will accept some interface I, and call a function or functions of that interface. Finding the correct implementation of the interface is a matter of figuring out where/how the dependency was injected. Even with good codesearch and cross-reference tools, this can be difficult if there are more than 1-2 implementations of an interface.
Lack of multiple inheritance is absolutely a good thing, and composition in general does have value though.
> 4. Gofmt
Yes.
> 5. Simple error handling. Easy to wrap with all the contextual info you would need to fix a bug.
Mixed, I think explicit error handling (as opposed to raise/catch) is fine. I think better support for concise simple cases (the try macro, better Result types like in rust, or something like Google's ASSIGN_OR_RETURN macro) would all be strictly better for the language.
> 6. preference for short names.
I abhor this. Perhaps it depends on the exact culture, but at Google for example, the result of this is names that are only abbreviations, which requires mental translation to what the thing should be, making reading new code harder. The canconical example of this would be `fpb` vs `foo_pb`. This is maybe okay if you're dealing with a single proto, but if you have a number of related ones, you end up with abbreviation soup trying to remember which of rpcpb, rcpb, crpb, and bcpb you want.
> 7. Packages
This is, I think, a thing that only matters if you're coming from C/C++. So like sure?
> 8. No constructors.
I guess, I'm not sure how this aids readability, I guess you mean that it forces you to have named factories for any complex instantiation, instead of default or magic constructors?
1. Culture of small api surfaces. The number one cause of complexity is having large apis with many arguments and knobs and whistles. Every time you interact with a large api you pay a decision/comprehension tax. Go culls this dramatically.
2. Small api in the language itself. When reading and writing the language itself you do not have to scratch your head at new creative constructs. This is the most commonly cited reason, and it’s a real reason.
3. No inheritance. The lack of immense hierarchies of data structures means it’s dead simple to find out where the implementation for a given function lives.
4. Gofmt
5. Simple error handling. Easy to wrap with all the contextual info you would need to fix a bug.
6. preference for short names. This visually lightens the page when you’re reading code, enhancing clarity.
7. Packages. You always know when code is being imported from somewhere else and precisely where it’s imported from, as you must reference the package every time you reference its code.
8. No constructors.
So no, it’s not a misconception, go actually is very readable and more so than most languages.