Google Go: The Good, the Bad, and the Meh
blog.carlsensei.com
Google Go: The Good, the Bad, and the Meh
1–10 of 126 posts
Re: Google Go: The Good, the Bad, and the Meh
#2So the author wants to type "./foo.go" rather than "go run"? Why not just build your executable, "go build", then you can run/move the resulting executable ./foo.
This really doesn't seem like a big deal / why do I want to compile a utility program every-time I run it?
Re: Google Go: The Good, the Bad, and the Meh
#3Re: Google Go: The Good, the Bad, and the Meh
#4"Go doesn’t suppose the use of a #! on the starting line, which means you can’t just use uncompiled files as utility scripts." So the author wants to type "./foo.go" rather than "go run"? Why not just build your executable, "go build", then you can run/move the resulting executable ./foo. This really doesn't seem like a big deal / why do I want to compile a utility program every-time I run it?
But someone could write shebang-go wrapper to implement this functionality, but a modification to Unix would be needed, since shebang is a magic hack on the '#' character, not configurable,IIRC
Re: Google Go: The Good, the Bad, and the Meh
#5"Go doesn’t suppose the use of a #! on the starting line, which means you can’t just use uncompiled files as utility scripts." So the author wants to type "./foo.go" rather than "go run"? Why not just build your executable, "go build", then you can run/move the resulting executable ./foo. This really doesn't seem like a big deal / why do I want to compile a utility program every-time I run it?
Re: Google Go: The Good, the Bad, and the Meh
#6Re: Google Go: The Good, the Bad, and the Meh
#7I'm really not crazy about the "import github.com/foobar/foo" thing. It seems that systems like CPAN have an advantage in that a) you can roll your own mirror to avoid using an untrusted network and b) should upstream change their VCS etc, the go system requires changes to all files that import the affected module. The go system also seems to ignore the problem of versioning libraries, though I imagine there's probab…
You can use version control commands directly to get code from your own repository mirror or to get specific versions from a repository. As long as you clone the repository to the directory in the workspace corresponding to the import path, all of the other go tools will work with the code.
Re: Google Go: The Good, the Bad, and the Meh
#8Downside: couldn't read past "And what’s up with all the languages that claim all you need are linked lists? I’m sorry, this is not 1958, and you are not John McCarthy".
Did I miss anything amazing in the rest of the article? Thanks in advance.
Re: Google Go: The Good, the Bad, and the Meh
#9 Let’s say I want to declare a pointer to a variable length
array (what Python calls a list and Go calls a slice) of
pointers to FooType objects:
var foo *[]*FooType
It reads very simply ...
What???? Not that it's better in other languages but this makes the article feel like satire. It reads like "The Ugly" and "The Bad".Aside: What's with the completely defective comment syntax on HN? Can anyone give some hints on how to quote and how to escape the star character?
edit: formatting, thanks spacemanaki