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

41–50 of 271 posts

Re: The State of Go

#41

Post by Mithaldu »

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 a remote to yours and use your familiar tools. If possible and done, a fast-forward merge + push will also close the PR.

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

    To create a patch one must fork the repository publicly
    (weird and unnecessary).
What exactly is weird about that? It makes it possible for the requestor to craft their changes with full control, without requiring upstream to give them write access. This point is just entirely nonsensical.

    In general, pull request culture is not about code review.
A strong claim, but one without any justification, and which is, in my experience, as far from the truth as possible.

Edit:

In light of their complaints about the need to fork, i have to say that their current contribution process can in its entirety be described as weird, unnecessary and baroque:

https://golang.org/doc/contribute.html

Re: The State of Go

#42

Post by sytse »

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.

GitLab CEO here. Both GitHub and GitLab normally always create a merge commit when accepting a merge request in the web UI. GitLab EE has a rebase feature where you can accept merge requests by automatically rebasing them just before merging, for more information see https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-re...

Re: The State of Go

#43

Post by MaulingMonkey »

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?

Re: The State of Go

#44

Post by arsv »

enneff wrote: post #23
arsv wrote: post #17

Earlier quoted context omitted.

> A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support an…

> "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope.…

> Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something.

It is not about the size of hello world executable, that is just a symptom. A code smell if you like. There is something badly broken in the dead code (or dead data) elimination area. And I hope that code is in fact dead, because if it is not, add code generation to the list of smelly things.

What I suspect I see here is a kind of C++ vtable problem built deep into the language design somewhere. And the reaction is, let's talk about large executables so that it would kinda become not so visible. Or maybe let's take a look at glibc, because glibc is definitely a paragon of clear design befitting a new language.

> fmt.Print does use reflection

There are two problems with this. The lesser one is why does it need reflection to print a string. The bigger one is why do I see about 600 reflect.* entries in the resulting ELF instead of a single one for the string type.

Re: The State of Go

#45

Post by hueving »

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.

That's like trying to predict the cost of a flight by cost per mile using a quote from SFO to SJC as a baseline.

Re: The State of Go

#46

Post by noir_lord »

enneff wrote: post #33
eternalban wrote: post #29

Earlier quoted context omitted.

It is a valid point considering the lack of dynamic linking. Go (as is) strongly suggests having lots of "small programs" compose a larger (modular) system on a node. So those 1.9MBs do add up.

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.

Re: The State of Go

#47

Post by justinmk »

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 after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests)

Yes, we try to keep PRs small. But they also need to be meaningful, and sometimes they require (many) more reworks than expected.

[1] https://github.com/neovim/neovim/pull/1820

Re: The State of Go

#48

Post by sytse »

admax88q wrote: post #38
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…

They're probably using Gerrit. Although I agree, I don't think merge commits are ugly. I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. In fact I find lots of developers just have an obsession with "clean" history, and fetishes for particular tools. It baffles me.

GitLab CEO here, I completely agree with your observation that people coming from SVN have a hard time adjusting to non-linear history. At GitLab we recommend embracing it https://about.gitlab.com/2014/09/29/gitlab-flow/ But we also believe in the freedom to do what you want, see there is a version of GitLab with automatic rebasing to allow a clean linear history without having to rebase by hand https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-re...

Re: The State of Go

#49

Post by hueving »

Gerrit still produces merge commits unless they have it configured to cherry-pick onto master, which is insane because you are changing the commit sha at that point.

Re: The State of Go

#50

Post by arsv »

vetinari wrote: post #26
arsv wrote: post #17

Earlier quoted context omitted.

> A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support an…

> A simple C "hello, world" program compiled and linked statically using gcc Statically. Care to check "ldd hello" of your binary?

"not a dynamic executable"

In case you wonder, that's dietlibc which is typically built with no dynamic linking capabilities whatsover.

Post reply on HN