6 ms·

Golang Is Good, Structure Is Bad

24 points by azbshiri 9y ago

bitwize 9y ago
More like "Golang is Good, Rubylang is Better, I write all my Golang code to look like Rubylang".
- askoma 9y ago
  You made my day.
Vendan 9y ago
func NewBaz() Baz { in a package called baz is already unidiomatic, in cases like that, the function should just be called `New`, leading to usage like: thing := baz.New() which, to my eyes, is perfectly fine.
- dullgiulio 9y ago
  And the returned Baz should be a pointer.
  - Vendan 9y ago
    .... Only if it's meant to be a pointer. Don't just make everything a pointer.
chank 9y ago
"Golang is good, but I still don't get how packages work yet."
nerdponx 9y ago
FWIW this is a problem for Python as well: import requests # uh-oh! requests = [] for url in ['http://google.com', 'http://duckduckgo.com']: with requests.get(url) as req: requests.append(req) You'll get AttributeError: 'list' object has no attribute 'get' because your sensibly-named `requests` object is shadowing the module. Obviously you could re-name it to `reqs` or something, but having module objects in a top-level global namespace can sometimes non-trivially increase cognitive load. By comparison, R and Common Lisp have special syntax for accessing objects in namespaces. There are good and bad approaches to both. Having namespaces/packages exist alongside other objects makes it easier to reflect on their contents, obviating the need for specialized access functions.
nine_k 9y ago
tl;dr: export one type per package to avoid shadowing of package names. Can't help but quote: "Design patterns are bug reports filed against the language" (Peter Norvig, iirc).
- dullgiulio 9y ago
  Not really, not in this case. The author of the article should take some time to learn idiomatic Go. "[...] I can use packages as metaphore for classes" is a big red-flag that one doesn't have the fundamentals. When one writes Go, writes in Go. Not in Ruby, not in Lisp, not in Haskell. In Go.
  - dozzie 9y ago
    You don't understand. Good programmer can write in Fortran in any language.
alvil 9y ago
You can also use dot import ( . "fmt" ) .... // now call function without prefix Println("Read more docs")
- nkozyra 9y ago
  Obviously this is fine only if you feel safe that no two imported packages share the same function/variable names. import ( . "fmt" . "log" ) func main() { Println("broken!") }
lowmagnet 9y ago
`go vet -shadowstrict` works pretty well for the shadowing problem. Look at go's `net/url` package. The type is `URL` because it's exported, there's no `New` function. It instead uses the conversational `Parse`. `url.URL` does stutter, and `url.Parse` probably belongs in the url module, with the type in `net` to reduce stutter. This would make `net/URL` a clearer non-stuttering type. It would also make 'net/url' a library of functions with which `net/URL`s are manipulated and a clean-room fashion.

24 points by azbshiri 9y ago

bitwize 9y ago

More like "Golang is Good, Rubylang is Better, I write all my Golang code to look like Rubylang".

askoma 9y ago
You made my day.

Vendan 9y ago

func NewBaz() Baz { in a package called baz is already unidiomatic, in cases like that, the function should just be called `New`, leading to usage like: thing := baz.New() which, to my eyes, is perfectly fine.

dullgiulio 9y ago
And the returned Baz should be a pointer.
- Vendan 9y ago
  .... Only if it's meant to be a pointer. Don't just make everything a pointer.

chank 9y ago

"Golang is good, but I still don't get how packages work yet."

nerdponx 9y ago

FWIW this is a problem for Python as well: import requests # uh-oh! requests = [] for url in ['http://google.com', 'http://duckduckgo.com']: with requests.get(url) as req: requests.append(req) You'll get AttributeError: 'list' object has no attribute 'get' because your sensibly-named `requests` object is shadowing the module. Obviously you could re-name it to `reqs` or something, but having module objects in a top-level global namespace can sometimes non-trivially increase cognitive load. By comparison, R and Common Lisp have special syntax for accessing objects in namespaces. There are good and bad approaches to both. Having namespaces/packages exist alongside other objects makes it easier to reflect on their contents, obviating the need for specialized access functions.

nine_k 9y ago

tl;dr: export one type per package to avoid shadowing of package names. Can't help but quote: "Design patterns are bug reports filed against the language" (Peter Norvig, iirc).

dullgiulio 9y ago
Not really, not in this case. The author of the article should take some time to learn idiomatic Go. "[...] I can use packages as metaphore for classes" is a big red-flag that one doesn't have the fundamentals. When one writes Go, writes in Go. Not in Ruby, not in Lisp, not in Haskell. In Go.
- dozzie 9y ago
  You don't understand. Good programmer can write in Fortran in any language.

alvil 9y ago

You can also use dot import ( . "fmt" ) .... // now call function without prefix Println("Read more docs")

nkozyra 9y ago
Obviously this is fine only if you feel safe that no two imported packages share the same function/variable names. import ( . "fmt" . "log" ) func main() { Println("broken!") }

lowmagnet 9y ago

`go vet -shadowstrict` works pretty well for the shadowing problem. Look at go's `net/url` package. The type is `URL` because it's exported, there's no `New` function. It instead uses the conversational `Parse`. `url.URL` does stutter, and `url.Parse` probably belongs in the url module, with the type in `net` to reduce stutter. This would make `net/URL` a clearer non-stuttering type. It would also make 'net/url' a library of functions with which `net/URL`s are manipulated and a clean-room fashion.