
Google App Engine for Go - odovdor
http://code.google.com/appengine/docs/go/overview.html
======
bgentry
It 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 the filesystem is allowed, and all application files uploaded with the application are available.

-open a socket or access another host directly. An application can use the App Engine URL fetch service to make HTTP and HTTPS requests to other hosts on ports 80 and 443, respectively._

~~~
dchest
With the announcement of backends
([http://googleappengine.blogspot.com/2011/05/app-
engine-150-r...](http://googleappengine.blogspot.com/2011/05/app-
engine-150-release.html)), I suspect long-running processes will be available
in Go in the future as well.

~~~
bgentry
Thanks for the info, didn't realize they launched this feature as well. I
doubt it will take them long to bring it to Go.

------
zmmmmm
This seems like a pretty big step to me: so far Go has seemed like a kind of
geeky side project of Google's. But here they are promoting it into one of
their production services.

Makes me wonder if they are preparing to slowly edge Java out the door and
replace it with something equally performant but not burdened by a hostile
owner.

~~~
rkalla
I think you nailed it. Consider they picked up Gosling for r&d I don't put
championing their own future platform for all devices (you know Go is going to
Android as part of the NDK or something by Android 4).

Isn't this what Sun basically did with Java? I don't know the incumbent they
were trying to edge out or if it was just a "look at our cool tech" play.

Go seems like a C-esque version of python/ruby/java to me. A lot of very slick
things in there. Lots of room to grow and a lot of community excitement.

------
enneff
The official blog post: <http://blog.golang.org/2011/05/go-and-google-app-
engine.html>

And Hacker News thread: <http://news.ycombinator.com/item?id=2533000>

~~~
kristianp
According to the blog post, deployment to app engine will only be available
initially to those who sign up as a trusted tester via this form:
[https://spreadsheets.google.com/spreadsheet/viewform?formkey...](https://spreadsheets.google.com/spreadsheet/viewform?formkey=dGJ6LXlIYWk4MjhnM0dubUstUHFKVXc6MQ&ndplr=1)

------
fortes
Any advantage (performance? memory use?) for using Go vs. Python? Or is just
programming language preference?

~~~
gecko
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 word for all loop variants,
and so on.) That said, if you're using it as a C replacement, rather than a
Python replacement, I think those are fine trade-offs.

~~~
true_religion
Have you looked into other Python performance solutions like Cython which lets
you add type declarations to Python code, and compile it into a C/C++ module?

In my tests, it produces speedups on numerics that put it within spitting
distance of hand-tuned C.

~~~
gecko
Oh, no question. That's part of why Mercurial is so close to Git in terms of
speed, despite Git being hyper-optimized C and Mercurial being Python. But so
far, this has always come up when I'm doing one-off, or nearly one-off, stuff.
Getting CPython extensions whipped up is more effort, and less fun, than
writing the solution in Go.

------
forgotusername
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
with App Engine.

~~~
enneff
There's a lot more than sandboxing to rolling a good App Engine SDK. A large
amount of effort went into designing nice, idiomatic Go APIs for accessing the
App Engine services.

------
chrisfarms
State my assumptions: GAE allows you to deploy multiple versions of your app
and access the same datastore. Go should significantly out perform Python for
certain CPU intensive tasks.

...

If Backends are available at _versioned_ URLs too (and I suspect they
do/willdo) then there might be nice opportunities to build little Go Backends
to do heavy lifting within your main Python applications. Sounds cool.

------
chuhnk
Go appears to be gain more and more traction. I wonder how long before someone
else supports it on their platform.

------
Kilimanjaro
Great news! I'll start playing with it right away.

I won't drop Python for my day to day coding, but having Go as an option is
good to see what cool toys we can build.

------
euroclydon
Go's a System language. Doesn't that mean it's more suitable for writing a web
server, database, driver or OS than as a web site scripting language?

I mean, no one would write System code in PHP, and it's rare to see web sites
written in C, so why write a website in Go?

~~~
leon_
Go turned out to be a pretty nice general purpose language. You got garbage
collection, sane native string handling, native maps and lists. Mix that with
static typing and you got a pretty nice language that enables fast and sane
web development.

~~~
lars512
Having done a lot of CJK development, I felt that Go's unicode strings were
pretty kludgey last time I looked. Go's strings are all utf8, so unless you're
working in its ASCII subset alone, you have to manually iterate over multi-
byte runes to get the unicode codepoints out. That's really not what I'd call
a friendly unicode handling comparable to scripting languages, or even Java.

Please correct if things have changed. I haven't revisited Go for a little
while now, and would be very interested as to any updates to its unicode
handling.

