9 ms·
From zero to Go: launching on the Google homepage in 24 hours
- cma 15y ago
- freakinjoe 15y agoDo consider the virtualization and resource sharing on GAE's server and google main page's views.
- adamio 15y agoTransistor density doesn't guarantee performance increase. Is AppEngine's ability to scale and maintain <60ms consistent with Moore?
- dextorious 15y agoThe AppEngine is not about transistor density, it's about share-nothing and scaling by adding cpus.
- BarkMore 15y agoThere's insufficient data to draw conclusions about the performance of the infrastructure. The application probably ran on a shared machine. We don't know the impact of the other processes running on the machine. We don't know how many requests the application handled in parallel, so we cannot divide by latency to get throughput. We don't know if the application ran on a modern machine.
- danielrhodes 15y agoThis was interesting because I've never seen Go used in production yet. However, the solution is not optimal for performance (as his benchmarking suggests is one of the goals). If there is a finite number of possible images and each image takes CPU time to generate, then why not lazy cache the images in a CDN after generating them once?
- cma 15y agoThe more complicated something is, the more chances for failure there are. Remember, this was only for compositing the image that would be shared to google plus -- the one in the browser is done client-side.
- enneff 15y agoThis works exactly as you describe - the app sets a cache header on the response and Google's geographically distributed front end servers will serve the cached response. You get all this for free by using App Engine.
- luriel 15y agoThere are quite a few people using Go in production already, see: http://go-lang.cat-v.org/organizations-using-go http://go-lang.cat-v.org/organizations-using-go
- curiouskat 15y agoHow is Go's websocket support? I have been thinking Go might be a good choice for a websocket proxy, like node.js is used in Juggernaut (http://flask.pocoo.org/snippets/80/ http://flask.pocoo.org/snippets/80/).
- biot 15y agoI'm curious to know how many instances were required and what the cost would have been had someone been billed for it.
- nickik 15y agoMaybe its just me but all blogpost about go read like they where checked by a marketing guru after the have been written. The always enforce the same basic points, it always sound the same. If I somebody says "go" my mind alwasys jumps to "feels like a interpreted language".
- enneff 15y agoWell I'm the guy who runs that particular blog, and I can tell you I'm no marketing guru. While Reinaldo and I edited the post together, I'm pretty sure that the line was in his original text. (Just checked: it was.) Maybe people keep saying Go feels like an interpreted language because it feels like an interpreted language? :-)
- jbarham 15y agoI've done a fair bit of Go programming (https://github.com/jbarham https://github.com/jbarham), but have programmed professionally mostly in Python for the past 10 years, and for me Go does feel an interpreted language because it requires so few type declarations compared to mainstream statically typed languages like C++ or Java. Checking the app source code for the article at http://code.google.com/p/go-thanksgiving/source/browse/app/app.go http://code.google.com/p/go-thanksgiving/source/browse/app/a..., the only type declaration I can see in the body of a function is in a type switch where it obviously makes sense. Otherwise the code uses the combined declaration and assignment := operator (http://golang.org/doc/go_spec.html#Short_variable_declarations http://golang.org/doc/go_spec.html#Short_variable_declaratio...) which is type-safe because it infers the types from the value(s) on the right hand side. IMO this is even better than working w/ a dynamically typed language like Python because the required parameter type declarations in the function declaration tell you the types you're dealing with, but unlike C++ or Java you don't have to repeat that information back to the compiler.
- alexchamberlain 15y agoC++11 has support for inferring types; http://en.wikipedia.org/wiki/C%2B%2B11#Type_inference http://en.wikipedia.org/wiki/C%2B%2B11#Type_inference.
- comex 15y agoIs Go's character type signed? If so, it's possible to make p negative, in which case this wouldn't apply: if p >= len(em) { panic(fmt.Sprintf("element index out of range %s: "+ "%d >= %d", t, p, len(em))) } although Go would still do its own runtime check for the dereference.
- BarkMore 15y agoThe variable "p" is a rune. Although the rune type can have negative values, p will only have values >= 0 in this code.
- comex 15y agoHow so? If the character is any value less than '0' (say, '!'), p will be set to a negative value.
- BarkMore 15y ago'0' has the decimal value 48, not zero. '!' has the decimal value 33. Here's a demo program that you can run from your browser: http://play.golang.org/p/qAKG9j5E4V http://play.golang.org/p/qAKG9j5E4V All characters have values greater than or equal to zero.
- Dylan16807 15y agocomex said less than '0'. 33 minus 48 is negative.
- yesbabyyes 15y agoI really liked the turkey, and I thought the solution looked elegant, so I had a go at it in CoffeeScript and node-canvas: https://gist.github.com/1475034 https://gist.github.com/1475034 All requests in less than 66 ms, mean less than 19 ms.
- jphackworth 15y agoTo be fair, you loadtested with ab, whereas the author launched his feature on the Google homepage.
- yesbabyyes 15y agoSadly I don't have the opportunity. :-)
- ariwilson 15y agoAppEngine instances, unless they're running in a special backend instance, exist in a special containerized machine. These machines are very slow and don't have much RAM - 600 MHz and 128 MB. Based on the source that was posted on the blog, this app was running on a normal instance, as the source did not contain a backends.yaml file. So it makes sense that a Core 2 Duo running at 2.13 GHz and slow CoffeeScript would be ~2x as fast. My personal experience of running Go code locally (on a Core i5 2500K) versus on a normal AppEngine instance showed a slowdown of around 6x or more.
- yesbabyyes 15y agoI can't argue with that, though I'm running this on just one core (single process). If I was better with the v8 profiler I would check to see how much time it spends in JS land vs C, since node-canvas is all C, as well as the http parser.
- ariwilson 15y agoGo runs on a single core unless you start using channels and/or threading libraries. So it should be apples-to-apples.
- billmcneale 15y agoI can't help but cringe whenever I read Go code because the following: paths, err := filepath.Glob(dir + "/*.png") if err != nil { panic(err) } is repeated over and over again. Didn't we learn in the 90's that exceptions are far, far superior to return codes?
- ariwilson 15y agoThere are some real trade-offs with using exceptions, as per http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... . However, as Go is garbage collected, some of these trade-offs don't apply.
- deleted 15y ago[deleted]
- timtadh 15y agoShort answer no. Long answer, the Go authors (Rob Pike et all) have a pedantic issue with exceptions as implemented in Python, Java, etc. They feel they conflate errors and exceptions. Errors, unlike exceptions, are an expected part of the programming process. Exceptions, on the other hand should be for exceptional circumstances. I did not say that as well as they do so see what Pike has to say about the issue here: http://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4 http://groups.google.com/group/golang-nuts/browse_thread/thr... here is an a typical example of the Go community's attitude: """ I _especially_ don't want exceptions to become an oft-used alternative to multiple levels of error return, as at that point they deteriorate to action at a distance and make understanding large code bases much harder. Been there, done that, got the scars to prove it. (Mostly from C++ and not from Java, but I've seen enough Java to have a healthy fear of runtime exceptions.) """ -- Giles Lean
- zmj 15y agoHere's a good Rob Pike quote from later on in the thread: "This is exactly the kind of thing the proposal tries to avoid. Panic and recover are not an exception mechanism as usually defined because the usual approach, which ties exceptions to a control structure, encourages fine-grained exception handling that makes code unreadable in practice. There really is a difference between an error and what we call a panic, and we want that difference to matter. Consider Java, in which opening a file can throw an exception. In my experience few things are less exceptional than failing to open a file, and requiring me to write inside-out code to handle such a quotidian operation feels like a Procrustean imposition. Our proposal instead ties the handling to a function - a dying function - and thereby, deliberately, makes it harder to use. We want you think of panics as, well, panics! They are rare events that very few functions should ever need to think about. If you want to protect your code, one or two recover calls should do it for the whole program. If you're already worrying about discriminating different kinds of panics, you've lost sight of the ball."
- ars 15y agoThis is quite offtopic, but if even programmers are using jpeg when they should use png, what hope is there for anyone else? The images this generates have mostly flat areas of all one color - it should have been a png.
- bostonvaulter2 15y agoWould the size of the png's be smaller?
- enneff 15y agoWe chose JPEG because the files were smaller and the encoding faster. The images looked fine in either case.
- deleted 15y ago[deleted]
- JabavuAdams 15y agoI'm working on a game with highly-stylized art that includes a lot of blobs of single colour. It surprised me at first, but the artists have had real gains using JPG instead of PNG. Also, strangely the artifacts give the art a kind of "texturized" finish that's actually kind of pleasant on tablet screens.
- canop_fr 15y agoMaybe it's for performance reasons. I have a web server in go that generate (big) png on the fly and most of the time is spent in the png encoding (mostly the compression). PNG encoding is a heavy task. Here's (from my blog) a pprof profile of my server : http://canop.org/pub/pprof4353.0.svg http://canop.org/pub/pprof4353.0.svg so that you can see the burden. (I didn't make comparisons with other languages so I don't know if Go's png encoder is fast or not, I suspect it isn't)
- liruqi 15y agothe link is broken. something wrong with golang blog?
- obtu 15y agoGreat Firewall?
- wallunit 15y agoThe pirate easter egg [1] seems not to work [2]. [1] http://news.ycombinator.com/item?id=3351407 http://news.ycombinator.com/item?id=3351407 [2] http://google-turkey.appspot.com/thumb/295552a0 http://google-turkey.appspot.com/thumb/295552a0
- anacrolix 15y agoNice try, Pike.