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

121–130 of 187 posts

Re: Four days of Go

#121

Post by howeyc »

adrusi wrote: post #66
howeyc wrote: post #5

Earlier quoted context omitted.

I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)"…

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…

That comment was there because my point was not about generics, but about programming language features (that are must have, the must have list of course being different for everyone) in general.

Re: Four days of Go

#122

Post by rickhanlonii »

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

The best example of this for me is the initialism style rule:

> Words in names that are initialisms or acronyms (e.g. "URL" or "NATO") have a consistent case. For example, "URL" should appear as "URL" or "url" (as in "urlPony", or "URLPony"), never as "Url". Here's an example: ServeHTTP not ServeHttp.

> This rule also applies to "ID" when it is short for "identifier," so write "appID" instead of "appId".

> Code generated by the protocol buffer compiler is exempt from this rule. Human-written code is held to a higher standard than machine-written code.

To enforce this in the linter they literally define a list of initialisms[1].

[1]: https://github.com/golang/go/wiki/CodeReviewComments#initial... [2]: https://github.com/golang/lint/blob/master/lint.go#L695

Re: Four days of Go

#123

Post by polymathist »

I am worried that there might be a dangerous trend in conversations about go on HN recently. There seems to be a tendency toward ad hominem comments against the go authors.

The article itself is a great read. I love hearing interesting and honest commentary about the language. But I wonder if comments like "for reasons that appear to be political, does not have integer Min and integer Max functions" are appropriate. Later the author mentions "I get a similar sense of refusal-to-engage — the authors are communicative, to be sure, but in a didactic way." If the go community (or the programming community at large) truly has the sense that the go authors are unwilling to engage with the users of the language, then that's a big problem. However, are these sort of off the cuff comments the right way to start a discussion about it? At the very least, I wish that the author would provide specific evidence for these claims. I'm sure that there is some justification for them, but what the author is telling us is his inference, and I would appreciate an opportunity to read the source material and decide for myself. FWIW I have been programming in go for 2.5 years and made a few trips to the go-nuts mailing list. I don't share the author's impression, but I also haven't read every thread on the mailing list.

That's far from the worst of it, of course. I have read comments calling the go authors arrogant, ignorant, or conceited. If you insist on criticizing the go authors, I would hope that you could at least keep it professional and provide a link to some comment/literature to back up your criticism.

I welcome criticism of go, or of any topic for that matter. I just want to avoid unfair characterization and irrelevant ad hominem comments. Am I being too defensive or do other people share this concern?

Re: Four days of Go

#124

Post by EugeneOZ »

steveklabnik wrote: post #109
wwweston wrote: post #97

Earlier quoted context omitted.

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

> I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the sta…

no. there is a HUGE difference between std lib and third-party libs. Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. And as http is a very important thing for web-programs, it's much better to see support of http in std lib.

Re: Four days of Go

#125

Post by EugeneOZ »

heinrich5991 wrote: post #111
ori_b wrote: post #90

Earlier quoted context omitted.

Go not including generics is a deliberate act.

A web server can easily be implemented as a library, generics are a language feature.

And library can be easily abandoned or just be broken after breaking changes in next version of language, and you will have to wait couple of months, while this issue will be solved. Or just fix all the things yourself.

Re: Four days of Go

#126

Post by PopsiclePete »

jkyle wrote: post #45
howeyc wrote: post #5

Earlier quoted context omitted.

I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)"…

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

>These are typically areas in a project where Parkinson's Law of Triviality rears its ugly head in project planning meetings. Everyone feels the need to bloviate about 2 vs 4 indents, tabs vs spaces, or which lint flags to enable/disable.

It was in one of the numerous Go talks/videos/presentations where I think it was Ken Thompson who said that he could walk around the Google cafeteria and hear Python programmers arguing all day long of how white space should work, and in Go, those discussions just don't happen. It's done. It's been decided. Move on.

It really struck a chord with me. It's amazing how smart people, given enough free time, will argue non-stop about the most irrelevant, insane things and stop themselves from being productive.

Re: Four days of Go

#127

Post by PopsiclePete »

adrusi wrote: post #66
howeyc wrote: post #5

Earlier quoted context omitted.

I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)"…

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…

Various core Go team members seem to have a different philosophy regarding generics. They actually don't have a united front on this.

It seems Russ Cox and Rob Pike are either anti-generics or in the you-dont-really-need-them camp, but Ian Thompson and Brad Fitzpatrick have seemed very open to the idea - what they can't, however, agree on, is exactly how to implement them so that they make sense in Go. That's it.

If you or anyone out there manages to produce a proposal of how they should work/look like and even a fork of Go implementing the idea, it will be taken seriously, at least by some core Go members.

I have a feeling that generics are coming. And I have a feeling they'll be very Go-like - an external tool with code generation, not special syntax. Just my 2 cents.

Re: Four days of Go

#128

Post by heinrich5991 »

EugeneOZ wrote: post #125
heinrich5991 wrote: post #111

Earlier quoted context omitted.

A web server can easily be implemented as a library, generics are a language feature.

And library can be easily abandoned or just be broken after breaking changes in next version of language, and you will have to wait couple of months, while this issue will be solved. Or just fix all the things yourself.

Just fixing the language is not possible without major problems though.

Re: Four days of Go

#129

Post by steveklabnik »

EugeneOZ wrote: post #124
steveklabnik wrote: post #109

Earlier quoted context omitted.

> I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the sta…

no. there is a HUGE difference between std lib and third-party libs. Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. And as http is a very important thing for web-programs, it's much better to see support of http in std lib.

Right. That's the kind of thing I meant with "Choosing non-minimalism has advantages too."

Re: Four days of Go

#130

Post by commentzorro »

PopsiclePete wrote: post #126
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…

>These are typically areas in a project where Parkinson's Law of Triviality rears its ugly head in project planning meetings. Everyone feels the need to bloviate about 2 vs 4 indents, tabs vs spaces, or which lint flags to enable/disable. It was in one of the numerous Go talks/videos/presentations where I think it was Ken Thompson who said that he could walk around the Google cafeteria and hear Python programmers arg…

> stop themselves from being productive.

I disagree with you here. First, just because people are arguing about irrelevant insane things doesn't necessarily mean they're not productive. Second, I love those trivial arguments because at the end of "lunch" I've taken a break from the more involved thought, floated up to lighter stuff for a while, had some fun, and can now easily get back to the tasks at hand.

Post reply on HN