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

261–270 of 271 posts

Re: The State of Go

#261

Post by dsymonds »

WorldWideWayne wrote: post #235
enneff wrote: post #214

Earlier quoted context omitted.

When first you say > Most Googlers I've spoken to despise this guy's reactionary lordship over the project and then water it down to > a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. then it seems like you're editorialising. Bear in mind that you're talking about real people and real relationships. Fanning the flames of hatred is unneces…

Did anyone expect all commenters to be hard-facts-only journalists here? I come here for the rumors. And this is the 3rd time in a few months that I've heard that Googlers generally don't like Go and don't use it. So, that's kind of interesting. Anyway, I don't think you can call an activity sociopathic if the vast majority of humans take part in it. (Having opinions and spreading rumors didn't start with the Interne…

I don't think it's true that "Googlers generally don't like Go". Some like it, and some don't. From my vantage point, the majority (maybe 80% or so) who have actually tried to do real with in Go seem to like it.

Re: The State of Go

#262

Post by Matt_Cutts »

WorldWideWayne wrote: post #235
enneff wrote: post #214

Earlier quoted context omitted.

When first you say > Most Googlers I've spoken to despise this guy's reactionary lordship over the project and then water it down to > a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. then it seems like you're editorialising. Bear in mind that you're talking about real people and real relationships. Fanning the flames of hatred is unneces…

Did anyone expect all commenters to be hard-facts-only journalists here? I come here for the rumors. And this is the 3rd time in a few months that I've heard that Googlers generally don't like Go and don't use it. So, that's kind of interesting. Anyway, I don't think you can call an activity sociopathic if the vast majority of humans take part in it. (Having opinions and spreading rumors didn't start with the Interne…

Lots of Googlers like Go and use it. I'm using it for a hobby project that I'm working on right now.

Re: The State of Go

#263

Post by enneff »

hueving wrote: post #249
enneff wrote: post #181

Earlier quoted context omitted.

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

Didn't you say that you used feature branches? If so, that was a case where Gerrit failed and you had to use git in an almost normal way.

How is that Gerrit failing? Gerrit is designed to support all kinds of workflows, just like Git. As far as I can tell, we're using our various tools the way they were intended. Just because it doesn't line up with your exact view on how Git should be used, doesn't mean we're doing something wrong (or "insane").

This is a boring conversation.

Re: The State of Go

#264

Post by enneff »

WorldWideWayne wrote: post #235
enneff wrote: post #214

Earlier quoted context omitted.

When first you say > Most Googlers I've spoken to despise this guy's reactionary lordship over the project and then water it down to > a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. then it seems like you're editorialising. Bear in mind that you're talking about real people and real relationships. Fanning the flames of hatred is unneces…

Did anyone expect all commenters to be hard-facts-only journalists here? I come here for the rumors. And this is the 3rd time in a few months that I've heard that Googlers generally don't like Go and don't use it. So, that's kind of interesting. Anyway, I don't think you can call an activity sociopathic if the vast majority of humans take part in it. (Having opinions and spreading rumors didn't start with the Interne…

> I don't think you can call an activity sociopathic if the vast majority of humans take part in it.

If you think the vast majority of people go around saying negative shit about people they don't know, then you need to reevaluate your worldview.

Maybe you're experiencing some observation bias, as the people who do this are highly visible, but the reality is that most people do not relish publicly spreading negativity.

There's a reason why people become known as the "town gossip" and are looked down upon for it.

Re: The State of Go

#265

Post by drothlis »

justinmk wrote: post #47
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).

> where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non-trivial reviews. Biggest WTFs: - No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments. - Source "annotations" are lost…

> Source "annotations" are lost after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests)

Yes, that is incredibly annoying. I discovered that if you add your comments in the "Files changed" tab (which shows the diff of the entire pull request) instead of the "Commits" tab (which shows the diff commit-by-commit), then the comments aren't lost when you force-push.

Just FYI, might make life a bit easier if you're stuck with Github.

Re: The State of Go

#266

Post by twotwotwo »

microtonal wrote: post #208
twotwotwo wrote: post #139

Earlier quoted context omitted.

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

Indeed, we agree that Go is suitable for some things people call high-performance but not others. I do not advocate porting everything to Go. Not only is it not always a good fit, but there's a very high bar to clear to justify revamping any perfectly good codebase. (I use Python at work and wouldn't advocate for porting anything.)

Re: The State of Go

#267

Post by Skinney »

Jweb_Guru wrote: post #260
Skinney wrote: post #232

Earlier quoted context omitted.

Go is stable, wheras Rust is not. Go also targets other use cases than Rust, and so the two are not directly comparable. 1. Rust cannot guarantee multi-threaded memory safety in all cases. Care, as in Go, must still be taken. 2. I agree with you here, I think Go would be better with generics. But apparently, most people don't have a problem with this. 3. Rust and Go's error handling is based on the same principle: fo…

While I do generally agree with what you've written, I do want to take issue with point (1). Rust is actually intended to guarantee multi-threaded memory safety in safe code. Period. If you can get it to behave otherwise, it's a bug in Rust.

True. What I really meant is that safe code can interact with unsafe code, and thus cannot guarantee everything working correctly. Of course, this is bug with unsafe code, my bad.

Re: The State of Go

#268

Post by pjmlp »

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…

If you read her tweets she states C++ would have been a better option, though.

Re: The State of Go

#269

Post by pjmlp »

dottrap wrote: post #256
vardump wrote: post #87

Earlier quoted context omitted.

JIT has potential to be faster than compiled native code. Better runtime information. Compiled code needs to cover all potential options and this means more instructions to execute. Say a variable value is set through a command line option to be a certain value. Compiled native code has to assume the value to be dynamic, but a JIT can optimize it away, effectively hardcoding it for that particular invocation. Same ap…

I'm glad you emphasized potential and mentioned reality. One other aspect that has become increasingly important is power consumption and heat. Huge data centers now have to worry about enormous electricity consumption and keeping all the equipment cool. JIT code must do more work to compile (and recompile to optimize) on the fly which means more power and more heat. On the consumer end, Android just switched to Ahea…

Same on Windows Phone. .NET is also compiled to native code ahead of time.

Re: The State of Go

#270

Post by hhaidar »

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…

WOW, this has been missing from my life for way too long!

Thank you :D

Post reply on HN