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

171–180 of 271 posts

Re: The State of Go

#171

Post by lomnakkus »

pjc50 wrote: post #109
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…

Don't use the merge button, just This is the smell of git plumbing again. Don't use the obvious UX that's been presented to you, do some other workflow that doesn't appear in the documentation.

Git != github.

(Does this really need to be said?)

Re: The State of Go

#172

Post by MaulingMonkey »

Mithaldu wrote: post #133
MaulingMonkey wrote: post #126

Earlier quoted context omitted.

> "Revisions that never existed" do exist "Revision that were never built nor tested" is probably closer to the truth. Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Sure, they're similar, and you probably didn't mess up the merges. There's likely no subtle lingering bugs that QA's only going to catch weeks down the line. Probably. > then you may end up i…

> Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Yes.

I hope that's all automated with short build+test iteration times! That'd easily eat a day for minor feature branches for me - I can't afford that kind of turnaround time.

Re: The State of Go

#173

Post by mdwrigh2 »

jrochkind1 wrote: post #110

Yeah, I dunno, the github PR 'culture' I've engaged in has often in fact been about code review. I don't see any problems with forking a repo publicaly to make a PR (what is there to hide?), am not really bothered by merge commits (and in some cases they are actually quite useful, some people prefer them, it's a point of some contention), and I don't really understand what they mean by 'Comments are sent as they are…

They use Gerrit: https://code.google.com/p/gerrit/

Re: The State of Go

#174

Post by nutate »

nutate wrote: post #77
didyoucheckthe wrote: post #70

I'm sorry, but the Go Gopher's eyes[1] will always remind me of boobs. [1]: https://talks.golang.org/2015/state-of-go.slide#21

MFW I read this: http://makeitthentelleverybody.com/wp-content/uploads/2014/0...

It would seem no one got the joke that this is a pencil drawing by Renee French illustrator of the Go Gopher.

Re: The State of Go

#175

Post by nkurz »

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

I also am scared off by the public aspect, and find it a very awkward requirement. If there was an option to create a private branch on Github, I'd probably use it often. I'd love if there was an easy way to submit a quick patch using only the Github interface. As it is, I've clicked once in my life on the fork button, realized that it created something visible to the outside world, and have never used it again. Instead, I make a local checkout, and generate patch files.

It's difficult for me to explain why I feel this way. The original stigma of 'fork' is definitely part of it, but most of it is just my distaste for visibility: it feels horribly immodest to associate myself with a project with which I probably have only a passing association. I can't defend my attitude, but it's probably worth noting that people like me (and apparently the author of the Go article) will be dissuaded if public affiliation is a requirement.

Re: The State of Go

#176

Post by pkroll »

leereeves wrote: post #157
EugeneOZ wrote: post #147

Earlier quoted context omitted.

So you think all compilers should be written in C exclusively?

No, I was just pointing out a drawback. Of course there are advantages too. In this particular case, though, I wonder why the Go team is planning to spend a lot of effort rewriting an already existing compiler. Rewriting a popular project from scratch can be a dangerous temptation.

They explain why in detail here: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw...

Also, you don't have to download a binary of Go to compile the latest Go. You can download the Go source back when it was compiled by C, compile it, and then compile the later, Go-sourced versions, if for any reason you need to go that far.

Re: The State of Go

#177

Post by yawaramin »

MaulingMonkey wrote: post #43
nawitus wrote: post #31

What is the better alternative Go is using? "Can only view diffs on a single page" You don't need to use GitHub to view diffs. "To create a patch one must fork the repository publicly (weird and unnecessary)." I don't think it's weird. "Accepting a patch creates a "merge commit" (ugly repo history)." You don't need to have a merge commit, although I don't think that creates an ugly repo history. "In general, pull req…

> "In general, pull request culture is not about code review." > I have no idea what this means. Me either. To me, the entire point of pull requests is about triggering (code) reviews. If I don't want to bother with review, why not just grant direct push access and skip the rubber stamp ceremony?

Pull request culture is about enabling distributed collaboration, i.e. I don't have push permission to your repo and you don't have push permission to mine, but we can still collaborate by sending each other pull requests and sharing our work that way. It's all about collaboration while not trusting the other person with write access to your repo.

Re: The State of Go

#178

Post by zak_mc_kracken »

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…

It's not exactly the first the time Go team is showing that they haven't spent much time researching current practices, theory, research and tools in the field of software engineering.

Everything about the language screams of coming from minds who stopped learning new things in the late 90s.

Re: The State of Go

#179

Post by zak_mc_kracken »

justinmk wrote: post #65
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…

> Don't use the merge button, just add the requester's repo as a remote to yours Actually, you don't need to do that. GitHub provides a special pulls remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so: [remote "upstream"] url = https://github.com/neovim/neovim.git fetch = +refs/heads/*:refs/remotes/upstream/* fetch = +refs/pull/*/head:refs/pull/upstream/* Then wh…

This is... amazing. Thank you so much.

Re: The State of Go

#180

Post by yawaramin »

enneff wrote: post #121
ak217 wrote: post #107

Can only view diffs on a single page (can be very slow). I've seen GitHub take five seconds to render a 100K line diff. In my experience all of the other tools I've used, including some of the ones listed, can take longer to render individual file sections of such a diff. It's fast enough. Comments are sent as they are written; you cannot "draft" comments. I'm a bit puzzled as to why you would need to draft comments…

> I'm a bit puzzled as to why you would need to draft comments inside the PR interface, especially in light of the fact that they can be edited. This scenario happens often: I read through a change, making comments as I go. Then I reach some part of the change and realise "Oh, that explains why they did that in that other file!" So I go back and delete or alter my comments. In Gerrit or Rietveld, the reviewee never s…

You're talking about GitHub commit comments, right? Can you not simply click to comment, compose your comments one by one, and then not send them immediately? You can send them all together after you finish reviewing the entire commit.

Although it would be nice to have a 'Send All Comments' button at the bottom of the commit page so you didn't have to click through them one by one.

Post reply on HN