
Golang Is Good, Structure Is Bad - azbshiri
https://github.com/azbshiri/gigsib
======
Vendan

      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
And the returned Baz should be a pointer.

~~~
Vendan
.... Only if it's meant to be a pointer. Don't just make everything a pointer.

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

------
nine_k
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
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
You don't understand. Good programmer can write in Fortran in _any_ language.

------
nerdponx
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.

------
lowmagnet
`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.

------
alvil
You can also use dot

    
    
      import (
              . "fmt"
      )
      
      ....
      
      // now call function without prefix
      Println("Read more docs")

~~~
nkozyra
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!") }

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

~~~
askoma
You made my day.

