Can anyone confirm if this allows linking native libraries? From the looks of the "compiler", it seems it might be hacked to produce a binary statically linked against, say, SpiderMonkey. Beyond coolness, it seems a waste of effort to tailor this release to Go, when similar effort might have been expended, e.g. to define a simple protocol talked over a UNIX fd that any static x86 binary could implement to integrate w…
Google App Engine for Go
21–30 of 73 posts
Re: Google App Engine for Go
#22http://code.google.com/p/googleappengine/issues/detail?id=23...
Re: Google App Engine for Go
#23It looks like this is still going to be limited to HTTP (port 80) web applications. So you won't be able to run a process like Doozer that communicates with other ports/protocols. EDIT: More details from the docs at http://code.google.com/appengine/docs/go/runtime.html An App Engine application cannot: -write to the filesystem. Applications must use the App Engine datastore for storing persistent data. Reading from t…
Re: Google App Engine for Go
#24It looks like this is still going to be limited to HTTP (port 80) web applications. So you won't be able to run a process like Doozer that communicates with other ports/protocols. EDIT: More details from the docs at http://code.google.com/appengine/docs/go/runtime.html An App Engine application cannot: -write to the filesystem. Applications must use the App Engine datastore for storing persistent data. Reading from t…
With the announcement of backends ( http://googleappengine.blogspot.com/2011/05/app-engine-150-r... ), I suspect long-running processes will be available in Go in the future as well.
Re: Google App Engine for Go
#25Any advantage (performance? memory use?) for using Go vs. Python? Or is just programming language preference?
I've been enjoying using Go as a C replacement when I need more performance than Python, but don't actually need to use C. It's been fine for that purpose. I would note that they do keep changing the syntax on a fairly regular basis, the libraries are still young, and I do find the language oddly unexpressive in places compared to even C++ with boost. (E.g., no ternary operator, no list comprehensions, using the same…
"Google has people who administer apps and services, and they need to, say, write tools that say scrape a few thousand machines statuses and aggregate the data," he says. "Previously, these operations people would write these in Python, but they're finding that Go is much faster in terms of performance and time to actually write the code."
Clever marketing or could Google's problems actually be handled better by Go than Python, in time to code?
Re: Google App Engine for Go
#26Earlier quoted context omitted.
Faster than Python, better memory use for many types of programs. Compared to Java, less memory use and (I assume) much less start-up time, since no VM is needed. Also, since you can use goroutines, it would seem like you'd be able to do concurrent requests without having to have a special async API like Java/Python have. Go seems like it'll be a pretty great fit for App Engine.
Faster than CPython maybe, last time someone did a benchmark of Go vs. Python webservers PyPy came out on top.
I assumed that you're talking about http://ziutek.github.com/web_bench/, but that makes no mention of PyPy (other than a HN comment that PyPy takes 2x the memory) and Go comes out on top in that benchmark.
Either way, when saying Go is faster, I wasn't talking specifically about it's http library or io system (I assume both are similar in speed to Pythons). I more meant that if you're going to be writing custom CPU-intensive code to run on App Engine, assuming the same algorithm, Go should be faster. It has better constant factors, and it gives you better control over allocation.
I don't know PyPy well enough to say in what situations it outperforms Go (especially considering that I don't know what kind of VM warm-up you can expect on App Engine), but since GAE doesn't run PyPy, it's not relevant to the discussion of Python v Go on App Engine.
Re: Google App Engine for Go
#27Earlier quoted context omitted.
Faster than CPython maybe, last time someone did a benchmark of Go vs. Python webservers PyPy came out on top.
I'd be interested in a link to that benchmark if you have it. I assumed that you're talking about http://ziutek.github.com/web_bench/ , but that makes no mention of PyPy (other than a HN comment that PyPy takes 2x the memory) and Go comes out on top in that benchmark. Either way, when saying Go is faster, I wasn't talking specifically about it's http library or io system (I assume both are similar in speed to Pythons…
Re: Google App Engine for Go
#28Re: Google App Engine for Go
#29IMHO, Google could be riding a much bigger wave right now...
Re: Google App Engine for Go
#30Earlier quoted context omitted.
I've been enjoying using Go as a C replacement when I need more performance than Python, but don't actually need to use C. It's been fine for that purpose. I would note that they do keep changing the syntax on a fairly regular basis, the libraries are still young, and I do find the language oddly unexpressive in places compared to even C++ with boost. (E.g., no ternary operator, no list comprehensions, using the same…
Pretty interesting. What do you think of the quote from this article http://news.ycombinator.com/item?id=2518609 http://www.theregister.co.uk/2011/05/05/google_go/print.html "Google has people who administer apps and services, and they need to, say, write tools that say scrape a few thousand machines statuses and aggregate the data," he says. "Previously, these operations people would write these in Python, but they'…
Google has many custom components, though. I personally don't write Go nearly as quickly as I write Python, but I have 4+ years of writing Python in everything from tiny scripts up to large applications, both for the desktop and for the web. I have maybe twenty to forty hours of experience writing Go code, absolute tops. It's not a fair comparison. If we assume that the Googlers who are claiming to be more productive in Go than Python have a couple orders of magnitude on me, and that they don't need many prefabricated libraries, and I find the claim plausible.
I don't believe it'd currently be true in the general case, though.