Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

groups.google.com

Post reply on HN
Print view View original

71–80 of 189 posts

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

#71

Post by heretohelp »

shawndrost wrote: post #66
zeeg wrote: 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…

I interviewed with moovweb a while back... they basically transcode non-mobile-optimized sites into mobile-optimized sites on the fly by transforming html/css/etc.

The results...aren't great.

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

#72

Post by dkroy »

pilif wrote: post #46
dkroy wrote: post #17

Earlier quoted context omitted.

They are a good fallback, I think he is talking about using things such as Local storage, session storage, or global storage. Since the site is their mobile site I see no reason why they aren't using the new technology available to us since most mobile devices would be able to use it. DOM storage seems to be a better fit for shopping carts than cookies anyways.

It's not about the shopping cart. It's about all the session data, especially for authentication. While you could use Dom storage for storing a session ID, you would have to send that through to the server with every request which you get for free with cookies. Additionally, cookies can be marked as http only or even as secure, making it very hard to lose the token by virtue of a fire sheep like, or even just XSS att…

Cookies are stored on the client just like DOM Storage, so nothing is free when it comes to requests and communicating with the server. I understand that both still have their place. Though I generally prefer to use DOM Storage for most things now depending on the use case. I also complete agree about keeping server-side session data.

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

#73

Post by qznc »

batista wrote: post #52
thebigshane wrote: post #19

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.

C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance.

Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.

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

#74

Post by microtonal »

Evbn wrote: post #56
pkulak wrote: post #45

How's the garbage collector these days for Go? Is it close to the performance of the Java GC?

It's not as sophisticated, but Go structs are smaller than similar Java objects, so that helps beat the tradeoff

I like Go, but this is total nonsense. It does help that you can embed values in a struct, rather than using pointers. But marking everything that looks like a pointer is not efficient. Not having generations does not help.

Go is still very young, a better GC will come, just give it time. In the meanwhile, let's not pretend that the current sub-par generator is as performant as that of modern JVMs.

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

#75

Post by aaronblohowiak »

oofabz wrote: post #23
cageface wrote: post #12

Earlier quoted context omitted.

In hindsight it doesn't seem so surprising. Go really isn't a good alternative to C++ for the kinds of things that really need the low-level control and direct memory access C++ provides. And if you don't really need those things you probably should have moved on to Java or Ruby/Python/etc already. And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that w…

I write Go and I have been satisfied with the low-level control and direct memory access. The language has pointers and you can cast between ints and pointers, so you can do anything you can do in C. If you're writing realtime code, you can avoid triggering the garbage collector simply by not allocating memory on the heap. It is harder to get anything done this way, but writing realtime code in any language is diffic…

>you can do anything you can do in C

This is true only for very limited meanings of "anything"; if your point was that you had direct control of memory layout and you can use CGO for those things that C offers but go does not. For instance, the volatile keyword..

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

#76

Post by raphinou »

jonathansizz wrote: post #28
aaronblohowiak wrote: post #2

Creator of SASS and Haml now using Go for whole production system. When asked about surprising things about Go, its creators have said that they expected to recruit people from c++ communities, instead it seems to be more ruby/python people.

I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement. And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started t…

I'm very interested to know more about your use of racket in production. Could you share your experience?

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

#77

Post by aaronblohowiak »

Evbn wrote: post #57
f2f wrote: post #38

Earlier quoted context omitted.

the C code is also being run under Go's control via Cgo.

My production system is written in 100% bash and some other code run under Bash's control. :-)

if it was a 95/5% split, that might be a fair (and terrifying) thing to say.

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

#78

Post by pilif »

dkroy wrote: post #72
pilif wrote: post #46

Earlier quoted context omitted.

It's not about the shopping cart. It's about all the session data, especially for authentication. While you could use Dom storage for storing a session ID, you would have to send that through to the server with every request which you get for free with cookies. Additionally, cookies can be marked as http only or even as secure, making it very hard to lose the token by virtue of a fire sheep like, or even just XSS att…

Cookies are stored on the client just like DOM Storage, so nothing is free when it comes to requests and communicating with the server. I understand that both still have their place. Though I generally prefer to use DOM Storage for most things now depending on the use case. I also complete agree about keeping server-side session data.

with "free" I meant without additional effort for the developer.

When you set a cookie with a Set-Cookie header, the client will automatically send the cookie with all further requests.

When you put the session-ID somewhere in DOM storage, you have to manually amend all requests with that session-ID - either by appending it as a get parameter or, when you do nothing but AJAX, as an additional request header - but whatever you do, it's considerably more effort.

Also, looking at our logs, I see way more users with DOM storage disabled than with cookies disabled, but that might just be my user base.

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

#79

Post by bad_user »

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.

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

#80

Post by vorg »

jebblue wrote: 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…

> At this point, I think I'd rather program in Groovy or even go to JavaScript if I had to, than use Go. Oh...the language name sux.

Which language name were you talking about?

Post reply on HN