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

161–170 of 271 posts

Re: The State of Go

#161

Post by frowaway001 »

enneff wrote: post #105
arsv wrote: post #101

Earlier quoted context omitted.

> After doing your research, you're welcome to submit a magical CL and PR that brings down the binary sizes, then you won't need to argue anymore. The original link is titled "The State of Go". The first thing I want to know about a state of a new language is whether it works. Then how well it works. Then, maybe, how to fix it and which VCS to use. There is an issue I think is within the range of these two questions,…

> I posted a comment summarizing (in my opinion) the state of Go. Not trying to be rude, but your uninformed opinion is less valuable than you think.

Wow, Googlers being Googlers.

Re: The State of Go

#162

Post by Mithaldu »

rdtsc wrote: post #149
scrollaway wrote: post #93

Earlier quoted context omitted.

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

It is a false dichotomy. You can have a dirty repository history with fast forward merges as well. And you can have a clean repository history with explicit merges. As I wrote in a sibling comment, feature branch commits should be rebased to looks clean and meaningful (squashed in some cases if needed) but then merged into main/master branch using --no-ff flag in order to generate a merge commit.

Here's my specific issue with that: Even in such a merge it would be possible for someone to hide a change in the merge commit, and due to the nature of git it is quite difficult to figure out with confidence whether a merge commit contains additional changes or not. I much prefer the rebase/merge no ff approach over the common "just merge whatever the fuck whenever", but due to the possibility of hidden details in merge commits, i prefer a linear history.

Re: The State of Go

#163

Post by omeid2 »

> In general, pull request culture is not about code review.

A lot of people seem to here insist that this is somewhat even remotely true. This is not. Look through Docker's pull requests on Github, look at their CI hooks.

Re: The State of Go

#164

Post by Blackthorn »

The comments here represent one of the best examples of bikeshedding I've ever seen. The deep details of go are too complex for some people to really have an opinion on but god damn does everyone want to get their voices heard about github!

Re: The State of Go

#165

Post by sanxiyn »

justinsb wrote: post #54
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're mmaping a file and processing the majority of it, you really are typically doing that in C today if you care about performance. You can get acceptable performance in Java with ByteBuffers, but because of the lack of value types it doesn't feel like Java any more. Go should be able to get much closer to C's performance, while still being closer to idiomatic Go code. And Go can plug in small pieces of C code…

JNI is un-fun, so JVM developers are working on the solution. I think Panama will arrive sooner than Go making any inroads.

http://openjdk.java.net/projects/panama/

Re: The State of Go

#166

Post by Mithaldu »

enneff wrote: post #125
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…

Half your post is saying we should just use different tools, but we are. We're using Gerrit, that lets us work the way we want. On the contributor instructions: note that if you just want to use plain git (and not our git-codereview tool) then you can stop at "Register with Gerrit." We created the tool to provide a more familiar review process for the people that used our previous system. If we took your advice and u…

Thanks for the direct answer. I think my stance wasn't clear enough, so i'll reword what i wrote in another comment here.

My issues are two-fold:

You could have just said on that slide: "We want a central code review system, so people do not have to learn Git. Github isn't terrible, but Gerrit is much better."

Instead you ended up putting up a list of points that make github seem like some kind of fatally flawed thing, while frankly putting people off with inaccuracies/subjectivities.

Secondly, by not allowing things by github you're forcing people to learn something else. Most developers experienced with Git will also be very familiar with Github. You're telling those people to instead go and learn something else. That will result in some people deciding it's not worth the trouble. I'm fully aware it's up to you to decide whether you're willing to pay that price, but personally i find it a bit odd that you can't simply do both.

And as for, apparently, most of the documentation on your contribute page being safely ignorable: If that is truly the case, i recommend rewriting that to make it obvious, because right now it's anything but. :)

If the last bit is the only good thing that comes out of this, then i'll be happy.

Re: The State of Go

#167

Post by eiopa »

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…

Good tip.

It's interesting that other systems has a nicer implementation for it.

In Phabricator, it's:

  $ arc patch D12345
and it checks out revision 12345 into an appropriately named branch.

Re: The State of Go

#168

Post by hueving »

enneff wrote: post #100
hueving wrote: post #82

Earlier quoted context omitted.

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.

You can't "simply not do that" if you're project is fast moving. That's essentially the "you're holding it wrong" defense for a terrible design flaw.

Imagine you are developing a plugin framework for something and would like to develop a reference plugin at the same time to flesh out the API. Neither belongs as part of the same change but the plugin certainly depends on the framework. This is basically impossible in Gerrit because of the awful way dependencies work. The only way it can work is with a feature branch, which is basically giving up on Gerrit anyway and using git in the way it was intended.

Gerrit ultimately becomes a choke point on the throughout a given project can have unless you have an extremely small set of contributors that can coordinate well (i.e. Not a large open source project). Maybe this isn't a problem for Go since there is a high barrier to entry for contributors, but it's something to keep in mind.

Re: The State of Go

#169

Post by leereeves »

nosefrog wrote: post #148
leereeves wrote: post #132

Earlier quoted context omitted.

I think bdcravens means that to install Go from source on, say, a new Linux box, we will have to download a binary version of Go first, even though we probably already have gcc. What happens if this catches on, and PyPy replaces CPython, and other languages do the same? Hassles for those who prefer to install from source, and potentially a lot of duplication of effort writing compiler backends in every language.

> What happens if this catches on I don't understand your comment, because we already live in your nightmare scenario: http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#L... In practice, it isn't a big deal. When was the last time you worried about the language your compiler was written in? > potentially a lot of duplication of effort writing compiler backends in every language. That's also the state of thin…

I agree the installation issues are fairly trivial; they were just a response to the original comment.

But the duplication of effort (which won't end when the "GoGo" compiler is ready to replace cgo), and a potential freeze in Go while "GoGo" catches up, are more serious drawbacks.

Yes, that is a trade-off other compiler teams have made, and it may be the right choice for Go as well, but it should be (and no doubt has been) considered.

Re: The State of Go

#170

Post by lomnakkus »

kasey_junk wrote: post #63
Mithaldu wrote: post #59

Earlier quoted context omitted.

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

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'm not sure I understand. Vetting a changeset is basically the same thing as verifying the repo. Just look at the hash of repo A (your clone), check that it matches B (upstream), check that your repo A + "patch" matches pull request.

What am I missing?

Post reply on HN