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

Four days of Go

evanmiller.org

Post reply on HN
Print view View original

11–20 of 187 posts

Re: Four days of Go

#11

Post by tormeh »

zimbatm wrote: post #6

That was quite fun to read. The point about Go being too pedantic and thus hindering exploration is something I've felt too. Some of that pain was mitigated by the Sublime Text Go plugin that has shortcuts to add/remove imports.

This is generally a tradeoff you have to make in programming language design. Should the checker enforce good code or should it let all but the most broken code through in the name of exploratory programming?

I would recommend using Python or possibly Clojure to experiment with and then translate the code to a language that will help you catch bugs (Ada/a functional one) when you know exactly how the problem is solved.

Re: Four days of Go

#12

Post by tormeh »

jgrahamc wrote: post #2

In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…

Which is why Go has goto's and pointers. Got it. No, Go's adherents are just sloppy in a different way. I have many bad things to say about Haskell, but I admire Haskellers lack of sloppiness. I cannot say the same about Gophers.

Re: Four days of Go

#13

Post by mike_hearn »

aperture wrote: post #3
jgrahamc wrote: post #2

In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…

I enjoyed that the author readily admits to his own faults concerning Go too: In this telling, the story of Go is really a tale of revenge, not just against slow builds, but against all kinds of sloppy programming. Which in my opinion is too bad, because I myself am a sloppy programmer. This really does seem to be the approach I see with the Go digest mailing list. What I don't understand though is the ease of import…

Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project!

Given this background and the Go designers focus on Google's internal needs, it's perhaps not surprising that you can import code from github .... but not specify which version you want. (unless that is now fixed?)

Re: Four days of Go

#15

Post by donlzx »

IMO, there are two different opposite directions in programming languages and tools approaches,

1) The artistic approach which is very flexible and requires creative thinking and deep understanding of the essence of computing. However, you can easily shoot yourself with it. Languages of this type are for code guru, knights and hackers.

2) The engineering approach which has rigid rules for efficiency and social cooperation. It is less error-prone but tend to suppress diversity and discovery. Golang belongs to this category. To me, the core Go authors are more of engineers than artists :)

I use Go for work and simple command-line tools for myself. It is also great for cooperation in well defined scenarios, e.g., Web back-end service. When it comes to creative works, I'd rather avoid it.

Re: Four days of Go

#18

Post by skj »

tormeh wrote: post #12
jgrahamc wrote: post #2

In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…

Which is why Go has goto's and pointers. Got it. No, Go's adherents are just sloppy in a different way. I have many bad things to say about Haskell, but I admire Haskellers lack of sloppiness. I cannot say the same about Gophers.

Like any decision, there are some trade-offs involved.

Re: Four days of Go

#20

Post by rakoo »

MindTwister wrote: post #16

I find that every issue I had with unused imports disappeared when I started using goimports: http://godoc.org/golang.org/x/tools/cmd/goimports

There are unused imports, solved easily with goimports, and then there are unused variables, which AFAIK are not solved by any tool. I dig what the author says regarding "explorability" hindered by all those errors popping up.

It's also funny to see errors solved automagically by tools instead of manually by the developer; there used to be a time where IDEs where voluntarily avoided because they did too many magic things to your code and to your project, and true hackers should be able to work with only a text editor and the compiler. I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...)

Post reply on HN