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

211–220 of 271 posts

Re: The State of Go

#211

Post by boulos »

geofft wrote: post #99
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.

From the web interface, no, but you can close PRs with `git push` just fine.

I mean the option to explicitly block any changes that generate a merge (that isn't a simple fast forward). You can set this on a git repo you fully control, but IIRC you can't do this on GitHub. So yes, it works fine until someone accidentally hits the big green button and generates a "real" merge.

Re: The State of Go

#212

Post by perturbation »

vardump wrote: post #87
perturbation wrote: post #58

Earlier quoted context omitted.

Doesn't Go have the potential to be faster than Java since it's compiled to native code (rather than compiled to byte code)?

JIT has potential to be faster than compiled native code. Better runtime information. Compiled code needs to cover all potential options and this means more instructions to execute. Say a variable value is set through a command line option to be a certain value. Compiled native code has to assume the value to be dynamic, but a JIT can optimize it away, effectively hardcoding it for that particular invocation. Same ap…

Thanks, that's a very clear (and thorough) explanation.

Re: The State of Go

#213

Post by dvirsky »

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.

I'm looking at an executable of a medium program I'm working on, probably around 5k LOC of my own code, using tons of standard library modules and linking to probably another 10-20k LOC of 3rd party libraries, all debug symbols in place. Weighs 5MB. I don't think this program in C++ would weigh much less.

Anyway it can be improved, but to me there are far more important things to be improved about Go than the binary size of small programs.

Re: The State of Go

#214

Post by enneff »

krenoten wrote: post #153
enneff wrote: post #8

Earlier quoted context omitted.

Rob Pike has nothing to do with the Plan 9 port of Go. It has been entirely driven by the outside community. I don't think Rob has used Plan 9 in years. > Most Googlers I've spoken to despise this guy's reactionary lordship over the project, This is pure nonsense.

Google is a huge place. I don't pretend to know what everybody, most people, or even a sizeable fraction of people there think. But a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. Take it with salt, but that is the noise I hear from my position on the outside. It may not match your experience, but it isn't nonsense. Just another datapoin…

When first you say

> Most Googlers I've spoken to despise this guy's reactionary lordship over the project

and then water it down to

> a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system.

then it seems like you're editorialising. Bear in mind that you're talking about real people and real relationships. Fanning the flames of hatred is unnecessary at best and sociopathic at worst. (Yes, I know people do this on the Internet all the time. That doesn't make it right.)

Re: The State of Go

#215

Post by lelf »

Blackthorn wrote: post #164

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!

Yeah, I'd prefer all those comments to be about the bootstrapping and GC (they can even keep the same tone, it'd be funny at least).

Re: The State of Go

#216

Post by amenghra »

cbr wrote: post #145
bdarnell wrote: post #90

Earlier quoted context omitted.

>> 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.) With github PRs, notifications are sent as soon as you write your first comment; in systems like gerrit and rietveld (and email) they are not sent until the reviewer chooses to send them. This leads to either awkward interactions if you…

My favorite are the comments like: 1:12pm line 33: Why are you doing this? 1:13pm line 33: I see, sorry, ignore my earlier comment. A system that lets you draft comments and then send them out in a batch can avoid a bunch of noise. On the other hand, though, people who aren't expecting it can get stuck with draft comments they don't send out.

I think we have the technology to show that a piece of text is a draft and hasn't yet been sent.

Imho, the end user should be able to choose between live commenting vs draft+send.

Re: The State of Go

#217

Post by joelthelion »

scrollaway wrote: post #93
falcolas wrote: post #75

Personal opinion here, but I much prefer merge commits as opposed to fast forwarded commits. With a merge commit, there's one commit to revoke if something breaks, and there's one commit per PR to step through with git bisect, and more importantly it maintains history, which to my eyes is more useful than a "pretty" repository. Drafting comments... if you want to draft comments, can't you do that in a separate editor…

> 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's extremely important if you want to attract cretins who favor "git history prettiness" over code quality.

Re: The State of Go

#218

Post by 4ad »

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.

The compiler is not rewritten, it is automatically translated from C, to Go:

http://golang.org/s/go13compiler

http://talks.golang.org/2014/c2go.slide#1

https://www.youtube.com/watch?v=QIE5nV5fDwA

Re: The State of Go

#219

Post by gtirloni »

Blackthorn wrote: post #164

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!

Agreed. However, the original submission called attention to that slide specifically, not the whole State of Go presentation. So people kept on topic :)

Re: The State of Go

#220

Post by lars512 »

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

Github didn't always distinguish well between repos you'd substantially authored and long-lived off-hand pull request forks. This made it annoying as a showcase of your work. Fortunately, they've made things much better now.
Post reply on HN