Live data from Hacker News

"100% of our production system is now running Go"

groups.google.com

81–90 of 189 posts

Re: "100% of our production system is now running Go"

#81
post #59
post #16

Earlier quoted context omitted.

It's a shopping website. It's sorta hard to do cart management without cookies.

Just put a session id in the URLs.

keeping a session id in the URLs is way less secure as it is susceptible to XSS attacks, it can leak in referer headers, it can be accidentally shared by people copy & pasting the URL and by extension, the session ID might even end up in a search engine and depending on your bad luck, the bots might visit the page just often enough so the session doesn't expire on the server at which point an authenticated session is in the search engines.

Session cookies on the other hand can be marked as http-only, mitigating XSS in many browsers (there are some that still screw this up with XmlHttpRequest) and by not having the session id in the url, the id is much less likely to be shared with others, nor to appear in search engines.

Also, it keeps the URLs nice looking.

So why exactly would one want to disable session cookies?

Because of all of the above reasons, I'd much rather keep users with cookies disabled away from my application than to subject them to the ugly URL fallback which will impact their security much, much more than the perceived privacy loss of session cookies (which go away when you close the browser)

Re: "100% of our production system is now running Go"

#82
post #40
post #21

I'd be really curious to know what their "800 million requests a month" means. When we actually added up numbers a while back, we were doing around 250 million requests to our Python machines/day, and we only had 200 servers (which included dbs/etc), that was around 3-3.5 billion pageviews a month IIRC. We now have 300 machines and do about 5 billion pageviews, but that completely ignores the huge amounts of requests…

200 servers for 800mio requests seems a little nuts. Two of my customers are doing 500mio and 400mio respectively on ~20 each, on Rails (i.e. as slow as it gets).

Do you count cache hits as a request?

Re: "100% of our production system is now running Go"

#83
post #47

Edit: I just posted 3 minutes ago and I'm already in gray text. Wow. We search with Google, run our phones with Google, run Google's browser, now they want us to write all our code in Google's language. Why Google? What's wrong with Java? Other than the fact that Oracle owns it, I miss Sun. Scott McNealy tried to make the technology world better. Scott, Gosling. Google...why should everything we do all day and night…

>> C, seriously? C??!? For those, like myself, that like C and do systems programming. Really never understood why people dislike or fear C so much. It is the foundation for so many systems and libraries.

The main problem people have with C syntax is that it's 'old' and 'old' things are bad because new things are better. We're an industry built on fashions. Largely the outcome of the massive success programmers can have without any formal education and so just get by knowing the "best" way to do things instead of understanding why.

Re: "100% of our production system is now running Go"

#84

I want to try out Go, but the problems exposed by the garbage collector on 32bit systems scared me away. Is that still the case with the latest version 1.0.2 ? Also, is there any chance for a precise generational garbage collector to get implemented for Go? As far as I know, pointers make the implementation of precise garbage collectors difficult.

There is code to make the garbage collector more precise currently in review. A few packages from the stdlib were changed to reduce the chance that package level variables might pin used sections of memory. Most people have no problems with the garbage collector on 32bit systems.

Re: "100% of our production system is now running Go"

#85
post #52

Earlier quoted context omitted.

Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn…

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

I think there's a bit of truth in both

And you can't use go outside of the "PC" (that is, embedded systems).

Re: "100% of our production system is now running Go"

#86

I want to try out Go, but the problems exposed by the garbage collector on 32bit systems scared me away. Is that still the case with the latest version 1.0.2 ? Also, is there any chance for a precise generational garbage collector to get implemented for Go? As far as I know, pointers make the implementation of precise garbage collectors difficult.

AFAIK, yes it is still the case (although somewhat slightly improved), but precise collector is officially expected (and being worked on) for version 1.1 . The latter was explicitly said on a Q&A session on Google I/O conference, the video is available somewhere on teh interwebs.

edit: I think it's this one: http://youtu.be/sln-gJaURzk ("Meet the Go team"), but maybe some other from: http://blog.golang.org/2012/07/go-videos-from-google-io-2012... (sorry, don't have time to watch them all again now to make sure ;)

Re: "100% of our production system is now running Go"

#87
post #50

Earlier quoted context omitted.

I actually haven't gotten this far with Go myself so I'm glad to hear that it's possible. But there's a huge uphill battle ahead for Go here. For instance, I write C++ code because I'm doing music software and all the APIs and existing code libraries and samples are in C++. It's just so much easier in this environment to put up with C++'s warts than it would be to try to shoehorn Go in there. As John Carmack says, ex…

Swig can help there?

or cgo? http://golang.org/cmd/cgo/

Re: "100% of our production system is now running Go"

#88
post #86

I want to try out Go, but the problems exposed by the garbage collector on 32bit systems scared me away. Is that still the case with the latest version 1.0.2 ? Also, is there any chance for a precise generational garbage collector to get implemented for Go? As far as I know, pointers make the implementation of precise garbage collectors difficult.

AFAIK, yes it is still the case (although somewhat slightly improved), but precise collector is officially expected (and being worked on) for version 1.1 . The latter was explicitly said on a Q&A session on Google I/O conference, the video is available somewhere on teh interwebs. edit: I think it's this one: http://youtu.be/sln-gJaURzk ("Meet the Go team"), but maybe some other from: http://blog.golang.org/2012/07/go…

That's good to know, thanks.

Re: "100% of our production system is now running Go"

#90
post #52

Earlier quoted context omitted.

> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.

I think there's a bit of truth in both And you can't use go outside of the "PC" (that is, embedded systems).

> And you can't use go outside of the "PC" (that is, embedded systems).

Why not? It runs on Arm.

Post reply on HN