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

31–40 of 271 posts

Re: The State of Go

#31

Post by nawitus »

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 request culture is not about code review."

I have no idea what this means.

Re: The State of Go

#32

Post by SBullet01 »

georgemcbay wrote: post #19
arsv wrote: post #11

> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.

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.

Re: The State of Go

#33

Post by enneff »

eternalban wrote: post #29
enneff wrote: post #23

Earlier quoted context omitted.

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

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

Re: The State of Go

#34

Post by [deleted] »

arsv wrote: post #11

> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.

[deleted]

Re: The State of Go

#35

Post by enneff »

mapleoin wrote: post #27
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).

Agreed. What I like most about GitHub pull requests is that they encourage splitting commits into smaller ones. Gerrit is focused on doing a change in one big commit.

Actually, the Gerrit workflow is pretty agnostic about whether you use one or many commits.

In general, it's poor form to send massive commits anyway. Those poor reviewers!

Re: The State of Go

#36

Post by enneff »

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.

Which makes no sense, anyway. The reason a Hello World program in Go is large is because it must include the baseline runtime support that is included in any Go program. A 10 line program won't be 13mb.

Re: The State of Go

#37

Post by enneff »

eternalban wrote: post #28
justinsb wrote: post #22

> Better bindings for calling Go from Java. If that is available for general Java code (i.e. uses JNI) and not just for Android, that could be really huge for Go. Writing performance-sensitive low-level code in Java is still fairly painful, wheras Go still isn't great for writing big programs. I can imagine (for example) Hadoop, Lucene/Elasticsearch and PrestoDB all using this.

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.

Re: The State of Go

#38

Post by admax88q »

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.

Re: The State of Go

#39

Post by notnowlewis »

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.

One of the previous slides says they are using Gerrit.

Re: The State of Go

#40

Post by inglor »

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.
Post reply on HN