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

71–79 of 79 posts

Re: Golang Diaries I

#71

Post by ridiculous_fish »

jff wrote: post #42
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.

People ignore warnings. Want proof? Go grab damn near any open source project and compile it. It's almost guaranteed that the default compile options, chosen by the authors, will generate dozens if not hundreds of warnings. Everyone's so very noble at the start of a project, "We shall turn on all warnings, and then fix them!", but really once the program compiles and seems to run properly, all that goes out the windo…

This is largely due to compiler version differences. I can fix every warning my compiler emits, and you are likely to still get warnings on yours.

Go's enforced -Werror can work in a smallish community, where there's a single compiler and a culture of everyone always using its latest version. But I don't see how it can survive an environment where there's multiple compilers, each with multiple versions. Who here could write a C program that is guaranteed to never produce a warning on any C compiler?

Re: Golang Diaries I

#72

Post by scott_s »

zzzcpan wrote: post #66
scott_s wrote: post #65

Earlier quoted context omitted.

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

I know what parsing and walking a tree is. And parsing is walking a tree. It requires going over the entire source, which is my point: they're trying to avoid processing unnecessary code.

You do not need to do code genration to establish what the unused packages are. But you must parse and perform semantic analysis of the entire package to determine what the unused packages are. There is more to "compiling" than code genration and optimization.

Parsing is what they want to avoid, not just code generation. Parsing is cheap for small projects. But nothing is cheap at scale. From the talk I have already linked to:

The construction of a single C++ binary at Google can open and read hundreds of individual header files tens of thousands of times. In 2007, build engineers at Google instrumented the compilation of a major Google binary. The file contained about two thousand files that, if simply concatenated together, totaled 4.2 megabytes. By the time the #includes had been expanded, over 8 gigabytes were being delivered to the input of the compiler, a blow-up of 2000 bytes for every C++ source byte.

As another data point, in 2003 Google's build system was moved from a single Makefile to a per-directory design with better-managed, more explicit dependencies. A typical binary shrank about 40% in file size, just from having more accurate dependencies recorded. Even so, the properties of C++ (or C for that matter) make it impractical to verify those dependencies automatically, and today we still do not have an accurate understanding of the dependency requirements of large Google C++ binaries.

If Go allowed including unused packages, you would end up with the exact same problem.

Re: Golang Diaries I

#73

Post by zzzcpan »

scott_s wrote: post #72
zzzcpan wrote: post #66

Earlier quoted context omitted.

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

I know what parsing and walking a tree is. And parsing is walking a tree. It requires going over the entire source, which is my point: they're trying to avoid processing unnecessary code. You do not need to do code genration to establish what the unused packages are. But you must parse and perform semantic analysis of the entire package to determine what the unused packages are. There is more to "compiling" than code…

I don't think you get it. You cannot end up with the same problem if you ignore unused dependencies and prevent circular ones, it's just not possible.

Re: Golang Diaries I

#74

Post by coldtea »

laumars wrote: post #70
coldtea wrote: post #67

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

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

"Enough with this old wives tale" was rude?

And yet you used: "people like yourself", "trolls and egos", "lazy negative posts", "you've ignored everyone else that's replied to you", "you're not even interested in this subject anyway", "people who actually know what they're talking about on this matter",

against my very simple statementthat his queries also work with "go" -- and it's not due to some "filter bubble".

Well, FUCK YOU, your insults and your condescending tone.

As for your points:

(a) "not all users get the same results" -- I replied to this, testing the "personalised bubble" effect. What else exactly do you think is in play? Divine intervention?

(b) "popular results for similar search patterns will be biased in everyones results" -- irrelevant, since I used the very terms Tim Bray tried. Why weren't they "biased" in HIS results? Isn't he a member of "everyone"?

(c) "not everyone uses Google." -- almost everybody does, and Tim for his examples used (and even works at) Google. Irrelevant again.

Re: Golang Diaries I

#75

Post by Roboprog »

claystu wrote: post #62
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.

Don't forget that one of the creators went to University of Zurich. (did he study with Wirth???)

Re: Golang Diaries I

#76

Post by scott_s »

zzzcpan wrote: post #73
scott_s wrote: post #72

Earlier quoted context omitted.

I know what parsing and walking a tree is. And parsing is walking a tree. It requires going over the entire source, which is my point: they're trying to avoid processing unnecessary code. You do not need to do code genration to establish what the unused packages are. But you must parse and perform semantic analysis of the entire package to determine what the unused packages are. There is more to "compiling" than code…

I don't think you get it. You cannot end up with the same problem if you ignore unused dependencies and prevent circular ones, it's just not possible.

