Four days of Go
evanmiller.org
Four days of Go
1–10 of 187 posts
Re: Four days of Go
#2In 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, that is, the “bad” programmers.
I think this is why some people dislike Go. The Go authors have made a decision about the language and are sticking to it. 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.
Re: Four days of Go
#3In 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 importing a library, say from Github. Interesting that the language from the author is all about how rigid and unforgiving Go is, yet "some guys" libraries can just be thrown into the mix in your program, and Go has no issues with this.
Re: Four days of Go
#4In 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,…
> faith
Or arrogance and incompetence. It's been said many times. Go team should spend at least one day with Gilad Bracha...
Re: Four days of Go
#5In 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 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)" are a breath of fresh air. Having dealt with team members that barely know how to program and think a compiler spitting out an executable means it's ready (what warnings? why do those matter, it compiled), Go makes coordinating with them a lot easier. It forces them to be more correct before an executable is created. It doesn't make them better, but at least the rest of the team can work with what they create until they do get better.
Also, the simplicity of the language sure helps everybody (regardless of skill) get up to speed quickly. People that know what they're doing may hate there isn't some special feature they love (generics, etc) in the language, but working with a team of varied skill is so much easier this way.
In before "but adding generics does not make team projects harder, look at language ..."
Re: Four days of Go
#6That 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.
Re: Four days of Go
#7In 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,…
"we programmers like to discuss everything" -- I enjoy being free from discussing the language, to discuss the context.
Re: Four days of Go
#8no ternary is a smart move tho. makes code more readable for all skill levels.
Re: Four days of Go
#9California New Wave of systems programming languages
Love it!
Re: Four days of Go
#10That 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.
Also he is spot on about the mascot.