Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang Diaries I

tbray.org

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Golang Diaries I

#41

Post by jlarocco »

viscanti wrote: post #37
zzzcpan wrote: post #35

Earlier quoted context omitted.

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

What's the argument for allowing un-used imports? I've never run into a case where I wished I had imported something but didn't want to use it If you're looking at future code, you can accomplish that by commenting out the import. But I've never run into the situation where writing future code has been good, or where I wouldn't have remembered to import the package I needed when I wrote that code. If you really need…

I think this is a matter of the way an individual person writes code, and not something that can be generalized by saying "this is never useful" or "this is always useful". Some people will find it annoying, others not.

I personally find it annoying because I compile often. In my workflow I write code for a few minutes then compile it and run some quick tests or even run it through the debugger to make sure everything is working the way I expect. If everything checks out I start on the next bit. I may be adding a feature that I know in advance will use libraries xxx, yyy, and zzz. The natural thing to do is to add those imports when I open the source files that will use them, then get to work implementing the feature.

Another useful reason is to import a library just to make sure it's installed correctly, before writing the code that uses it, although that's less common.

Re: Golang Diaries I

#42

Post by jff »

zzzcpan wrote: post #35
scott_s wrote: post #32

Golang will not let you compile if there’s an import or declared variable that’s unused. I think that is the result of an explicit design goal of Go: optimizing for large projects that involve many files and packages developed by many people. Having extraneous package or variable declarations in parts of a program are not an issue for small, one-off exploratory programs, but can be for large projects. So they're cons…

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

People ignore warnings. Want proof? Go grab damn near any open source project and compile it. It's almost guaranteed that the default compile options, chosen by the authors, will generate dozens if not hundreds of warnings. Everyone's so very noble at the start of a project, "We shall turn on all warnings, and then fix them!", but really once the program compiles and seems to run properly, all that goes out the window.

Re: Golang Diaries I

#43

Post by BarkMore »

rgbrgb wrote: post #28
NateDad wrote: post #22

Please call it Go, not golang. Golang is the domain name of the language's website, a useful hashtag, and an occasionally useful search term. It is not the name of the language should not be used as such. The language is Go, it should be called Go.

He explains in the article that he does this as a search differentiator.

That's why he did it, but it's not necessary. Google search can determine that a page is about the Go programming language without repeated use of "golang".

Re: Golang Diaries I

#44

Post by zzzcpan »

jff wrote: post #42
zzzcpan wrote: post #35

Earlier quoted context omitted.

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

People ignore warnings. Want proof? Go grab damn near any open source project and compile it. It's almost guaranteed that the default compile options, chosen by the authors, will generate dozens if not hundreds of warnings. Everyone's so very noble at the start of a project, "We shall turn on all warnings, and then fix them!", but really once the program compiles and seems to run properly, all that goes out the windo…

Perl is one example, where people usually have all warnings enabled and keep their code warning-free. I guess it depends on the community.

Re: Golang Diaries I

#45

Post by alayne »

laumars wrote: post #34
coldtea wrote: post #20

Earlier quoted context omitted.

> Maybe Google is tailoring your results to bring back sites that include the programming language based on a) your past searching habits and b) the emerging trends for those specific search patterns. Google's results are highly tailored Well, tried the same thing logged out from Google, in incognito mode and with cookies turned off. Same results. I can also try to proxy my search to a remote VPS I never use and see…

> Well, tried the same thing logged out from Google, in incognito mode and with cookies turned off. Same results. Now lets try it with a search phrase that hasn't been hammered to death: "go http listener" [1] https://www.google.co.uk/search?q=go+http+listener [2] https://www.google.co.uk/search?q=go+lang+http+listener In example 1, only 1 item on the 1st page is related to Golang. In example two, every result is rel…

Bing's results are much more entertaining.

Re: Golang Diaries I

#46

Post by thezilch »

Jabbles wrote: post #2

" After a few painful in­stances of search­ing for things like “go array lit­er­als” and “go repl” I got into the habit of stick­ing with Golang; and so will this diary. " https://encrypted.google.com/#q=go+array+literals https://encrypted.google.com/#q=go+repl ...

Maybe not using Google -- using DDG (or worse)? The results are an order of magnitude richer with the former.

Re: Golang Diaries I

#47

Post by levosmetalo »

coldtea wrote: post #3

> First, the name. “Go” has too many meanings and is among the world’s lousiest Google search disambiguators. Enough with this old wives tale. Yes, "Go" is too generic. Nevertheless, Google understands it just fine. Case in point: > "After a few painful instances of searching for things like “go array literals” and “go repl” I got into the habit of sticking with Golang; and so will this diary. Both his examples ("go…

So, if you want to use Go you pretty much have to use Google search since no-one else made a special case for Go. It is a bit of a problem for some people.

Re: Golang Diaries I

#48

Post by cynwoody »

zzzcpan wrote: post #35
scott_s wrote: post #32

Golang will not let you compile if there’s an import or declared variable that’s unused. I think that is the result of an explicit design goal of Go: optimizing for large projects that involve many files and packages developed by many people. Having extraneous package or variable declarations in parts of a program are not an issue for small, one-off exploratory programs, but can be for large projects. So they're cons…

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

I agree. I would like an option to have unused imports and variables ignored during development. But I would also like them gone in the final code, because they are noise inhibiting future human understanding of the code.

It might also be useful to have gofmt auto-remove unused imports and variables.

Re: Golang Diaries I

#49

Post by scott_s »

zzzcpan wrote: post #35
scott_s wrote: post #32

Golang will not let you compile if there’s an import or declared variable that’s unused. I think that is the result of an explicit design goal of Go: optimizing for large projects that involve many files and packages developed by many people. Having extraneous package or variable declarations in parts of a program are not an issue for small, one-off exploratory programs, but can be for large projects. So they're cons…

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

Take a look at this adaptation of a keynote talk on the design of Go, with the title "Language Design in the Service of Software Engineering": http://talks.golang.org/2012/splash.article

Section 7, "Dependencies in Go" addresses this issue: http://talks.golang.org/2012/splash.article#TOC_7. The relevant paragraph states,

The first step to making Go scale, dependency-wise, is that the language defines that unused dependencies are a compile-time error (not a warning, an error). If the source file imports a package it does not use, the program will not compile. This guarantees by construction that the dependency tree for any Go program is precise, that it has no extraneous edges. That, in turn, guarantees that no extra code will be compiled when building the program, which minimizes compilation time.

Re: Golang Diaries I

#50

Post by Roboprog »

zzzcpan wrote: post #35
scott_s wrote: post #32

Golang will not let you compile if there’s an import or declared variable that’s unused. I think that is the result of an explicit design goal of Go: optimizing for large projects that involve many files and packages developed by many people. Having extraneous package or variable declarations in parts of a program are not an issue for small, one-off exploratory programs, but can be for large projects. So they're cons…

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

It makes it easier for me to read your code when I checkout a copy: there's not a bunch of unused cruft I have to mentally skip over to look at it. You'll be glad later that I'm not leaving a bunch of left over Rob's stupid crap (TM) that you have to wade through as well :-)

It's not just imports, assigned-but-not-used is also a failure. This keeps the cruft down.

Post reply on HN