That's my entire point: you can't ignore unused dependencies. I've explained at length why this is the case - the Go designers have also explained this. Simply, you must look at imported packages before you look at this package. You can only establish that a package is unused in this package after looking at all code in this package. Hence, you only can only recognize that a package is unused after you have looked at it.

Yes, you can avoid generating code for that package. But the designers of Go want to avoid looking at the package at all. They have collected data from inside Google which clearly establishes that this is a problem.

Re: Golang Diaries I

#77

Post by laumars »

coldtea wrote: post #74
laumars wrote: post #70

Earlier quoted context omitted.

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

> 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. "Enough with this old wives tale" was rude? And yet you used: "people like yourself", "trolls and egos", "lazy negative posts", "you've ignored everyone else that's replied to you", "you're not even interested in this subject anyway", "people who actually…

> "Enough with this old wives tale" was rude? And yet you used: "people like yourself", "trolls and egos", "lazy negative posts", "you've ignored everyone else that's replied to you", "you're not even interested in this subject anyway", "people who actually know what they're talking about on this matter",

You're selectively sampling data there. Those comments of mine are from later on in this debate - where you've been equally condescending. At the start I was polite.

> a) "not all users get the same results" -- I replied to this, testing the "personalised bubble" effect. What else exactly do you think is in play? Divine intervention?

Indeed you did. Albeit just the once. More tests would be required if you truly cared about disproving the bubble effect as your results could easily have fallen into the (b) point I raised.

> b) "popular results for similar search patterns will be biased in everyones results" -- irrelevant, since I used the very terms Tim Bray tried. Why weren't they "biased" in HIS results? Isn't he a member of "everyone"?

[sigh] Because they might not have been popular when he searched for them. His blog might have caused others to Google those terms and thus skew the results (in fact it definitely has caused others to Google his search terms as we're here arguing about it now). This is why I posted examples of other search terms, which you clearly haven't looked at yet. If you're not going to look at my examples, then why don't you try a few more irregular searches of your own.

In this whole argument you've basically taken one example as proof that your argument works every time. You've not even attempted other irregular search patterns of your own (or perhaps you have but they proved my point so you opted to ignore them as well?) so I really don't know how you can be so confident when you assert your point so absolutely. You do realise that multiple experiments need to be performed if you want to prove a statistical average? Just as myself and all the other Go developers have done with our time spent troubleshooting code.

> c) "not everyone uses Google." -- almost everybody does, and Tim for his examples used (and even works at) Google. Irrelevant again.

Of course it's relevant. You're arguing that "Go" is good enough on it's own - Google searches are just an example. If your point was valid then your results would be similar in other search engines. Later confining your point to one search engine seems a little like moving the goal posts mid-match.

Re: Golang Diaries I

#78

Post by zzzcpan »

scott_s wrote: post #76
zzzcpan wrote: post #73

Earlier quoted context omitted.

I don't think you get it. You cannot end up with the same problem if you ignore unused dependencies and prevent circular ones, it's just not possible.

That's my entire point: you can't ignore unused dependencies. I've explained at length why this is the case - the Go designers have also explained this. Simply, you must look at imported packages before you look at this package. You can only establish that a package is unused in this package after looking at all code in this package. Hence, you only can only recognize that a package is unused after you have looked at…

You and Go designers are misleading people by claiming false statements.

You don't have to look into the package to ignore it, I even explained to you how exactly to do it, but you keep repeating this bullshit. You have to look into the package and therefore parse it in one case only: when this package is imported into current namespace, which is almost never the case in Go. You can detect and ignore unused package with looking no farther than current package almost all the time, because each imported package uses unique namespace. If there were no symbols present with that namespace in current package - you don't have to look into the package with that namespace, it's that simple. And gc (Go's compiler) already detects unused packages in similar way.

Re: Golang Diaries I

#79

Post by scott_s »

zzzcpan wrote: post #78
scott_s wrote: post #76

Earlier quoted context omitted.

That's my entire point: you can't ignore unused dependencies. I've explained at length why this is the case - the Go designers have also explained this. Simply, you must look at imported packages before you look at this package. You can only establish that a package is unused in this package after looking at all code in this package. Hence, you only can only recognize that a package is unused after you have looked at…

You and Go designers are misleading people by claiming false statements. You don't have to look into the package to ignore it, I even explained to you how exactly to do it, but you keep repeating this bullshit. You have to look into the package and therefore parse it in one case only: when this package is imported into current namespace, which is almost never the case in Go. You can detect and ignore unused package w…

And as I explained already, that complicates, and probably lengthens, the parsing and semantic analysis. (Instead of establishing the contents of a package before processing the current package, you have to track what symbols this packages has used from other packages, and then verify they are used correctly, or exist at all.) Which goes against their design goal.
Post reply on HN