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.
And faster doesn't always mean better or more desirable.
> However, from wikipedia: "Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic." For many people (including me) the lack of all this "features" is a feature in itself. I certainly have not missed any of them.
You don't miss generics? In my limited time working with Go, the lack of generics felt like a glaring hole in the language. That said, maybe that feeling goes away as you spend more time with Go, and perhaps learn to program it more idiomatically.
Go has generics, but only for the built-in chan, map, and slice types (and the associated operators). Since the majority of uses of generics (at least in my code) are from containers, this results in me not really feeling the lack too much. Interfaces and reflection cover most of the rest, though not ideally. After using Go for a while, I'm not yet sure if the lack of user-defined generics are a bug or a feature. It limits your expressive power a bit, yes, but it also makes the world so much simpler.
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.
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…
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.
None of that is available on the GAE, though (you cannot use custom C extensions on GAE, which includes 3rd party tools like numpy).
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
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... I am a node fan, I…
But with Go can you write your client code and your server code in the same language?
Sorry, this was actually a tongue-in-cheek comment. :)
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 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.
GvR mentioned today at Google I/O that the Go runtime was championed by another group within Google. Apparently, the same thing happened with the Java runtime before it was brought into the App Engine team. He expected the same thing to happen with the Go runtime. So one would expect new features to come to the Go runtime slightly after the other "first class" runtimes (Python and Java).
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.
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.
> However, from wikipedia: "Of features found in C++ or Java, Go does not include type inheritance, generic programming, assertions, method overloading, or pointer arithmetic." For many people (including me) the lack of all this "features" is a feature in itself. I certainly have not missed any of them.
You don't miss generics? In my limited time working with Go, the lack of generics felt like a glaring hole in the language. That said, maybe that feeling goes away as you spend more time with Go, and perhaps learn to program it more idiomatically.
Between interfaces and the builtin generic types, I have never missed generics (specially since append() was added to the language), and that seems to be the experience of most people that have used Go for a while.
Still it probably would be nice to have them some day, but it is worth doing right and not worth sacrificing the current simplicity and elegance of the language.
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.
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 chang…
Same in Java, C# and Python. To get the codepoints out or access the nth codepoint you need to iterate over the string if you want your code to be correct and safe.