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.
"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."
>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.
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.
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.
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].
> Having Rob Pike reply is a good start, considering he's the primary author of Go
According to himself and the Go FAQ he's just one member in the team, the beginnings are described as "Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007"
>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.
>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).
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]" rather than just "go [query]" due to the same frustrations in the past. What the author describes isn't a unique quirk he's experienced, it's actually a very common complaint.
Perhaps these examples weren't the best. When searching for more general things it helps to put in golang. For example "Running go on multiple machines" or "Running go on multiple cores":
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.
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.
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.
> 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.
The language was conceived under four years ago, and only quite recently was considered production ready.
Yes, in the pantheon of programming languages it is very new. Further many of us have stayed at a distance until the ecosystem of supporting libraries and supports are robust enough (I love everything about developing, but my primary concern remains paying the bills and pulling in the lucre, so exploratory or academic languages don't get prioritized).
I am quite sure that a large percentage of HNers are interested in the language, but haven't yet taken the dip and thus are intrigued by things like this.
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)
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.
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.
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.
[+] [-] Symmetry|12 years ago|reply
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|12 years ago|reply
https://encrypted.google.com/#q=go+array+literals
https://encrypted.google.com/#q=go+repl
...
[+] [-] vanderZwan|12 years ago|reply
[+] [-] thezilch|12 years ago|reply
[+] [-] voidlogic|12 years ago|reply
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.
[+] [-] cynwoody|12 years ago|reply
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.
[+] [-] Smerity|12 years ago|reply
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
[+] [-] unwind|12 years ago|reply
I was quite surprised by that combination after reading the diary blog post, they don't really match up.
[+] [-] zurn|12 years ago|reply
According to himself and the Go FAQ he's just one member in the team, the beginnings are described as "Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007"
[+] [-] jzelinskie|12 years ago|reply
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|12 years ago|reply
[+] [-] justinhj|12 years ago|reply
[+] [-] coldtea|12 years ago|reply
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?
[+] [-] laumars|12 years ago|reply
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]" rather than just "go [query]" due to the same frustrations in the past. What the author describes isn't a unique quirk he's experienced, it's actually a very common complaint.
[+] [-] willvarfar|12 years ago|reply
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).
[+] [-] pothibo|12 years ago|reply
[+] [-] Gazler|12 years ago|reply
https://www.google.co.uk/search?q=running+go+on+multiple+mac...
vs
https://www.google.co.uk/search?q=running+golang+on+multiple...
[+] [-] pbreit|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] levosmetalo|12 years ago|reply
[+] [-] scott_s|12 years ago|reply
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|12 years ago|reply
[+] [-] wrl|12 years ago|reply
The hate for semicolons is far, far more annoying to me than semicolons ever are.
[+] [-] msie|12 years ago|reply
[+] [-] zzzcpan|12 years ago|reply
Agreed, this is really annoying and makes it very hard to prototype things.
[+] [-] karka91|12 years ago|reply
It's a good language. I'd like to see more articles about things made with it and not about it.
[+] [-] jeremymcanally|12 years ago|reply
[+] [-] corresation|12 years ago|reply
Yes, in the pantheon of programming languages it is very new. Further many of us have stayed at a distance until the ecosystem of supporting libraries and supports are robust enough (I love everything about developing, but my primary concern remains paying the bills and pulling in the lucre, so exploratory or academic languages don't get prioritized).
I am quite sure that a large percentage of HNers are interested in the language, but haven't yet taken the dip and thus are intrigued by things like this.
[+] [-] Roboprog|12 years ago|reply
Type blocks? Var blocks? Types-after-names? Makes sense to me (a former Turbo Pascal user)
:-P
[+] [-] claystu|12 years ago|reply
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.
[+] [-] NateDad|12 years ago|reply
[+] [-] rgbrgb|12 years ago|reply
[+] [-] zwieback|12 years ago|reply