Friday, September 30, 2011

"Go" Smalltalk

Here's a random thought that I haven't done a lot of homework on but thought I'd throw out there. People are often looking for places that can host web sites written in Smalltalk. Lots of places will give you full access to a machine, but the places that provide a lot of infrastructure tend to restrict things to a couple of platforms.

Google's App Engine is one such platform. It provides a lot of services and scalability, and is free for up to 5 million or so page views per month, which is probably enough for many purposes. But the applications have to be written in Java, Python, or Google's own "Go" language. Go is intended as a system programming language, so presumably has good performance on low-level operations, but offers garbage collection and run-time reflection.

So it ought to be possible to write a Smalltalk VM in Go that wouldn't have the same sort of performance difficulties that you'd get trying to write one on top of, say, Java. And if the garbage collection is at all reasonable it might be possible to just delegate the GC to it instead of writing it as part of the VM. I would think it ought to be not that difficult to, say, adapt Squeak's Slang to emit Go code instead of C, or even to write a simple VM directly in Go.

There are a few difficulties. If you actually want to run on App Engine, it's a restricted environment. You can't write files, you have to use their datastore APIs for anything that persists. You're only allowed to run code in response to HTTP requests. So it's not really what Smalltalk expects, and it certainly wouldn't run the normal development environment easily. The only running code in response to HTTP requests might be an issue, though I'm not sure exactly what it means. Since this is supposed to scale automatically using Google's infrastructure, it might mean that any two requests might go to different running instances and you might get shut down once the request is done. So if you want to save any information between requests it would have to be put into some sort of data store. That's probably not so good for Seaside continuations, although it's possible to serialize processes using VisualWorks BOSS or the new Squeak/Pharo Fuel serializer. Aside: I know I saw something talking about using Fuel for this but can't find the link; this is something that BOSS has supported for many years.

Nevertheless, a Smalltalk VM in Go running on App Engine might make quite an interesting way of deploying at least some types of Smalltalk web applications with excellent scalability and free up to quite a large usage. I wonder if anyone else has thought about this or looked into how difficult it would be or how severe the limitations are in practice.

2 comments:

  1. Running Smalltalk-Applications on the AppEngine is something i'd like to do too. There are several approaches i was thinking of.
    The first and maybe the best way would be to have a smalltalk-to-java-bytecode compiler to run Smalltalk directly on the jvm. Redline could be the solution - it makes big steps but is still not production ready.
    The other approach is something i tried, discarded and now re-think: using Amber on the serverside (via jsr 223). There are several issues to be solved but it could work.
    btw: on the AppEngine there is a new mechanism called "Backends" - when running code on a backend, the state is maintained. I used that in my Amber (formerly known as JTalk) experiments, see my blog-entry: http://krecher.com/2011/06/jtalk-server-now-using-backends-on.html

    ReplyDelete
  2. The downside of using JVM bytecodes is that they haven't been particularly suitable for running Smalltalk. Maybe with invokedynamic they'd be better now but I haven't heard much about it. The interesting things about Go seemed to be the ability to do the sorts of low-level things normally done in Smalltalk VMs but still run on a restricted platform.

    ReplyDelete