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

Golang Diaries I

tbray.org

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Golang Diaries I

#61

Post by scott_s »

zzzcpan wrote: post #60
scott_s wrote: post #55

Earlier quoted context omitted.

The compiler cannot ignore an unused dependency. The compiler must first process the imported packages, then compile the current package. It only knows that an imported package was not used until after it has finished compiling the entire current package.

I don't know how Go compiler works, but I don't see a problem detecting unused dependencies very early just by walking an AST of current package, since in Go you have to specify package name explicitly in order to use something from it (well, not all the time, but almost all the time). And even this is probably unnecessary, you only have to process additional unused dependencies in your current package, other package…

Packages are processed before the current package is compiled. You can only establish that packages are unused after compiling the current package. So, you will still process unused packages. That is exactly the problem they want to avoid.

Your solution is, I think, to scan the current package twice: once to establish which packages are used, then process the packages, then actually compile the current package. But now you're scanning through each package twice, which will significantly add to compilation times, and make the compilation process more convoluted. Their solution is, I think, far simpler.

You're dismissing the problem, but I'm not sure you understand what the problem is.

Re: Golang Diaries I

#62

Post by claystu »

Roboprog wrote: post #53

I never worked with Algol, but I worked with Pascal years before C. The part of Go syntax that seems "bastardized" to me is trying to hide the language in C syntax, when clearly it seems more like Modula. Type blocks? Var blocks? Types-after-names? Makes sense to me (a former Turbo Pascal user) :-P

This is exactly what I think too.

I suspect the only reason they kept C's pointer token instead of using ^ is to maintain the fiction that this is really a 'C' family language rather than a derivative of Pascal and Modula.

Re: Golang Diaries I

#63

Post by laumars »

coldtea wrote: post #54
laumars wrote: post #34

Earlier quoted context omitted.

> Well, tried the same thing logged out from Google, in incognito mode and with cookies turned off. Same results. Now lets try it with a search phrase that hasn't been hammered to death: "go http listener" [1] https://www.google.co.uk/search?q=go+http+listener [2] https://www.google.co.uk/search?q=go+lang+http+listener In example 1, only 1 item on the 1st page is related to Golang. In example two, every result is rel…

> People like yourself and the OP can love to prove people wrong and argue that same popular searches work perfectly for you, but until you've spent a few months learning the language and thus making frequent searches online like myself and the author have, all you're doing is making pointless arguments Besides the BS ad hominem ("people like me", really?), you just reversed the whole argument against my results. How…

You're arguing the same points I'd already addressed in my previous post. You clearly haven't bothered to read my points nor look at the examples as they demonstrate exactly why "go +stuff" doesn't always work. So what's the point in me answering your questions again? You're clearly only going to ignore me, again. Just like how you've ignored everyone else that's replied to you.

> Besides the BS ad hominem ("people like me", really?), you just reversed the whole argument against my results. How's that for contradiction?

You're absolutely right. But I'm defending the author; and feel obliged to defend him because I'm sick and tired of reading lazy negative posts against authors who've taken the time to contribute back to the community. Particularly when a) the criticisms have very little relevance to the wider topic and b) the guys making the remarks aren't even experienced in the technologies they feel compelled to make authoritative judgements about.

This place used to be a safe haven from the trolls and egos of other communities, but these days if feels like the constructive and informative posts are outnumbered by the opinionated who have very content to contribute -and often, no interest in the subject either- but yet still feel compelled to comment.

And yes, I know I've swerved woefully off topic now. I'm certainly not trying to accuse you as being the worst that HN has to offer. I'm just frustrated that I've let myself get dragged into this dumb argument when I should have just broken my personal "down-voting rule" so that the healthier discussions in this thread could have risen to the top of the page.

Re: Golang Diaries I

#64

Post by zzzcpan »

scott_s wrote: post #61
zzzcpan wrote: post #60

Earlier quoted context omitted.

I don't know how Go compiler works, but I don't see a problem detecting unused dependencies very early just by walking an AST of current package, since in Go you have to specify package name explicitly in order to use something from it (well, not all the time, but almost all the time). And even this is probably unnecessary, you only have to process additional unused dependencies in your current package, other package…

Packages are processed before the current package is compiled. You can only establish that packages are unused after compiling the current package. So, you will still process unused packages. That is exactly the problem they want to avoid. Your solution is, I think, to scan the current package twice: once to establish which packages are used, then process the packages, then actually compile the current package. But n…

I just checked, they actually do it very early, similar to what I suggested, but instead of ignoring and producing warning they simply throw yyerror and they do that without even walking a tree, but during parsing. So I'm still correct. You can verify it by executing "go run .." multiple times with and without import error, you'll notice how fast it generates "imported but not used" error, compared to actual compilation.