~~~
dchest
1\. Range on a string iterates over Unicode code points (runes):

    
    
        s := "Какая-то строка"
        for _, rune := range s {
            // do something with rune 'К', 'a', ...
        }
    
    

2\. Converting to []int gives you a slice of runes:

    
    
       s := "Какая-то строка"
       runes := []int(s)
    
       sub := string(runes[:8]) // "Какая-то"
    

however, slicing a string directly will slice it by byte:

    
    
       s[:8] // "Кака"
    
    

3\. With package utf8 (<http://golang.org/pkg/utf8/>) you can manipulate runes
manually.

While this is all not intuitive (you have to know what does what), I find it
rather easy.

------
jordinl
What's the best way to get started with Google Go?

~~~
dchest
Start from the left column (Learning Go): <http://golang.org/doc/docs.html>
and continue to the bottom.

Watch "Practical Go Programming": <http://osdc.blip.tv/file/4432146/>

Watch "Writing Go Packages":
<http://www.youtube.com/gocoding#p/u/0/jDWBJOXs_iI>

Read language specification.

Edit: If you prefer books, here's a CC-licensed, still in development, book by
Miek Gieben "Learning Go": <http://www.miek.nl/files/go/> (grab the latest
PDF; alternatively, here's Git repo: <http://miek.nl/cgi-
bin/gitweb.cgi?p=gobook.git;a=summary>)

------
wwkeyboard
Nice of them to even mark the issue fixed!

[http://code.google.com/p/googleappengine/issues/detail?id=23...](http://code.google.com/p/googleappengine/issues/detail?id=2382)

------
xtfunlp
It's about time! i always wondered why google left out Go! for the app engine
last time i was there, since it's their language and stuff. Tough i guess it's
ruby next? yeah probably not...

------
MatthewPhillips
Can't wait to toss Eclipse into the trash!

------
arturadib
It's going to be a tough sale for Google to convince people to adopt Go for
their web apps when Node.js is taking over that scene. With Node I get the
best of two worlds: high concurrency and speed -- presumably the top two
selling points for using Go with web apps -- without having to teach myself
yet another programming paradigm. Everyone and their mother knows some
Javascript; good luck hiring help for your Go-based startup.

IMHO, Google could be riding a much bigger wave right now...

~~~
bjg
While I agree that go on appengine might not take off, in no way is node.js
"taking over that scene". If by scene you mean the "web app" scene. Just
because node.js articles are constantly blowing up hn, reddit does not
necessarily correspond to real world deployments of node.js apps.

An admittedly hastily prepared google trends graph:
[http://www.google.com/trends?q=node.js%2C+python+django%2C+r...](http://www.google.com/trends?q=node.js%2C+python+django%2C+ruby+on+rails%2C+gwt%2C+appengine&ctab=0&geo=all&date=all&sort=1)

I am a node fan, I subscribe to the node-dev list and have worked on a few
applications my self. However I am in no way delusional about the current blog
popularity vs actual projects deploying with it.

Also you state that you are able to gain the same concurrency and speed with
node that you are with Go. May I ask how you achieve this? Go usually
comparable to C code in terms of performance [1]. Go also has amazing
concurrency tools for efficient communication between two concurrent
goroutines, for example the channel interface[2]. To my knowledge their is no
way to run concurrent node processes. You can launch multiple instances of the
same program but their is no way to let them communicate without sending data
over a socket. You can of course use a reverse proxy to present a single entry
point in which multiple node backends can take requests. However you can not
claim this as concurrency in the same sense that is available with go.

[1] <http://golang.org/doc/go_faq.html#Performance>

[2] <http://golang.org/doc/effective_go.html#concurrency>

~~~
robfig
But with Go can you write your client code and your server code in the same
language?

~~~
KirinDave
People keep touting this, but the actual number of cases where you really want
this is actually pretty limited.

~~~
rjurney
With robust server-side javascript... its not hard to see the application of
this. It is easier to generate executable javascript for the client on the
server in javascript itself. Certainly in Web2+ you want this for increasingly
dynamic behavior?

~~~
KirinDave
I do want more dynamism, but I don't see why you should be passing and
executing arbitrary code from a source you can only verify with the greatest
of difficulty. And having executable code be your communications protocol
seems like an absolute nightmare if anything goes wrong. Hell, just versioning
it will be hard. It might work for some simple demo apps, but I seriously
question the wisdom of such an approach with a team who's size is >1.

Why not pass Json, and write your client code. It's not like Node is so
expressive that it's a big win on server side code (especially with the flood
of great altjvm & altclr languages these days).

