
Golang Diaries I - richmok
http://www.tbray.org/ongoing/When/201x/2013/06/16/Go-Love-Hate
======
Symmetry
_I’m also unconvinced that the distinction between := and = is essential;
feels like unnecessary ceremony._

I think that's actually almost my favorite thing about the language, I don't
know how many times I've wished that Python and Lua worked that way. Having a
low-ceremony means of declaration while also preventing you from accidentally
over-assigning something when you want to be declaring it is really nice.

------
Jabbles
" _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+array+literals)

[https://encrypted.google.com/#q=go+repl](https://encrypted.google.com/#q=go+repl)

...

~~~
vanderZwan
He could be stuck in a filter bubble.

------
voidlogic
>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](https://code.google.com/p/golangide/downloads/list)
Source:
[https://github.com/visualfc/liteide](https://github.com/visualfc/liteide)

As for the merit if REPL over something like the go playground
([http://play.golang.org/](http://play.golang.org/)) or a debugger, I can't
say. Most of the code I wrote before Go was C/C++/C#/Java.

~~~
cynwoody
The main benefit of a true REPL over the Go playground is that a REPL allows
you to interact with the state of a partially-run program. By contrast, the Go
playground is one-shot. Your code runs quickly, but completely, and you see
the result. But you can't examine the data structures interactively.

For instance, when debugging a simple Python utility, I will often put the
steps it goes thru into individual functions and tie them together with a
main() function normally called via "if __name__ == '__main__':main()".

That allows me to import the program as a module into a REPL session, from
which I can call the functions individually and examine the resulting outputs.
If something's not right, I can alt-tab to the editor, make a change, save the
program, and use the reload() function in the REPL. Sometimes, the REPL-
obtained data is all I'm looking for, and I never get around to running the
code from the command line.

~~~
voidlogic
OK, in a compiled language like Go a REPL implementation looks hard- am I
wrong? It seems like besides the code being R/O a debugger is pretty close
too.

When testing with a debugger I setup my program to run the same tests, read
the same input etc. In this way I can use the debugger, find and issue, change
the code, set a break point, re-run the program and I'm right back where I
left off. This sounds functionally similar to using a REPL.

------
Smerity
The post is fun, thanks. I like Tim's idea of "taking the journey" with a
programmer on discovering new content. It's certainly the best way to
introduce the topic to others. All the potential sticking issues have been
handled for you!

I was also excited when he said "I filed a bug on June 6th, and it was fixed
on the 12th. Gotta love that.". There is no better feeling than sending a pull
request and having someone thank you, merge it, and fix the issue within a few
hours or days of you sending it.

In this case, however, I think his joy may be premature. Rob Pike replied to
the bug saying it was indeed an issue and either the code or documentation
should be fixed. Having Rob Pike reply is a good start, considering he's the
primary author of Go. Someone else then came along and fixed it in a way the
article's author is unhappy with, though[1].

[1]:
[https://code.google.com/p/go/issues/detail?id=5655](https://code.google.com/p/go/issues/detail?id=5655)

~~~
unwind
Yeah, the final comment on the bug is also from Mr Bray, and isn't exactly a
"thanks".

I was quite surprised by that combination after reading the diary blog post,
they don't really match up.

~~~
corresation
Agreed, that bug is quite a bit different from the impression in the blog
post. Tim is completely right, however: Why can't he use the automatically
differentiated leading underscore test? And the fix of the documentation is,
as he mentioned, just as wrong as it already was. Now I wonder if his bug
comment was sarcastic, because it would be had I written it.

~~~
BarkMore
_Why can 't he use the automatically differentiated leading underscore test?_

The go tool currently ignores all files with a leading '_' in the name.
Changing the tool to use a file with the name '_test.go' complicates the rule
for ignored files and might break an existing project. The workaround of using
'all_test.go' is not onerous.

------
jzelinskie
>Golang will not let you compile if there’s an import or declared variable
that’s unused. OK, I understand that Cleanliness Is Next To Godliness, but
this is seriously slowing me down; probably a third of my attempts to run my
damn program fail because I’ve forgotten to remove debugging apparatus, or
I’ve sketched in a variable but not used it yet. How about a compiler switch
or something?

I don't find this an issue with vim using syntastic. When I save, I get
notified in the gutter of issues like this and then I can use the official go
vim support to do things like :Drop to remove the import without even
navigating to the imports section. Syntastic picks up on most issues before
you even think of compiling.

>There doesn’t seem to be a way to declare a constant array, what in a Java
class I’d call final static String[] COLS = {"Red", "Blue"};

Constants in Go are evaluated at compile time and arrays don't exist at
compile time. You can manage at the package level by using a unexported
variable then exporting a function that returns it.

~~~
saljam
Furthermore, Java is quite happy to let you do COLS[1] = "Green". All that is
constant about that array is the reference.

------
coldtea
> _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 array literals" and "go repl") return a page full of Go
related results (the documentation, the golang-nuts discussion list, related
blog posts, etc).

What exactly is painful about it?

~~~
willvarfar
The filter bubble! After you've googled enough, google starts knowing what
domain you are searching in.

If you search for 'array literals' you'll likely get Go results at the top
rather than, say, Javascript (which is what I get, I just tried).

~~~
Jabbles
Click the button in the top right of the search results to turn personal
search off. I get Javascript results anyway.

~~~
willvarfar
I often switch between languages and it takes google just a handful of queries
to catch up and I can start omitting the language again...

I sometimes wonder if they have special case code for programming-related
subjects, but I guess its more general than that. Clever googlers!

------
scott_s
_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 consciously making it slightly more painful for small
projects because they're designing for large projects.

~~~
zzzcpan
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.

~~~
viscanti
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.

~~~
jlarocco
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.

------
wrl
_" 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.

~~~
msie
Yes, it's weird how some people deny their existence in Javascript!

~~~
Roboprog
That's because Javascript is a line oriented language like Ruby! :-)

Use semicolons like you would use colons in BASIC: to stack multiple
statements on a line.

The C programming language is not the be-all & end-all template for
programming languages.

------
zzzcpan
> Golang will not let you compile if there’s an import or declared variable
> that’s unused. OK, I understand that Cleanliness Is Next To Godliness, but
> this is seriously slowing me down; probably a third of my attempts to run my
> damn program fail because I’ve forgotten to remove debugging apparatus, or
> I’ve sketched in a variable but not used it yet. How about a compiler switch
> or something?

Agreed, this is really annoying and makes it very hard to prototype things.

------
karka91
Golang ins't all that new. I don't get it why so many articles exploring the
basics get so much spotlight.

It's a good language. I'd like to see more articles about things made with it
and not about it.

~~~
jeremymcanally
Ruby was about 10 years old before most people took notice. :) It often takes
time for languages to get traction.

------
Roboprog
I never worked with Algol, but I worked with Pascal years before C. The part
of Go syntax that seems "bastardized" to me is trying to hide the language in
C syntax, when clearly it seems more like Modula.

Type blocks? Var blocks? Types-after-names? Makes sense to me (a former Turbo
Pascal user)

:-P

~~~
claystu
This is exactly what I think too.

I suspect the only reason they kept C's pointer token instead of using ^ is to
maintain the fiction that this is really a 'C' family language rather than a
derivative of Pascal and Modula.

~~~
Roboprog
Don't forget that one of the creators went to University of Zurich. (did he
study with Wirth???)

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

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

~~~
BarkMore
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".

------
zwieback
This is exactly the kind of thing I was looking for - more please. I'm
interested in golang but don't need general programming tutorials. How go is
different from other languages and what it's idiosyncracies are is good to
know.