And the whole point of their solution has absolutely nothing to do with unused imports and variables. They are just reusing object files without recompiling and they can't have circular dependencies to do that. There is nothing more to it.

Re: Golang Diaries I

#65

Post by scott_s »

zzzcpan wrote: post #64
scott_s wrote: post #61

Earlier quoted context omitted.

Packages are processed before the current package is compiled. You can only establish that packages are unused after compiling the current package. So, you will still process unused packages. That is exactly the problem they want to avoid. Your solution is, I think, to scan the current package twice: once to establish which packages are used, then process the packages, then actually compile the current package. But n…

I just checked, they actually do it very early, similar to what I suggested, but instead of ignoring and producing warning they simply throw yyerror and they do that without even walking a tree, but during parsing. So I'm still correct. You can verify it by executing "go run .." multiple times with and without import error, you'll notice how fast it generates "imported but not used" error, compared to actual compilat…

Based on your statements, I am not confident that you understand the compilation process and the terminology we use to describe it. In particular, I don't how you can say they don't "walk a tree," but do it "during parsing." Nor is timing the compiler sufficient to determine this kind of behavior.

In order to establish that a particular package was unused, they must: at least parse the header for that package, and parse the entirety of this package. Parsing the unnecessary package is the problem they want to avoid. Because that package could also have unnecessary packages, in large projects you could end up parsing more unnecessary packages than necessary packages.

This isn't even considering the building process, which is what actually produces the headers that get parsed for packages. So, if you import a package and it has not been built yet, it will build it. If that was an unnecessary package, then there's even more wasted time.

Re: Golang Diaries I

#66

Post by zzzcpan »

scott_s wrote: post #65
zzzcpan wrote: post #64

Earlier quoted context omitted.

I just checked, they actually do it very early, similar to what I suggested, but instead of ignoring and producing warning they simply throw yyerror and they do that without even walking a tree, but during parsing. So I'm still correct. You can verify it by executing "go run .." multiple times with and without import error, you'll notice how fast it generates "imported but not used" error, compared to actual compilat…

Based on your statements, I am not confident that you understand the compilation process and the terminology we use to describe it. In particular, I don't how you can say they don't "walk a tree," but do it "during parsing." Nor is timing the compiler sufficient to determine this kind of behavior. In order to establish that a particular package was unused, they must: at least parse the header for that package, and pa…

What can possibly be so confusing about parsing and walking a tree? Scanner (lexer) and parser are the very first stages of compilation. Parser produces syntax tree and some other stuff, like symbol table, there is no alternative terminology. Walking a tree cannot have multiple meanings either. Most of the work is done after parsing. And timing a compiler is sufficient to understand exactly that, since you claimed, that detection of unused dependencies required package to be compiled, which is of course total bullshit. For most unused packages even parsing is not required, you can look at symbols during parsing and set "used" flag for every package, that was used and only parse it if it has this flag set.

And parsing is not what they want to avoid. Parsing is cheap. They want to avoid full-blown compilation of unused packages.

Re: Golang Diaries I

#67

Post by coldtea »

laumars wrote: post #63
coldtea wrote: post #54

Earlier quoted context omitted.

> People like yourself and the OP can love to prove people wrong and argue that same popular searches work perfectly for you, but until you've spent a few months learning the language and thus making frequent searches online like myself and the author have, all you're doing is making pointless arguments Besides the BS ad hominem ("people like me", really?), you just reversed the whole argument against my results. How…

