4 ms·

> Go doesn't force file=module paradigm (preferring the folder to be the basis), Yes, this is what that complaint was about? > however, it doesn't preclude ha

> Go doesn't force file=module paradigm (preferring the folder to be the basis), Yes, this is what that complaint was about? > however, it doesn't preclude having one file per module, if that's what you prefer. > 1. Say, you have an `animal` module, the first place you check for `NewCow()` is `animal/cow.go` This whole subthread was about reading other people's Go code. Of course your own code is going to look organized to yourself! > If you're reading someone else's poorly organized code, you can always use grep. Yeah, ripgrep tends to be what saves me in the end. Still annoying to have to break it out all the time.

sangnoir 6y ago
> Yes, this is what that complaint was about?...This whole subthread was about reading other people's Go code. So the complaint, restated is "Go doesn't prevent other people from writing bad code?" Am I getting you right? If so, well, I have nothing to say about that. edit: I do actually have something to say. I just remembered having to work with an 82,000-line long Perl module file that would defeat any IDE. Fun times. No language can save you from poorly organized projects, whether the modules are file-based or folder-based.
- Nullabillity 6y ago
  I would say it's closer to "Go doesn't do a really simple thing that nudges people towards writing more readable code, while having basically no tradeoffs". Considering the far more tedious tradeoffs that Go does force on users in the name of supposed readability (for example: the lack of generics), I'd consider that a pretty big failure. I don't expect them to be perfect. I do expect them to try.
  - sangnoir 6y ago
    FYI: Go's lack of generics was not related to readability - the Go team didn't have a solution they liked, so instead of saddling the language with a half-assed solution forever, they waited for a more elegant solution. Also: the design of Go generics was recently approved (as in the past month). It's no secret that Go is targeted at "programming at large". Go's design favors larger, fewer modules, how those modules are structured is left to teams/individuals. I may be lucky to work with a great team, but I always find the code where I expect to find it. When I'm starting from scratch, I utilize modules, <$VERB>er interfaces, structs and receiver functions: I cannot remember ever running into an ambiguous scenario where I'm unsure where a particular piece of code ought to go.

sangnoir 6y ago

> Yes, this is what that complaint was about?...This whole subthread was about reading other people's Go code. So the complaint, restated is "Go doesn't prevent other people from writing bad code?" Am I getting you right? If so, well, I have nothing to say about that. edit: I do actually have something to say. I just remembered having to work with an 82,000-line long Perl module file that would defeat any IDE. Fun times. No language can save you from poorly organized projects, whether the modules are file-based or folder-based.

Nullabillity 6y ago
I would say it's closer to "Go doesn't do a really simple thing that nudges people towards writing more readable code, while having basically no tradeoffs". Considering the far more tedious tradeoffs that Go does force on users in the name of supposed readability (for example: the lack of generics), I'd consider that a pretty big failure. I don't expect them to be perfect. I do expect them to try.
- sangnoir 6y ago
  FYI: Go's lack of generics was not related to readability - the Go team didn't have a solution they liked, so instead of saddling the language with a half-assed solution forever, they waited for a more elegant solution. Also: the design of Go generics was recently approved (as in the past month). It's no secret that Go is targeted at "programming at large". Go's design favors larger, fewer modules, how those modules are structured is left to teams/individuals. I may be lucky to work with a great team, but I always find the code where I expect to find it. When I'm starting from scratch, I utilize modules, <$VERB>er interfaces, structs and receiver functions: I cannot remember ever running into an ambiguous scenario where I'm unsure where a particular piece of code ought to go.