Earlier quoted context omitted.
It's great http://golang.org/pkg/websocket/
Do websockets work on AppEngine(Go)?
No.
From zero to Go: launching on the Google homepage in 24 hours
31–40 of 78 posts
Re: From zero to Go: launching on the Google homepage in 24 hours
#32Maybe 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".
Well 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? :-)
I see that claim everywhere as well, and I don't understand it. Does it just mean "it has a type system that you won't hate"? There are still plenty of type declarations in that code, whereas if you ported it to OCaml they'd all be inferred.
Re: From zero to Go: launching on the Google homepage in 24 hours
#33I 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?
Short 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:…
Here'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."
Re: From zero to Go: launching on the Google homepage in 24 hours
#34Earlier quoted context omitted.
I 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.
Go runs on a single core unless you start using channels and/or threading libraries. So it should be apples-to-apples.
True, but the base http package handles each request on a different goroutine, so your requests could be handled concurrently:
http://golang.org/pkg/http/#Server.Serve
Though adgar is right, for now I believe you need to specify GOMAXPROCS to utilize multiple cores.
Re: From zero to Go: launching on the Google homepage in 24 hours
#35This 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.
Re: From zero to Go: launching on the Google homepage in 24 hours
#36I 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?
The two decades of experience we've had since the 90s, building things with exceptions, have fairly adequately demonstrated that they're not superior to return codes, despite their (apparent) theoretical advantages.
Re: From zero to Go: launching on the Google homepage in 24 hours
#37I 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 All requests in less than 66 ms, mean less than 19 ms.
AppEngine 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…
This isn't true any more. They recently announced faster frontend instances with more memory (http://googleappengine.blogspot.com/2011/12/app-engine-161-r...), and I'm willing to bet this has been available internally since long before Thanksgiving.
I'd bet money that this app used the beefiest class of frontend instances.
Re: From zero to Go: launching on the Google homepage in 24 hours
#38Earlier quoted context omitted.
Well 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? :-)
I see that claim everywhere as well, and I don't understand it. Does it just mean "it has a type system that you won't hate"? There are still plenty of type declarations in that code, whereas if you ported it to OCaml they'd all be inferred.
Yes, basically. As far as I can tell Go is entirely about getting rid of unnecessary cruft and boilerplate and making a practical language you won't hate working in. Inasmuch as most interpreted languages are intended to be practical languages you won't hate working in, they are similar to Go.
As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-typed, and so is Go. When you code in an interpreted languages you expect arguments to functions to be of a certain type, where type just means "responds appropriately to methods I call on it". In Go, interfaces are just method specifications and any type that has appropriate methods satisfies the interface. For example, you might have an argument "input" of type "io.Reader"[1] to a function. All this really means is that you expect to be able to call "input.Read()" to populate a byte slice. As a result the implicit type guarantees you expect from an interpreted language and the explicit type guarantees you get from Go are basically the same.
Re: From zero to Go: launching on the Google homepage in 24 hours
#39Is 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.
The variable "p" is a rune. Although the rune type can have negative values, p will only have values >= 0 in this code.
How so? If the character is any value less than '0' (say, '!'), p will be set to a negative value.
Re: From zero to Go: launching on the Google homepage in 24 hours
#40Earlier quoted context omitted.
The variable "p" is a rune. Although the rune type can have negative values, p will only have values >= 0 in this code.
How so? If the character is any value less than '0' (say, '!'), p will be set to a negative value.
'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
All characters have values greater than or equal to zero.