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

141–150 of 271 posts

Re: The State of Go

#141

Post by coldtea »

twotwotwo wrote: post #122
tylertreat wrote: post #60

Earlier quoted context omitted.

I don't know if I completely agree with this. To write truly performance-critical Go, you end up throwing away many of the language's qualities. Channels are slow, defers add overhead, interfaces add overhead (e.g. I2T), etc. Don't get me wrong, I like Go, but in my (and others I work with) experience, it's not the right choice for performance-critical systems.

I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.com). CloudFlare has it sitting in the middle of every request for some sites (in the form of Railgun, their delta compression for pages). I'm not exactly a perf ninja and got some Go code packing Wikipedia history dumps at >100 MB/s. Dropbox uses Go for, their…

>I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.com).

Not as impressive as it sounds. Most of it is cached in memory anyway...

Re: The State of Go

#142

Post by tylertreat »

twotwotwo wrote: post #122
tylertreat wrote: post #60

Earlier quoted context omitted.

I don't know if I completely agree with this. To write truly performance-critical Go, you end up throwing away many of the language's qualities. Channels are slow, defers add overhead, interfaces add overhead (e.g. I2T), etc. Don't get me wrong, I like Go, but in my (and others I work with) experience, it's not the right choice for performance-critical systems.

I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.com). CloudFlare has it sitting in the middle of every request for some sites (in the form of Railgun, their delta compression for pages). I'm not exactly a perf ninja and got some Go code packing Wikipedia history dumps at >100 MB/s. Dropbox uses Go for, their…

Agreed with setting the standard arbitrarily high. It depends on what problem you're trying to solve—just like deciding when to use any other tool. Context matters.

Where I work, we've been trying to build some super-fast systems and things like the GC and even calling interface methods matter. We open sourced some data structures that show just how optimized we're trying to get (https://github.com/Workiva/go-datastructures), but in hindsight, Go might not have been the right tool for the problem.

Re: The State of Go

#143

Post by xkarga00 »

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.

But really... stop using the merge button.

Re: The State of Go

#144

Post by piotrkaminski »

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

For a code review tool more powerful than GitHub's but with a much better UI than Gerrit, check out https://reviewable.io (disclosure: my project). It integrates smoothly with GitHub and doesn't require setting up your own host.

Re: The State of Go

#145

Post by cbr »

bdarnell wrote: post #90
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…

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

Re: The State of Go

#147

Post by EugeneOZ »

leereeves wrote: post #132
enneff wrote: post #25

Earlier quoted context omitted.

I don't understand the basis of your question. What does the bootstrapping process for a compiler have to do with "OSS's value proposition?" (By OSS I'm assuming you mean "Open Source Software"?) To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.

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?

Re: The State of Go

#148

Post by nosefrog »

leereeves wrote: post #132
enneff wrote: post #25

Earlier quoted context omitted.

I don't understand the basis of your question. What does the bootstrapping process for a compiler have to do with "OSS's value proposition?" (By OSS I'm assuming you mean "Open Source Software"?) To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.

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.

> What happens if this catches on

I don't understand your comment, because we already live in your nightmare scenario: http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#L...

In practice, it isn't a big deal. When was the last time you worried about the language your compiler was written in?

> potentially a lot of duplication of effort writing compiler backends in every language.

That's also the state of things for every compiler that doesn't use LLVM or compiles to another language.

Re: The State of Go

#149

Post by rdtsc »

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 is a false dichotomy. You can have a dirty repository history with fast forward merges as well. And you can have a clean repository history with explicit merges. As I wrote in a sibling comment, feature branch commits should be rebased to looks clean and meaningful (squashed in some cases if needed) but then merged into main/master branch using --no-ff flag in order to generate a merge commit.

Re: The State of Go

#150

Post by swetland »

enneff wrote: post #111
eternalban wrote: post #108

Earlier quoted context omitted.

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

Part of the reason Go exists is because of such issues. Believe me, it's not desirable. My point is, on typical machines today, even a 10mb binary is not an issue at all.

And this is a reason why, though I like the language, it's pretty useless for embedded work. Not all the world is lacking in resource constraints.
Post reply on HN