You're arguing the same points I'd already addressed in my previous post. You clearly haven't bothered to read my points nor look at the examples as they demonstrate exactly why "go +stuff" doesn't always work. So what's the point in me answering your questions again? You're clearly only going to ignore me, again. Just like how you've ignored everyone else that's replied to you. > Besides the BS ad hominem ("people l…

>You're arguing the same points I'd already addressed in my previous post. You clearly haven't bothered to read my points nor look at the examples as they demonstrate exactly why "go +stuff" doesn't always work.

If the "previous post" is the one I replied to, I not only read it thoroughly (and nowhere it addresses those points, you're welcome to correct me with citations), but also replied to it quoting you.

If the "previous posts" is something else up or down the thread, not addressed to me, then no, I haven't read it. Should I check and re-check everything in a thread?

Screenshots of what you got are not proof. I (and others) already said we got different results. So, it might not "always work", but it does work for some (contrary to what Tim says), and it's not due to a "filter bubble".

Heck, he WOULD be wrong EVEN if it was due to a "filter bubble", because then the lack of results would only be temporary, until Google learns his habits with regards to Go.

>But I'm defending the author; and feel obliged to defend him because I'm sick and tired of reading lazy negative posts against authors who've taken the time to contribute back to the community.

So you do it because you have an agenda, specifics be damned. I don't care if someone "took time to contribute back to the community" -- if there are points that need to be criticise they SHOULD be criticised. Not doing it would be a disservice to the community. Also, what he did as "contribution to the community" is just posted on his blog: not very different from what we do here, discussing in public.

>This place used to be a safe haven from the trolls and egos of other communities

Nowhere did I attacked the author. I responded to his claim and provided my contrary experience with similar searches. When confronted with the "filter bubble" explanation, I redid the experiment outside the "personalised search" effect.

You chose to come as a "defender of the author", attacking me, and talking about "trolls" and "egos". Maybe the problem lies with you?

Re: Golang Diaries I

#68

Post by [deleted] »

viscanti wrote: post #37
zzzcpan wrote: post #35

Earlier quoted context omitted.

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

What's the argument for allowing un-used imports? I've never run into a case where I wished I had imported something but didn't want to use it If you're looking at future code, you can accomplish that by commenting out the import. But I've never run into the situation where writing future code has been good, or where I wouldn't have remembered to import the package I needed when I wrote that code. If you really need…

[deleted]

Re: Golang Diaries I

#69

Post by ridiculous_fish »

viscanti wrote: post #37
zzzcpan wrote: post #35

Earlier quoted context omitted.

They can produce a warning on unused stuff, instead of an error and not force this idea on everyone, especially considering they have zero proof on this idea. Also, every large project starts from a small one.

What's the argument for allowing un-used imports? I've never run into a case where I wished I had imported something but didn't want to use it If you're looking at future code, you can accomplish that by commenting out the import. But I've never run into the situation where writing future code has been good, or where I wouldn't have remembered to import the package I needed when I wrote that code. If you really need…

Say you're trying to debug something, and you add a call to fmt.Printf. 'Compile error, "Undefined: fmt."' No problem, add 'import "fmt"' at the top.

Now it's debugged, so let's remove the annoying logging statement. Oops: 'Compile error: "imported and not used: fmt."' So now you remove the import, knowing full well you're going to be adding it back again in a minute or two. Annoying!

Or maybe, as part of debugging, you temporarily comment out a block of code. You just made a bunch of variables and imports unused, and you can't even test your changes until you clean them up.

Exploratory programming and debugging puts code in transiently dirty states, and Go's enforced hygiene is onerous in those cases.

Re: Golang Diaries I

#70

Post by laumars »

coldtea wrote: post #67
laumars wrote: post #63

Earlier quoted context omitted.

You're arguing the same points I'd already addressed in my previous post. You clearly haven't bothered to read my points nor look at the examples as they demonstrate exactly why "go +stuff" doesn't always work. So what's the point in me answering your questions again? You're clearly only going to ignore me, again. Just like how you've ignored everyone else that's replied to you. > Besides the BS ad hominem ("people l…

> You're arguing the same points I'd already addressed in my previous post. You clearly haven't bothered to read my points nor look at the examples as they demonstrate exactly why "go +stuff" doesn't always work. If the "previous post" is the one I replied to, I not only read it thoroughly (and nowhere it addresses those points, you're welcome to correct me with citations), but also replied to it quoting you. If the…

No I don't have an agenda. I happen to agree with the author. And I also happen to think your opening argument was rude, irrelevant and wrong - in equal measures. Maybe not intentionally rude, but unnecessary none the less.

What's more, neither Tim nor myself said that Go never works. Just that Go is a lousy search term and that "go lang" usually yeilds better results. My screenshots are evidence of that (and your reasoning for dismissing them is completely wrong because nobody else had commented on those examples. So don't give me that crap about "and others")

The issue here is that you've decided to post the typical easy reps via unrelated negative, and did so by overstating the authors point about the quality of Go as a search term. But then, sadly, you were too bloody stubborn to admit when you were wrong despite numerous developers (read: people who actually know what they're talking about on this matter) politely trying to demonstrate that a) not all users get the same results, b) popular results for similar search patterns will be biased in everyones results and c) not everyone uses Google.

But who cares about experience and expertise when people like you can voice an opinion after only 5 minutes of button bashing on thier keyboard. who cares about the fact that several go developers have all said that it's just easier to get into the habbit of using "go lang", after recieving disappointing results in the past. And who cares that Google themselves advice using golang for searches, because obviously Google are less of an authority on this subject than you clearly are.

Anyhow, we're never going to agree on this and you're not even interested in this subject anyway. So I suggest we quit while we're ahead.

Post reply on HN