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

51–60 of 79 posts

Re: Golang Diaries I

#51

Post by zzzcpan »

scott_s wrote: post #49
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.

Take a look at this adaptation of a keynote talk on the design of Go, with the title "Language Design in the Service of Software Engineering": http://talks.golang.org/2012/splash.article Section 7, "Dependencies in Go" addresses this issue: http://talks.golang.org/2012/splash.article#TOC_7 . The relevant paragraph states, The first step to making Go scale, dependency-wise, is that the language defines that unused dep…

Compiler can ignore unused dependencies and variables, since it detects them anyway and still guarantee that no extra code will be compiled when building the program, which minimizes compilation time. So the argument itself is flawed and only gives a perception of rational decision, while not actually being rational.

Re: Golang Diaries I

#52

Post by Roboprog »

msie wrote: post #31
wrl wrote: post #5

"Nice C-flavored code (there’s even ++) but look, Ma, no semicolons!" The hate for semicolons is far, far more annoying to me than semicolons ever are.

Yes, it's weird how some people deny their existence in Javascript!

That's because Javascript is a line oriented language like Ruby! :-)

Use semicolons like you would use colons in BASIC: to stack multiple statements on a line.

The C programming language is not the be-all & end-all template for programming languages.

Re: Golang Diaries I

#53

Post by Roboprog »

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

Re: Golang Diaries I

#54

Post by coldtea »

laumars wrote: post #34
coldtea wrote: post #20

Earlier quoted context omitted.

> Maybe Google is tailoring your results to bring back sites that include the programming language based on a) your past searching habits and b) the emerging trends for those specific search patterns. Google's results are highly tailored Well, tried the same thing logged out from Google, in incognito mode and with cookies turned off. Same results. I can also try to proxy my search to a remote VPS I never use and see…

> 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's that for contradiction?

People argued above that I was getting them because I was in a "filter bubble" for having searched for the language a lot in the past.

Suddenly the problem is that I haven't "spent a few months learning the language and thus making frequent searches online [like yourself]"?

What for? To appreciate the subtle nuances and variable results of using go vs golang?

Not to mention, I never said golang didn't work best (which you somehow assumed I did). Just that "go +stuff" worked well too.

>which are based upon flawed experiments (as already discussed)

Nothing of the short was shown. What was the "flawed experiment" and in what way?

Surely not that I was in a "filter bubble", because now you argue for the inverse (that I didn't perform enough searches). If that was the case, then you should be in a filter bubble too, after all your "frequent searches", which wouldn't explain your results.

Plus, I did the same from totally different account with no cookies and got the same results (as I patiently explained).

Re: Golang Diaries I

#55

Post by scott_s »

zzzcpan wrote: post #51
scott_s wrote: post #49

Earlier quoted context omitted.

Take a look at this adaptation of a keynote talk on the design of Go, with the title "Language Design in the Service of Software Engineering": http://talks.golang.org/2012/splash.article Section 7, "Dependencies in Go" addresses this issue: http://talks.golang.org/2012/splash.article#TOC_7 . The relevant paragraph states, The first step to making Go scale, dependency-wise, is that the language defines that unused dep…

Compiler can ignore unused dependencies and variables, since it detects them anyway and still guarantee that no extra code will be compiled when building the program, which minimizes compilation time. So the argument itself is flawed and only gives a perception of rational decision, while not actually being rational.

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.

Re: Golang Diaries I

#56

Post by cynwoody »

voidlogic wrote: post #38

>The second big gripe is that Golang has neither an IDE nor a REPL. The IDE part is not true at all, why do people keep saying this? LiteIDE (aka golangide) works great, I use it all day everyday. It has syntax highlighting, autocomplete, gofmting, building, debugging, etc and is very lightweight. Downloads: https://code.google.com/p/golangide/downloads/list Source: https://github.com/visualfc/liteide As for the meri…

The main benefit of a true REPL over the Go playground is that a REPL allows you to interact with the state of a partially-run program. By contrast, the Go playground is one-shot. Your code runs quickly, but completely, and you see the result. But you can't examine the data structures interactively.

For instance, when debugging a simple Python utility, I will often put the steps it goes thru into individual functions and tie them together with a main() function normally called via "if __name__ == '__main__':main()".

That allows me to import the program as a module into a REPL session, from which I can call the functions individually and examine the resulting outputs. If something's not right, I can alt-tab to the editor, make a change, save the program, and use the reload() function in the REPL. Sometimes, the REPL-obtained data is all I'm looking for, and I never get around to running the code from the command line.

Re: Golang Diaries I

#57

Post by eikenberry »

zzzcpan wrote: post #35
scott_s wrote: post #32

Golang will not let you compile if there’s an import or declared variable that’s unused. I think that is the result of an explicit design goal of Go: optimizing for large projects that involve many files and packages developed by many people. Having extraneous package or variable declarations in parts of a program are not an issue for small, one-off exploratory programs, but can be for large projects. So they're cons…

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.

https://github.com/elazarl/gosloppy

Re: Golang Diaries I

#58

Post by voidlogic »

cynwoody wrote: post #56
voidlogic wrote: post #38

>The second big gripe is that Golang has neither an IDE nor a REPL. The IDE part is not true at all, why do people keep saying this? LiteIDE (aka golangide) works great, I use it all day everyday. It has syntax highlighting, autocomplete, gofmting, building, debugging, etc and is very lightweight. Downloads: https://code.google.com/p/golangide/downloads/list Source: https://github.com/visualfc/liteide As for the meri…

The main benefit of a true REPL over the Go playground is that a REPL allows you to interact with the state of a partially-run program. By contrast, the Go playground is one-shot. Your code runs quickly, but completely, and you see the result. But you can't examine the data structures interactively. For instance, when debugging a simple Python utility, I will often put the steps it goes thru into individual functions…

OK, in a compiled language like Go a REPL implementation looks hard- am I wrong? It seems like besides the code being R/O a debugger is pretty close too.

When testing with a debugger I setup my program to run the same tests, read the same input etc. In this way I can use the debugger, find and issue, change the code, set a break point, re-run the program and I'm right back where I left off. This sounds functionally similar to using a REPL.

Re: Golang Diaries I

#59

Post by [deleted] »

zzzcpan wrote: post #51
scott_s wrote: post #49

Earlier quoted context omitted.

Take a look at this adaptation of a keynote talk on the design of Go, with the title "Language Design in the Service of Software Engineering": http://talks.golang.org/2012/splash.article Section 7, "Dependencies in Go" addresses this issue: http://talks.golang.org/2012/splash.article#TOC_7 . The relevant paragraph states, The first step to making Go scale, dependency-wise, is that the language defines that unused dep…

Compiler can ignore unused dependencies and variables, since it detects them anyway and still guarantee that no extra code will be compiled when building the program, which minimizes compilation time. So the argument itself is flawed and only gives a perception of rational decision, while not actually being rational.

[deleted]

Re: Golang Diaries I

#60

Post by zzzcpan »

scott_s wrote: post #55
zzzcpan wrote: post #51

Earlier quoted context omitted.

Compiler can ignore unused dependencies and variables, since it detects them anyway and still guarantee that no extra code will be compiled when building the program, which minimizes compilation time. So the argument itself is flawed and only gives a perception of rational decision, while not actually being rational.

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 packages already did.

Anyway, it's just a technical problem with a few simple solutions.

Post reply on HN