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

131–140 of 271 posts

Re: The State of Go

#131

Post by jaimeyap »

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…

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

Re: The State of Go

#132

Post by leereeves »

enneff wrote: post #25
bdcravens wrote: post #20

Most of career has been spent doing web programming, so maybe I'm ignorant, but if you have to build Go with a Go binary, instead of C, doesn't this break OSS's value proposition? (obviously I'd have to start with a C compiler, but that feels a bit purer in my mind, as I can start with a pretty bare-bones OS)

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.

Re: The State of Go

#133

Post by Mithaldu »

MaulingMonkey wrote: post #126
Mithaldu wrote: post #66

Earlier quoted context omitted.

Your building strawmen does not help your credibility much, nor your attempt to convince me of your view. "Revisions that never existed" do exist, and if you put a rebase of a branch on master without verifying the rebase, then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason. Frankly, i find your style of argument through implication, and through trying to disregard som…

> "Revisions that never existed" do exist "Revision that were never built nor tested" is probably closer to the truth. Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Sure, they're similar, and you probably didn't mess up the merges. There's likely no subtle lingering bugs that QA's only going to catch weeks down the line. Probably. > then you may end up i…

> Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase?

Yes.

Re: The State of Go

#134

Post by enneff »

eternalban wrote: post #124
enneff wrote: post #64

Earlier quoted context omitted.

I disagree with "channels are slow". They may be faster than you think. Defers needn't add as much overhead as they do today; this can be fixed. I think it really depends on your definition of "performance-critical". I agree Go isn't suitable for all performance-critical tasks, but it covers a vast swathe of them quite comfortably.

> this can be fixed. I believe this and am counting on it. Go2.0 and beyond should be a solid choice. You should also note that it is entirely understood that more mature tech e.g. JVM have had the benefit of multibillion Dollar investment by SUN, IBM, Oracle, etc. I feel it is regrettable that (imo valid and reasonable) criticism of what is currently not up to par with this tech always seemingly requires a disclaime…

Valentines day was yesterday for me. You wouldn't see me spending my time responding here if it were today!

Re: The State of Go

#135

Post by ak217 »

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…

Thanks for replying directly. I have; I've used Gerrit and Phabricator (which also does inline comment draft keeping) a lot, and I've clicked around Rietveld. I just never have seen much use for the comment draft feature; keeping comments in draft is not what I naturally do. I can see where others might like that, so it could be a nice to have (though you can also use your browser to keep draft comments).

I think GitHub and to a lesser extent Phabricator have enormous UI/UX upsides over Gerrit and Rietveld, which perpetually look like internal tools that never underwent proper UX review. What's more important is that GitHub has done so much for open source software and has achieved such critical mass that a decision to not use it now starts to also shut you off from a population of developers for whom the activation energy is too high.

Re: The State of Go

#136

Post by eropple »

enneff wrote: post #130
eropple wrote: post #127

Earlier quoted context omitted.

More value than I think? I'm pretty sure that I know exactly their value. I'll maintain that stack-allocated structs are a nice-to-have on top of the sort of stack-allocated primitives that Java provides; I'd like to have those structs as a convenience when I write Java, which is why I alluded to terseness in my prior post. But there's very little (or should be, I suppose, depending on implementation) performance dif…

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 performance benefits. I'm not saying they aren't a nice convenience (value types are one of the things I love about C# when I'm writing code under MonoGame), I'm saying that I can't think of a reasonable way, barring bugs or short-sighted implementations, that they made for faster code.

Re: The State of Go

#137

Post by rdtsc »

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…

For integration branches it is nice to have cleanly rebased changesets which are then merged with "--no-ff" option so it generates an explicit merge commit.

Re: The State of Go

#138

Post by xkarga00 »

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…

Opinions do vary a lot. I am iterating over history logs quite a lot and IMHO nothing beats clean repositories. Again IMO merge commits have no reason of existence whatsoever.

Re: The State of Go

#139

Post by twotwotwo »

eternalban wrote: post #116
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.

Not an uncommon view: https://twitter.com/kellabyte/status/564531804837654528 (That's not me, to be clear.) We all like Go. Just wish we could discuss these matters without unduly raising temperatures. "It's just code".

Sommers is an absolute beast, does totally astounding work and is an asset to the community. But even when we say "performance-critical" most of us don't mean getting 3M req/sec from one box like she did w/Haywire (https://twitter.com/kellabyte/status/547063455048404992). In other words, pushing the hardware absolutely to its limits is another game (Sommers' game :) ) from simply getting a tricky part of your app performing at the level you need. And, confusingly, "high-performance" or "performance-critical" are terms you might use to describe either task.

For context, the person whose presentation triggered Kelly's comment, MIT scholar Neha Narula, was experimenting with an 80 core machine, and she replied "it's kind of amazing I could push Go that far," and "to be fair they weren't really optimizing for my use case :)" -- her whole presentation is on YouTube at https://www.youtube.com/watch?v=Mbg1COjhsJU (some wild stuff--she got improvements for >48-core machines pushed into the Go GC) and those replies I quoted are at https://twitter.com/neha/status/564569903219634176 .

Re: The State of Go

#140

Post by crawshaw »

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

Go gives you data structures with fewer pointers than Java, which helps cut down on GC pressure.

    type point struct {
        x int16
        y int16
    }
    points := make([]point, 1e6)
The value points uses 4 MB of memory and contains one pointer, not a million.
Post reply on HN