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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

81–90 of 271 posts

Re: The State of Go

#81

Post by kasey_junk »

Mithaldu wrote: post #74
kasey_junk wrote: post #63

Earlier quoted context omitted.

The simplest reason is if what I was contributing was done on my employers time and they have strict IP restrictions. It is much, much easier to vet a single changeset than it is to a) verify a whole repo history and b) coordinate around my public/private github identities.

I was hoping for more reasons, since the very first and simple one is usually the one that has the most and simplest workarounds. You could for example make a patch with git on your local machine and attach that to an issue.

And then I have to follow a completely different work flow and inconvenience the maintainers.

Re: The State of Go

#82

Post by hueving »

enneff wrote: post #79
hueving wrote: post #55

Earlier quoted context omitted.

It's essentially rewriting history. As a contributor it's nice to know a commit went in exactly as you wrote it, which is not the case when the commit hash changes. Git is powerful because it was written with the ability to merge trees. The cherry pick workflow is throwing all of that in the trash. Why not use SVN at that point? Because of cherry picking in Gerrit, dependent patches are a nightmare to maintain. Say p…

One nice thing about Git is it lets you choose your workflow. Our general workflow for the Go project is to review single commits, and sometimes do major new work in feature branches. When we submit a single change we cherry-pick. When we merge trees, we create a merge commit. We don't write commits that depend on other pending work. That's overly complicated (IMO) even if you always use merge commits.

It's not complicated at all if you use merge commits. That's exactly what you are doing with a feature branch. Failing to realize merge commits are useful is what makes them complicated.

Re: The State of Go

#83

Post by falcolas »

SBullet01 wrote: post #32
georgemcbay wrote: post #19

Earlier quoted context omitted.

Yeah, what an outrage this is. 1.3 megabytes. That's like $0.00004 USD worth of hard drive space. Does the go team think we are all rich or something?

I think the point he tried to make was that if only "hello world" produces a 1.3 megabytes executable, the file size of a fairly complicated program made in Go will be significantly larger than the same program implemented in another language.

You're right - it will be significantly larger. But then again, it doesn't depend on your system having all of the necessary libraries of the correct version and the overhead of dynamic linking.

It's a tradeoff, and worth it in my opinion.

Re: The State of Go

#84

Post by hammerandtongs »

noir_lord wrote: post #46
enneff wrote: post #33

Earlier quoted context omitted.

This makes me laugh, considering at Google we regularly deploy statically linked C++ programs that are two orders of magnitude larger. "You call that a big binary? THIS..." etc

I was generating 7-15Mb binaries out of Delphi in the late 90's (it had a similar kitchen sink approach) and it simply wasn't an issue then and it certainly isn't an issue now. I'm actually racking my brain for a case where a 500kb vs 5Mb binary would be a deal breaker, outside of embedded stuff I can't think of much.

Just as a minor point -

One of the major blockers to clojure in android is that the lack of treeshaking/deadcode elimination makes for 10 second+ startup times in most environments.

Re: The State of Go

#85

Post by kryptiskt »

ori_b wrote: post #61
perturbation wrote: post #58

Earlier quoted context omitted.

Doesn't Go have the potential to be faster than Java since it's compiled to native code (rather than compiled to byte code)?

Java is also compiled to native code, but only after it runs for a bit.

Android does AOT compiling with ART, it became the default in Lollipop.

Re: The State of Go

#86

Post by wereHamster »

justinmk wrote: post #47
wereHamster wrote: post #15

> In general, pull request culture is not about code review. This is not true. There are many projects on GitHub which do extensive code reviews on pull requests. It may not be as nice as Gerrit for the type of project like Go (where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient (and arguably more efficient than Gerrit).

> where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non-trivial reviews. Biggest WTFs: - No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments. - Source "annotations" are lost…

> GitHub is painful for non-trivial reviews.

That may very well be the case. But note how you said for non-tivial reviews, whereas in the presentation about go they said in general (see the line I quoted in my original comment). And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. I don't have any hard numbers to back up my claim.

Re: The State of Go

#87

Post by vardump »

perturbation wrote: post #58
eternalban wrote: post #28

Earlier quoted context omitted.

You jest? Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.

Doesn't Go have the potential to be faster than Java since it's compiled to native code (rather than compiled to byte code)?

JIT has potential to be faster than compiled native code. Better runtime information. Compiled code needs to cover all potential options and this means more instructions to execute.

Say a variable value is set through a command line option to be a certain value. Compiled native code has to assume the value to be dynamic, but a JIT can optimize it away, effectively hardcoding it for that particular invocation. Same applies to more complicated type of software. Some configuration and invocation parameters tend to be effectively static during that particular invocation. JITs can capitalize on this fact.

JITs have also better chance to adapt to exact hardware it's running on. Compiled code is forced to make one or a limited number of assumptions of available CPU hardware configuration.

In the end, both options are running compiled native code. JIT just does it a bit before running.

Of course current reality is the opposite, but the key word here is potential.

Re: The State of Go

#88

Post by boulos »

inglor wrote: post #40

This presentation looks horrible on the iPhone screen. I wonder if they couldn't spend a few minutes to point phone users to a working version or at least not lock the viewport size so mobile users could pinch-zoom out.

Each slide was okay when viewed horizontally, but then advancing then shows the damn address bar. I had to annoyingly advance, rotate, rotate back, and then read. After a while I just gave up on the titles...

Re: The State of Go

#89

Post by enneff »

wereHamster wrote: post #86
justinmk wrote: post #47

Earlier quoted context omitted.

> where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non-trivial reviews. Biggest WTFs: - No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments. - Source "annotations" are lost…

> GitHub is painful for non-trivial reviews. That may very well be the case. But note how you said for non-tivial reviews , whereas in the presentation about go they said in general (see the line I quoted in my original comment). And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. I don't have any hard numbers to ba…

> And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine.

Right. And what you say validates my exact point: "pull request culture is not about code review." If all you want to do is cast your eye over it and click "merge", it works great. That's not how we work, though.

Re: The State of Go

#90

Post by bdarnell »

Mithaldu wrote: post #41

Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…

>> Comments are sent as they are written; you cannot "draft" comments. > How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.)

With github PRs, notifications are sent as soon as you write your first comment; in systems like gerrit and rietveld (and email) they are not sent until the reviewer chooses to send them. This leads to either awkward interactions if you start replying to comments while the reviewer is still reviewing, or unresponsiveness if everyone introduces hysteresis to avoid this situation.

This is IMHO the biggest problem with Github PRs; I don't necessarily agree with the Go team's decision to abandon the PR system but on smaller projects I have pushed for rietveld over PRs for this reason.

Post reply on HN