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

151–160 of 271 posts

Re: The State of Go

#151

Post by piotrkaminski »

enneff wrote: post #121
ak217 wrote: post #107

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…

> 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. This scenario happens often: I read through a change, making comments as I go. Then I reach some part of the change and realise "Oh, that explains why they did that in that other file!" So I go back and delete or alter my comments. In Gerrit or Rietveld, the reviewee never s…

You might also want to check out https://reviewable.io. It's got most of the useful features of Rietveld (and, to a lesser degree, Gerrit), but with a UI that isn't stuck in the '90s and one-click integration with your GitHub project. Draft comments, threaded discussions that don't disappear, explicit tracking of resolution, quick diffs between (multi-commit) revisions, support for rebasing/merging without losing review history, etc. It trades off the deep customization possible with Gerrit, but is still much better than GitHub's PRs (IMHO -- I'm the author).

Re: The State of Go

#152

Post by rdtsc »

pjc50 wrote: post #109
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.

I see you've been downvoted and I think unfairly. I agree with you though.

Looking back at arguments people make about how to "do it properly", it looks like something is broken. Git is broken, maybe Github is broken, documentation, UI, marketing. Something is though. When an obvious UI element is there, seemingly designed to do merges, and then everyone says "no, no, do this other thing", like send emails, then rebase here on top of that, make a ref pattern in your ~/.gitconfig ...

Re: The State of Go

#153

Post by krenoten »

enneff wrote: post #8
krenoten wrote: post #2

> Now running Linux, FreeBSD, OpenBSD, and Plan 9 builders on Google Compute Engine. (OS X, Windows coming soon.) What purpose does putting work into Plan 9 support serve other than wastefully gratifying Rob Pike? Most Googlers I've spoken to despise this guy's reactionary lordship over the project, and seeing stuff like this lends evidence to the idea of it being a North Korean situation.

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

On the flip side, I'm glad that the Plan 9 port was contributed by the outside community, and that my suspicions about a poor engineer being put up to overtly political work were untrue.

Re: The State of Go

#154

Post by hacknat »

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…

You rock!

Re: The State of Go

#155

Post by sytse »

sytse wrote: post #42
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...

I see this is down-voted (after being up-voted initially). I thought it was interesting that GitLab allows you to accept pull/merge requests without creating a merge commit. Should I not have included the url? Edit: Thanks for re-upvoting it

Re: The State of Go

#156

Post by geodel »

eropple wrote: post #136
enneff wrote: post #130

Earlier quoted context omitted.

You said: > I considered stack-allocated structs in Go, but honestly that doesn't strike me as a particularly major thing; But for me they're one of the major ways in which I control memory use in Go programs. So, yeah, I think you underestimate them. No condescension implied. Apologies if it came across that way. I think we probably agree more than we disagree.

Yeah, I edited it out because after I took a breath I figured you didn't mean it that way. =) Hugs all around. But I really don't think it's a major thing, because there's no meaningful difference, in terms of performance, between "struct { int x; int y; } A" and "int Ax; int Ay;". I'm suspicious of claims that Go, as fundamentally a not that different language to a JVM language, is going to yield significant perform…

If it is not a major thing JVM architects would not deliberating on this issue in such details. http://cr.openjdk.java.net/~jrose/values/values-0.html

Java value types are going to be in Java 10 i.e. years away. So may be it is not big deal for you but JVM developers think it is going to be big deal for lot of performance sensitive code.

This is despite the fact that most advanced GC available in Java.

See overhead for Java data structures.

https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...

Go does not have this heavy overhead.

Re: The State of Go

#157

Post by leereeves »

EugeneOZ wrote: post #147
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.

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.

Re: The State of Go

#158

Post by frowaway001 »

jaimeyap wrote: post #131
enneff wrote: post #121

Earlier quoted context omitted.

> 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. This scenario happens often: I read through a change, making comments as I go. Then I reach some part of the change and realise "Oh, that explains why they did that in that other file!" So I go back and delete or alter my comments. In Gerrit or Rietveld, the reviewee never s…

A lot of people commenting here probably haven't had the experience of working with mature pre-submit code review tools. It's funny how much of an opinion people seem to have about things they don't know about. I'm shocked at how bad Githubs PR review UI is given how much funding they have had for so many years. Even abandoned side projects like Rietveld have vastly better review UIs and workflows for larger patch se…

I don't see a problem. Google people use what their NIH-filter-bubble tells them and the rest of the world uses Git(Hub).

Everyone is happy.

Re: The State of Go

#159

Post by kasey_junk »

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…

People use mmapped files all the time in performance critical Java. Typically using the unsafe packages. In fact, if you want to communicate with C/assembler level things, this is the way people who do fast Java do it because JNI is very slow.

If you want to use an abstraction around ByteBuffers that feels like value types take a look at the javalution structs.

As a counter to your argument, C# has had value types for quite a while and has not achieved Java levels of performance, so those in and of themselves aren't enough. Mostly thats because if you are doing any allocation in fast code you are doing it wrong regardless of language. Even in C object pools and arena allocation are standard for performance critical work. The gap between Java and C (or really C++) right now is almost entirely around control of the memory model, not allocation (that said, I'd love the JVM to have value types and am glad that go started with them).

If anything will allow go to achieve better performance than Java its that it will be able to incorporate the lessons learned from Java without the support burden. I do think the constrained nature of go will give it a very good chance at impressive performance.

Re: The State of Go

#160

Post by skybrian »

noir_lord wrote: post #46
enneff wrote: post #33

Earlier quoted context omitted.

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.

It matters when you have to download the file over a slow network.

"The ideal size is 10-15MB globally. Idea size for an app for tier 2/3 countries (like India) is below 5MB. 500MB+ is a non-starter. At 50MB+ the conversion rates fall off dramatically."

http://time.com/3589909/internet-next-billion-mobile/

Post reply on HN