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

101–110 of 271 posts

Re: The State of Go

#101

Post by arsv »

mholt wrote: post #56
arsv wrote: post #44

Earlier quoted context omitted.

> 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 sme…

> The lesser one is why does it need reflection to print a string. It doesn't print just strings. It can print anything. http://golang.org/src/fmt/print.go?s=6420:6467#L221 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.

> 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, but it is not even mentioned there.

So to make life a bit easier for people who like me expect that issue to be discussed first, I posted a comment summarizing (in my opinion) the state of Go.

My thoughts on how to fix it are hardly relevant to the current state of Go.

> It doesn't print just strings. It can print anything.

The fact it is just a string should be statically (build-time) inferable in a strongly-typed language. Reflection, at least as I understand it, implies run-time type information. So the question does make sense. Yes, I understand why it may be needed for a particular implementation of printf, this is why I called it a lesser issue.

Re: The State of Go

#102

Post by justinmk »

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

Force pushes to the PR fork. We have set receive.denyNonFastForwards=true on the upstream master.

Re: The State of Go

#104

Post by enneff »

eropple wrote: post #96
enneff wrote: post #37

Earlier quoted context omitted.

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

Values ("off-GC primitives?") are first class-citizens in Go. Stack-allocated structs have much more value than you think.

Re: The State of Go

#105

Post by enneff »

arsv wrote: post #101
mholt wrote: post #56

Earlier quoted context omitted.

> The lesser one is why does it need reflection to print a string. It doesn't print just strings. It can print anything. http://golang.org/src/fmt/print.go?s=6420:6467#L221 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.

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

Re: The State of Go

#106

Post by pjc50 »

lmm wrote: post #62
Mithaldu wrote: post #52

Earlier quoted context omitted.

> I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master: It makes debugging very easy. With branch merges, especially when the branch lines cross, or the merge i…

Linearized histories are much harder to find bugs in. You end up looking through revisions that never existed; in SVN you merge the remote history into your local history without it ever showing up as a merge. The explicit git approach tells you something much closer to the truth. Your condescension is only hurting yourself.

Local history is not a concept in SVN. There is only one history which is the same for everyone.

Re: The State of Go

#107

Post by ak217 »

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 inside the PR interface, especially in light of the fact that they can be edited.

Cannot compare differences between patch sets.

You most certainly can. Just use branch/revision compare.

To create a patch one must fork the repository publicly (weird and unnecessary).

Also immaterial.

Accepting a patch creates a "merge commit" (ugly repo history).

This comes closest to being a legitimate complaint. Because GitHub emphasizes recognition of contributors, it doesn't let you rewrite the commits in the PR as you merge them with the merge button, but there are multiple ways to merge on the command line that avoid the merge commit and play nice with the PR.

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

WTF?

Sounds like a strong case of NIH.

Re: The State of Go

#108

Post by eternalban »

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

From what I hear you have the funds and resources to operate at that scale.

Re: The State of Go

#109

Post by pjc50 »

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.

Re: The State of Go

#110

Post by jrochkind1 »

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 written; you cannot "draft" comment'

But to each their own -- I'm curious what alternative system (if any) of accepting patches they have. If it's emailed git patches on a listserv, then I would definitely find it a barrier to submitting patches, myself, compared to github PR's.

I think in general, github PR's have proven succesful at soliciting code contributions from a wider field, which seems to be the goal of their UI (over command line git itself). Of course, this can seem a downside too, as committers have to spend time dealing with those submissions.

Post reply on HN