"Nice C-flavored code (there’s even ++) but look, Ma, no semicolons!" The hate for semicolons is far, far more annoying to me than semicolons ever are.
Yes, it's weird how some people deny their existence in Javascript!
Golang Diaries I
31–40 of 79 posts
Re: Golang Diaries I
#32Golang 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 consciously making it slightly more painful for small projects because they're designing for large projects.
Re: Golang Diaries I
#33> 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…
[deleted]
Re: Golang Diaries I
#34Earlier 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, thus two people can search for the same term and get different results. Going back to the original point raised, I too have gotten into the habit of searching for " go lang [query] "…
> 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 related. (and that's without me dipping into incognito mode)
People like yourself and the OP can love to prove people wrong and argue that same popular searches work perfectly for you, but until you've spent a few months learning the language and thus making frequent searches online like myself and the author have, all you're doing is making pointless arguments (i mean does it really matter that much to you when you're not actively developing in the language?) which are based upon flawed experiments (as already discussed) and inexperience.
If that sounds condescending, then I'm sorry, but I've been working in Go for > 6 months now -so I'm still a new comer- but even just in that time I've noticed how poor the results are without specifying "lang" in the criteria. So I resent having a non-go developer tell me that I'm imagining the last 6 months of online research. Particularly when several (read: not just one other, but several other) Go developers have spoken up in this very same thread and confirmed the same issues I've been raising. This isn't some blip in Google's results. This is a genuine issue with the searchability of "Go".
But don't just take my word for it, here's some screenshots:
Re: Golang Diaries I
#35Golang 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.
Re: Golang Diaries I
#36Golang 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.
Go is a rather opinionated language. They could produce a warning, but then with large projects, one has to decided, should all warnings be made errors? Will there be exceptions to the rule? They simplified that for large projects by making one decision, and forcing it on everyone.
(Please note that I am explaining what I think their motivations are. I am not arguing for the perspective.)
Re: Golang Diaries I
#37Golang 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.
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 to import packages you're not using, and for some reason can't spend the time to comment those out, GO probably isn't for you. I just haven't heard of a case where doing otherwise would have been helpful.
Re: Golang Diaries I
#38>The second big gripe is that Golang has neither an IDE nor a REPL.
The IDE part is not true at all, why do people keep saying this? LiteIDE (aka golangide) works great, I use it all day everyday. It has syntax highlighting, autocomplete, gofmting, building, debugging, etc and is very lightweight.
Downloads: https://code.google.com/p/golangide/downloads/list Source: https://github.com/visualfc/liteide
As for the merit if REPL over something like the go playground (http://play.golang.org/) or a debugger, I can't say. Most of the code I wrote before Go was C/C++/C#/Java.
Re: Golang Diaries I
#39Earlier 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 don't know how people write their code, but I don't like thinking about satisfying compiler when I'm working on some idea, it takes some of my thinking power. I'd rather do that later, probably together with unit tests.
Re: Golang Diaries I
#40> 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…
When I recall starting to investigate Go it was made pretty clear to always use "golang" for Googling. This seemed an odd gripe to me.