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

201–210 of 271 posts

Re: The State of Go

#201

Post by Mithaldu »

nkurz wrote: post #175
Mithaldu wrote: post #59

Earlier quoted context omitted.

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

I also am scared off by the public aspect, and find it a very awkward requirement. If there was an option to create a private branch on Github, I'd probably use it often. I'd love if there was an easy way to submit a quick patch using only the Github interface. As it is, I've clicked once in my life on the fork button, realized that it created something visible to the outside world, and have never used it again. Inst…

Now this is an interesting answer and i thank you for it. You don't have a problem that is in search of a solution. You have a real reason why github's publicity can actually be a bit hindering.

And i am even more grateful because it's truly a way i have not yet considered. See, for me github is a tool that i approach as dispassionately as my garage door opener. It is a thing with which i personally solve problems. Those problems are broken software or broken documentation. I use github to fix things. And i'm almost always doing so with a sense of nearly full confidence in that my issues or PRs will either fix a problem, or allow me to gain information so i can fix it. The only doubt i have is when i recognize the maintainer is not very skilled or otherwise mentally a little of the beaten path and might need some convincing.

The least concern i ever have is "someone might see what i'm doing", which is why i've ended up with 210 forks in my account. I didn't think that concern could ever be a thing since i started using Github long after the time when i last had reason to feel truly self-conscious about the code or documentation i'm creating, and you did remind me of the time before that point, so i can understand you now.

Maybe with time it will get better for you, maybe not. Please keep sending emails with patch files if that's what you feel most comfortable with.

And thank you. :)

Re: The State of Go

#202

Post by jaimeyap »

jaimeyap wrote: post #198
frowaway001 wrote: post #158

Earlier quoted context omitted.

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.

I probably sounded overly dismissive of github. Which probably isn't fair. But I'll leave my post un-edited for posterity. I use github every day for work. There are lots of things it gets right. But if you want to work on a project where you more or less have a central repository, take contributions from external and internal contributors, and have a strict policy of pre-submit reviews for individual commits to mast…

@piotrkaminski Comment nesting seemed to run out. So replying to myself.

Our team is currently using Rietveld. But I've used Gerrit in the past, as well as internal tools of the same flavor back when I was at Google.

I don't particularly love Rietveld. But it's simple to maintain and does the job. That being said, I'm genuinely looking forward to one day being able to just use Github for this.

Re: The State of Go

#203

Post by piotrkaminski »

jaimeyap wrote: post #202
jaimeyap wrote: post #198

Earlier quoted context omitted.

I probably sounded overly dismissive of github. Which probably isn't fair. But I'll leave my post un-edited for posterity. I use github every day for work. There are lots of things it gets right. But if you want to work on a project where you more or less have a central repository, take contributions from external and internal contributors, and have a strict policy of pre-submit reviews for individual commits to mast…

@piotrkaminski Comment nesting seemed to run out. So replying to myself. Our team is currently using Rietveld. But I've used Gerrit in the past, as well as internal tools of the same flavor back when I was at Google. I don't particularly love Rietveld. But it's simple to maintain and does the job. That being said, I'm genuinely looking forward to one day being able to just use Github for this.

Heh, that's almost exactly like me: used internal tools at Google, brought up a Rietveld instance after I left. Except that I got frustrated with Rietveld and built https://reviewable.io -- you might want to check it out. :)

FullStory looks awesome, BTW, I just wish I could afford it.

Re: The State of Go

#204

Post by rdtsc »

lomnakkus wrote: post #171
pjc50 wrote: post #109

Earlier quoted context omitted.

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.

Git != github. (Does this really need to be said?)

Saddly it does. There is probably a significant number of developers who never used git without Github.

As a funny aside, when Github breaks the thing to say is "I wish one day someone would invent a decentralized version control system" ;-)

Re: The State of Go

#205

Post by rdtsc »

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…

JVM is in use in a lot more performance critical paths than Go. Go just seems new so it is easy to list the 2-3 places that use at scale.

Re: The State of Go

#206

Post by pjmlp »

perturbation wrote: post #58
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.

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

There are quite a few JVMs that allow compilation to native ahead of time.

Re: The State of Go

#207

Post by pjmlp »

skybrian wrote: post #160
noir_lord wrote: post #46

Earlier quoted context omitted.

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/

If Google keeps Go away from Android, as first class language, only having the Go team doing NDK related support it doesn't really matter.

I don't foresee any changes on this regard at Google IO.

Re: The State of Go

#208

Post by microtonal »

twotwotwo wrote: post #139
eternalban wrote: post #116

Earlier quoted context omitted.

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 p…

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

We are not all writing web apps. Some of use are in machine learning, NLP, signal processing, etc. where squeezing out as much performance as possible does matter.

In those fields Go is still weak. No autovectorization, no OpenMP, no direct CUDA integration, GC overhead, etc. Luckily, this can often be worked around since cgo is so good. One can write performance-intensive parts in C or C++, compile with the latest gcc or clang and link it with the Go code to drive it. This is often an understated advantage of Go compared to Java, where JNI calls are expensive. But the Go camp always advocate for porting everything to Go (because fast compile times).

Re: The State of Go

#209

Post by microtonal »

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.

A dependency parser (in other words, serious program) in Go, linking in some external dependencies and a C++ machine learning library (statically):

  % du -k eval/eval
  2040	eval/eval

  % strip eval/eval
  % du -k eval/eval
  1864	eval/eval
Don't just assume. Measure.

Re: The State of Go

#210

Post by lambda »

Mithaldu wrote: post #201
nkurz wrote: post #175

Earlier quoted context omitted.

I also am scared off by the public aspect, and find it a very awkward requirement. If there was an option to create a private branch on Github, I'd probably use it often. I'd love if there was an easy way to submit a quick patch using only the Github interface. As it is, I've clicked once in my life on the fork button, realized that it created something visible to the outside world, and have never used it again. Inst…

Now this is an interesting answer and i thank you for it. You don't have a problem that is in search of a solution. You have a real reason why github's publicity can actually be a bit hindering. And i am even more grateful because it's truly a way i have not yet considered. See, for me github is a tool that i approach as dispassionately as my garage door opener. It is a thing with which i personally solve problems. T…

I think that it's a little bit of a problem with a lot of the modern "social web" mindset; it all implies that you should feel comfortable doing everything in public, with the whole world watching you.

The problem is, there are people for whom this really doesn't work well. Some might just personally feel uncomfortable about it. Some might be concerned about future career prospects. Some might be women, who are worried about online harassment. Some might be people with stalkers, who are trying to avoid any kind of traceable online public trail.

This whole "share all the things" mentality leads to somewhat creepy exposure of everyone's private lives to governments, corporations, the general public (which can act as a mob on occasion), and also specific private individuals who you might be trying to avoid exposing things to.

Post reply on HN