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

91–100 of 187 posts

Re: Four days of Go

#91

Post by justicezyx »

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 get the impression that they are doing this because they believe they are 'right'. That makes some people uncomfortable because we programmers like to discuss everything, and argue, and it's hard to come up against people who have what is close to 'faith' in their own beliefs."

They do not just argue, then invent their own wheels. Go is not special in this sense, just another wheel, whose inventors have a stronger sense of righteousness. And I think it is well grounded.

Re: Four days of Go

#92

Post by barosl »

lmm wrote: post #68
jkyle wrote: post #45

Earlier quoted context omitted.

> Go makes coordinating with them a lot easier. What I like about strongly opinionated languages in general is that most of the strong opinions are around trivial features of the languages relative to the complexity of a decently interesting programming problem. Features like formatting, no unused imports, etc. These are typically areas in a project where Parkinson's Law of Triviality rears its ugly head in project p…

I agree with a lot of these (and would be interested in adopting a language that followed them - but one with a decent type system), but I don't think that's the Go innovation. Python had opinions about whitespace and never attracted the same level of hate.

I think Python's mandatory whitespace has a similar nature as Go's unused-as-an-error. They are definitely great in production code, but when I play with code, sometimes I do want to mess them up while adding and removing the parts of the code. Even though I've used Python for more than 10 years, I often feel like "I don't want to indent these lines for now. I wish there were a way to wrap them up without changing the indentation" after copying and pasting some lines.

Re: Four days of Go

#94

Post by hurin »

wwweston wrote: post #85
jlebrech wrote: post #8

no ternary is a smart move tho. makes code more readable for all skill levels.

I'm completely baffled that people find the ternary operator difficult to scan. The concept is simple. The syntax can be terse, but it doesn't have to be. Modestly capable Excel users take advantage of something just like it. The only time I've ever seen it become difficult is when either the conditional or result expressions get hairy or depend on undescriptive variable names. And when that's the case, well, you're…

> The only time I've ever seen it become difficult is when either the conditional or result expressions get hairy or depend on undescriptive variable names.

It's definitely possibly to write obfuscated ridiculous code without the ternary operator -- but I think that's part of the whole "go-lang mentality".

Would I leave unused declarations in production code? No.

Do I have a problem with a compiler that doesn't let me test code with a function call commented out without also commenting out all the other variables/functions that are now unused as a result? Yes.

> I'm at the point where I suspect complaints about the ternary operator are a cargo cult repetition thing, and the developers who are scared of it are scared because they were either taught by someone else to be scared, or they're suffering from a confirmation bias problem where they notice confusing conditionals more when they're associated with the operator.

I definitely don't think Rob Pike and Ken Thompson are getting confused -- it's more like they took a utilitarian view of the situation and decided - if the average code-base is made better or easier to read by this change, then it's worth it.

The over-all result is a language that appears to be easy to pick up and productive at least for those who use it - but it's hardly exciting or fun to code in.

Re: Four days of Go

#95

Post by ChikkaChiChi »

nodivbyzero wrote: post #80
hahainternet wrote: post #14

Wow. For once a fantastic article on Go which is clearly balanced and educated by experience. This is the sort of thing we should see more of on HN IMO.

+1. Agreed. I'm tired to read about startups/success stories/failures.

Your sarcasm is noted. I believe hahainternet was referring to articles that either gloss over the bad parts of a thing, or make specious claims to reinforce their ideas.

Re: Four days of Go

#96

Post by Scramblejams »

I used Go at work to write some utilities which extracted and manipulated values from large text files. It compiled fast and ran fast (at least, compared to the Python it was replacing).

However, I learned that Go is a language conceived for Programming in the Large, and I found out (once again, thanks Java) that I don't like languages for Programming in the Large.

But if I liked that sort of thing it'd probably be one of my first choices.

Re: Four days of Go

#97

Post by wwweston »

nemothekid wrote: post #83
adrusi wrote: post #66

Earlier quoted context omitted.

In before "but adding generics does not make team projects harder, look at language ..." Your (and many other people's) insistence on dismissing discussion regarding generics as some kind of a joke is anti-intellectual. You're rejecting valid criticism of your arguments on the basis that the critic's argument is unworthy of attention for some reason external to the discussion at hand. I agree that pro-generics argume…

I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?

It's not just the "not now" approach. It's the rhetoric that often goes along with it. The author of this piece picks up on it when he talks about the "we've already thought about this and we're tired of talking about it" vibe, though I might characterize a lot of the discussion around generics from the Go community at large more specifically as "you think you want/need this, but trust us, you don't, and the inconveniences you think you're experiencing are just not that big a deal, particularly compared to the inconveniences you'll experience if we do add it."

And yes, if not having an HTTP server implementation in the stdlib seems like it makes your project difficult, that's a perfectly reasonable criticism of Rust.

(Though one I suspect will get resolved much more quickly and cleanly than issues like generics in Go.)

Re: Four days of Go

#98

Post by smegel »

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,…

"Opinionated" frameworks/tools/languages are becoming pretty common these says. I would say programmers are becoming quite fond of authors who just make some damned decisions.

Re: Four days of Go

#99

Post by nulltype »

wiremine wrote: post #27
donlzx wrote: post #15

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 cooper…

> To me, the core Go authors are more of engineers than artists I thought the same thing. They are like the anti-Larry Wall.

I guess that makes Go the inverse of Perl. I assume if a Perl programmer shakes hands with a Go programmer, they cancel each other out.

Re: Four days of Go

#100

Post by vowelless »

> Go is productive enough that I’ve been enjoying implementing things from scratch like collapsible widgets and navigating a viewport. In order to do evil things like convert raw bytes to floats, I chose to use the “unsafe” package, which made me feel manly, powerful, and highly supportive of private gun ownership.

This was really funny!

Post reply on HN