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

41–50 of 187 posts

Re: Four days of Go

#41

Post by zerr »

laumars wrote: post #35
zerr wrote: post #4

Earlier quoted context omitted.

> faith Or arrogance and incompetence. It's been said many times. Go team should spend at least one day with Gilad Bracha...

I find it amusing that people would use the term "incompetence" to describe Ken Thompson and Rob Pike. These two guys have been as instrumental in shaping modern computing as Linus Torvalds, Bill Gates and Steve Jobs. But I guess it's easy to be critical of other peoples output when you're an anonymous internet user yourself.

Sorry, I thought it was clear - incompetence regarding [modern] language design. They don't deny this neither. And it seems they're even proud of this.

> when you're an anonymous internet user

It is easy to be honest, yes.

Re: Four days of Go

#43

Post by garfij »

tormeh wrote: post #33
jerf wrote: post #30

Earlier quoted context omitted.

Go's goto is the standard structured-programming-limited goto which is not allowed to violate blocks, which means it is not the goto that is "considered harmful". Go's "pointers" are not allowed to do pointer arithmetic, which basically means that they are references. As they are also backed by a garbage collector, this means you can't do any of the nasty C things you can do with them, not even "fail to deallocate" t…

Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code. You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.

Goto's can create unreadable code. It's not a unavoidable fact that they have to create unreadable code.

Anything can create unreadable code, but mostly it's bad programmers writing unreadable code, not the syntax they use.

Re: Four days of Go

#44

Post by jerf »

tormeh wrote: post #33
jerf wrote: post #30

Earlier quoted context omitted.

Go's goto is the standard structured-programming-limited goto which is not allowed to violate blocks, which means it is not the goto that is "considered harmful". Go's "pointers" are not allowed to do pointer arithmetic, which basically means that they are references. As they are also backed by a garbage collector, this means you can't do any of the nasty C things you can do with them, not even "fail to deallocate" t…

Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code. You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.

No, gotos are present to allow you to use programming paradigms other than structured programming, isolated within the confines of a structure-programming function. The most popular such alternative paradigm that can be written by a human being a finite-state machine, which can be quite clearly and efficiently expressed via goto. Generated code can also get a lot of mileage out of goto, and this is usually code you're not going to be touching anyhow if you've gone so far as to generate it.

This paralyzing fear of goto is really out of date. I work on a Perl code base with dozens of other programmers of varying levels of skill across man-centuries of programming the vast bulk of which has basically had no code review. I've seen enormous quantities of bad code and had a hand in cleaning up a lot of it. I've seen confusing object hierarchies, bunches of confusing functions calling each other with essentially untyped parameters, all of them "fixing up" each other's parameters (mostly "correctly"...), functions a mile long with nothing but the occasional incorrect comment, reams of dead code kept around "just in case", and a huge variety of other bad code practices. And you know what I have literally not seen once? An abuse of goto. Nor do I see it in the open source I crack open, nor anything else I read.

Even if someone pops up and claims they see goto abuse "all the time", I'd challenge them to go find the source for them, and I bet they find it was just one person doing all of them in their code base. People do not abuse goto anymore, because if anything, they've been beaten so thoroughly into compliance with "goto is bad!" that the problem they have with it is not using it when they should. I don't fear that putting goto into a language will suddenly produce tons of code where entire programs are just one big function with tons of gotos in it, because I observe that it doesn't happen, and observation of facts trumps any theory about how the facts "could" be something else, because the facts are the facts.

As for passing pointers, yes, it can be dangerous. So far I've had no trouble with it because I'm always also passing ownership, but you do have to know what you are doing. I used to pine for Rust's feature set, but then, I observe that it turns Go into a completely different language, so now I prefer a world in which they are both available.

Re: Four days of Go

#45

Post by jkyle »

howeyc wrote: post #5
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 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 planning meetings. Everyone feels the need to bloviate about 2 vs 4 indents, tabs vs spaces, or which lint flags to enable/disable.

Hell, with go get always grabbing the master branch, it even implicitly requires projects to keep their master branch 'green' so it doesn't break projects that depend on it. A very neat way to eliminate a whole set of "Which branching model should we use?" arguments.

Re: Four days of Go

#46

Post by dilap »

Fantastic article.

Two tips about the pain points regarding unused imports and variables:

The program goimports is an extended version of gofmt that will automatically add and remove imports. Bind it to a keystroke of your editor of choice, and the imports situation becomes painless.

For unused variables, you can do "_ = someVar" to stop it from being flagged as unused. Still a bit of a pain, but much easier than commenting and uncommenting things all the time.

Re: Four days of Go

#47

Post by laumars »

tormeh wrote: post #33
jerf wrote: post #30

Earlier quoted context omitted.

Go's goto is the standard structured-programming-limited goto which is not allowed to violate blocks, which means it is not the goto that is "considered harmful". Go's "pointers" are not allowed to do pointer arithmetic, which basically means that they are references. As they are also backed by a garbage collector, this means you can't do any of the nasty C things you can do with them, not even "fail to deallocate" t…

Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code. You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.

> Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code.

Goto's are seldom used by bad programmers anyway - most of them wouldn't even be aware of them. They generally exist in languages as a niche feature used be experienced developers for those rare situations where a goto results in cleaner code. You definitely don't see Go developers sprawling goto's everywhere just because it exists.

> You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.

Erm, sorry. You've lost me now. I'll grant you that pointers require a little extra mental overhead, but they're most definitely necessary when you're writing code that either needs to be sensitive to memory usage, or performance.

As for pointers "encouraging bad code", I'm not even going to dignify that remark with a proper response.

Re: Four days of Go

#48

Post by Arzh »

aikah wrote: post #32
mike_hearn wrote: post #13

Earlier quoted context omitted.

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

> Given this background and the Go designers focus on Google's internal needs Does it mean the community isn't a priority? this vertical relationship between the Go team and the community could doom the language as fast as it was made popular, that's my opinion.That's a real issue.

That has always been the point of go. A better way of writing code the 'Google Way' It is really useful outside of that (I use it for everything other then video games), but it was always a language to help them get their work done faster.

Re: Four days of Go

#49

Post by garfij »

Ever since I started immediately creating at least one "test" file in my Go projects, I have found that both the unused variable/imports problem, as well as the "freedom to explore" issue have been eliminated for me.

Sure, they will still bite me in that individual test file if the situation arises. It keeps the problem out of the "real" code, however so I don't get it when building. In this way I get to maintain a creative space to test out various apis and do my "print to console" testing, while also keeping my primary code base Go-Clean™.

Re: Four days of Go

#50

Post by loopbit »

dysoco wrote: post #37

I must said, I've never heard of this guy, I think I have a new favorite blogger now.

He has a few very, very interesting articles. I would point out the following two:

- How not to sort by average ranking (http://www.evanmiller.org/how-not-to-sort-by-average-rating....) is a recommended read on coursera's recommender systems course.

- Rank Hotness With Newton's Law of Cooling (http://www.evanmiller.org/rank-hotness-with-newtons-law-of-c...)

Post reply on HN