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

181–190 of 271 posts

Re: The State of Go

#181

Post by enneff »

hueving wrote: post #168
enneff wrote: post #100

Earlier quoted context omitted.

It doesn't matter what the mechanism is; writing code that depends on code that changes is more complex than simply not doing that.

You can't "simply not do that" if you're project is fast moving. That's essentially the "you're holding it wrong" defense for a terrible design flaw. Imagine you are developing a plugin framework for something and would like to develop a reference plugin at the same time to flesh out the API. Neither belongs as part of the same change but the plugin certainly depends on the framework. This is basically impossible in…

The Go project is sufficiently modular that this isn't an issue for us.

Re: The State of Go

#182

Post by zak_mc_kracken »

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…

You're leaving out the alternative, which is the important part.

If you pull rebase, then that merge commit will be whatever the author of the commit decides it should be.

If they currently have ten files open, the merge commit will be ten files, regardless of how connected these files are, which is a lot of noise. With a pull-rebase, when they are ready to commit, they will decide to break it down nicely in 2+3+3+2 files.

The only person who should decide how to merge their files should be the person that modified these files, not git.

Re: The State of Go

#183

Post by andrewchambers »

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)

They want things in c unless they are tools for a language other than c. In which case it can be in that language.

Re: The State of Go

#184

Post by andrewchambers »

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)

They want things in c unless they are tools for a language other than c. In which case it can be in that language.

Re: The State of Go

#185

Post by zak_mc_kracken »

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

I think it's very fair to demand from a contributor to sync and build the entire app before they're allowed to submit a patch.

Interestingly, I note the Go team says it's "unnecessary" but doesn't provide their alternative.

Re: The State of Go

#186

Post by enneff »

nutate wrote: post #174
nutate wrote: post #77

Earlier quoted context omitted.

MFW I read this: http://makeitthentelleverybody.com/wp-content/uploads/2014/0...

It would seem no one got the joke that this is a pencil drawing by Renee French illustrator of the Go Gopher.

I got it, and laughed :-)

Re: The State of Go

#187

Post by dsymonds »

zak_mc_kracken wrote: post #178
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…

It's not exactly the first the time Go team is showing that they haven't spent much time researching current practices, theory, research and tools in the field of software engineering. Everything about the language screams of coming from minds who stopped learning new things in the late 90s.

I think you mean s/researching/adopting/, since you are only referring to the outcome, not the study or decision making that arrived at the outcome. The Go team generally knows about modern things; we deliberately choose not to use them when we don't think they suit Go.

Re: The State of Go

#188

Post by themightykevdog »

zak_mc_kracken wrote: post #178
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…

It's not exactly the first the time Go team is showing that they haven't spent much time researching current practices, theory, research and tools in the field of software engineering. Everything about the language screams of coming from minds who stopped learning new things in the late 90s.

This is so colossally misguided a comment it's hard to know where to begin. So I won't.

Re: The State of Go

#189

Post by sirclueless »

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…

No one doubts that Go is production ready at this point. But the performance requirements of a systems programming language are just very different from the requirements for a web server or applications language.

From my point of view, and the industry I'm in, the latency requirements of a web server stack look completely laughable. That's not to say there aren't challenges in a web stack, because many web servers have to handle orders of magnitude more I/O than we do, and efficient load balancing over a distributed system is extremely difficult and I am fortunate to rarely have to think about that kind of thing. But a requirement like "99% of requests need to have a response time of 200ms or lower" looks like fiddlesticks compared to a requirement like "a round-trip-time of more than 100us will be a large problem and get noticed".

My point is that Google's, CloudFlare's, and Dropbox's "performance-critical backends" don't require the same things as some other workloads. As a more mundane example, the latency requirements of Google's search engine are probably less stringent than the latency requirements of your text editor.

None of this should be taken to mean Go is slow or can't handle 99% of the world's performance requirements. But you can't just say "Go is high performance and fits in all of these company's critical paths. Try harder and it will work." Sometimes it might just not be cut out for it.

Re: The State of Go

#190

Post by dsymonds »

zak_mc_kracken wrote: post #185

> To create a patch one must fork the repository publicly (weird and unnecessary). I think it's very fair to demand from a contributor to sync and build the entire app before they're allowed to submit a patch. Interestingly, I note the Go team says it's "unnecessary" but doesn't provide their alternative.

We expect contributors to sync and run all the tests. The public forking is the weird and unnecessary part.

Gerrit is the alternative used, and contributors have a full local clone of the git repo, with their commit, and that's private on their machine until they push it to Gerrit for review.

Post reply on HN