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

91–100 of 271 posts

Re: The State of Go

#91

Post by hk__2 »

falcolas wrote: post #80
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…

Wait. Force pushes? That's a terrible habit to get into; force pushes have decimated more than a few a open source project's repository. https://news.ycombinator.com/item?id=6713742

What? Pull requests should be on their own branches, if you want to keep one commit per PR but need to edit it you must rebase it and thus force push. It’s a terrible habit if you’re sharing your branch with others, it’s completely normal if not.

Re: The State of Go

#92

Post by rmrfrmrf »

Mithaldu wrote: post #59
kasey_junk wrote: post #53

Earlier quoted context omitted.

> What exactly is weird about that? I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all but do want to contribute to a repo hosted there. This is a distributed version co…

Honest curiosity here. Given that there's nothing stopping you from deleting your fork after the PR is done, what reasons can you name for this: There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all

If PRs were a instantaneous thing, I don't think it would be a problem. However, if you've ever looked at a network graph of a repo that requires rigorous code review or doesn't have a diligent maintainer, some of those forks can sit in limbo for a really long time. And, as more pull requests pile up, it's very difficult as a user to figure out which version I should be using for my code to run correctly.

I just ran into this issue the other day when I was using Node with a lot of dependencies that still haven't been patched for issues that cropped up in OSX Yosemite.

Re: The State of Go

#93

Post by scrollaway »

falcolas wrote: post #75

Personal opinion here, but I much prefer merge commits as opposed to fast forwarded commits. With a merge commit, there's one commit to revoke if something breaks, and there's one commit per PR to step through with git bisect, and more importantly it maintains history, which to my eyes is more useful than a "pretty" repository. Drafting comments... if you want to draft comments, can't you do that in a separate editor…

> which to my eyes is more useful than a "pretty" repository.

A pretty history is extremely important when you need to attract new contributors to your repository. I've maintained extremely clean git logs and extremely nasty ones too. New contributors are immediately turned off in the latter case, because a good developer will generally git log extremely early when discovering a new project.

Re: The State of Go

#95

Post by scrollaway »

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.

It's hijacking Alt+Left/Alt+Right (back/forward in the browser) too. Nasty.

Re: The State of Go

#96

Post by eropple »

enneff wrote: post #37
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.

> if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land. I don't think that's necessarily true. Go does a much better job than Java at letting you manage your allocations and re-use memory. You can write tight, performance-critical code in Go without resorting to 'unsafe'; it just requires care, as it does in any language.

I don't believe that this is true. You use the exact same patterns and tricks in both for perf-critical code: off-GC primitives and object pools rule the day. What are you considering a "much better" option available in Go?

(I considered stack-allocated structs in Go, but honestly that doesn't strike me as a particularly major thing; it may be slightly more terse, but fundamentally the same behavior.)

Re: The State of Go

#97

Post by geofft »

falcolas wrote: post #75

Personal opinion here, but I much prefer merge commits as opposed to fast forwarded commits. With a merge commit, there's one commit to revoke if something breaks, and there's one commit per PR to step through with git bisect, and more importantly it maintains history, which to my eyes is more useful than a "pretty" repository. Drafting comments... if you want to draft comments, can't you do that in a separate editor…

This is actually one of the things I miss about SVN: in addition to a record of the commit being generated on a branch, there's a record of the commit being accepted onto trunk, and when and why.

Rust has an integration robot that does all the merges into master, that records who reviewed it, what the link to the PR (and the code review on that PR! it exists!) was, etc. It was a little weird as a complete newcomer not to see humans in the `git log --first-parent` view, but I really like it now, because if I want to know why some commit was merged the way it was, that discussion is recorded nicely. (The merge commit has the subject/body of the PR, which doesn't need to match the subject/body of any commit in the PR.) Compare with, like, the Linux kernel, where the best you can do is Google for LKML threads with the same subject line. There's even a convention of [PATCH 0/10] for summaries, but those summaries are nowhere to be seen in the git repository.

https://github.com/rust-lang/rust/commits/master

Re: The State of Go

#98

Post by jakub_g »

I tried to mitigate some of the pains with GitHub code review UI by writing a helper userscript to track the progress of big code reviews. Some of the items listed in the link can be fixed in this way.

The idea is to expand/collapse files, store progress of the review and collapse status of the files in local storage of the browser, so you can stop and resume at any time (I also have in mind serializing this stuff into a hash in the URL so you can forward it to the other machine for instance, and recreate the progress there).

I work on it every now and then and have a number of items in the backlog. If someone is interested to contribute I'll be happy to accept pull requests (sic!) :)

https://github.com/jakub-g/gh-code-review-assistant

Re: The State of Go

#99

Post by geofft »

boulos wrote: post #30

Does GitHub still not support "fast-forward only" commits? The "ugly merge" thing is easily avoided with a rebase before committing.

From the web interface, no, but you can close PRs with `git push` just fine.

Re: The State of Go

#100

Post by enneff »

hueving wrote: post #82
enneff wrote: post #79

Earlier quoted context omitted.

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.

It doesn't matter what the mechanism is; writing code that depends on code that changes is more complex than simply not doing that.
Post reply on HN