An overview:

Pure OO

Io, Python and Ruby are pure OO languages (like Smalltalk), the others are not pure OO languages as they have non-object types. Io is a bit more pure as even assignment and locals accesses are messages. In the case of Lua, it is a language in which objects can be easily implemented but are not built in.

Simplicity

Io unifies a number of ideas that appear as separate constructs in other languages.

• objects, classes, name spaces and locals (into prototypes)
• functions, methods, lambdas and anonynomous functions (into blocks with assignable scope)
• operators, method calls, assignment and variable accesses (into messages)
• threads, locks and objects (into actors)

Syntax

In terms of simplicity and consistency of syntax, I'd (subjectively) rate them from simplest to most complex as follows: Io, Lua, Python, Ruby, Java, Perl. Io's syntax has no keywords and is composed of messages that have 3 forms.

Object Model

Io uses a prototype-based object model. Python, Perl, Ruby and Java use a class-based object model. Either can be easily implemented in Lua, but Lua has no built-in object model. Class based languages in general are less flexible as method changes to objects can usually only happen at the class level, inheritance is static, etc.

Flexibility

Io has greater introspection capabilities and dynamic features (such as runtime modification of code, namespaces, inheritance, etc). In Io and Ruby, operators are syntactic sugar for messages, so they can be easily redefined.

Size

Io and Lua are significantly smaller than the others. See size comparison.

Memory Management

Io uses an incremental (tri-color, write barrier) garbage collector which is similar to a mark and sweep collector but without the pauses. Perl uses reference counting collectors which leak memory if there are reference cycles. Python also uses reference counting but with a cycle detector. Ruby uses a mark and sweep collector which can cause disruptive pauses when the collector runs. Different Java VM implementations use different collectors but most seem to use generational copying collectors which may use more memory (for copying space) and also suffer from pauses, though they are less frequent. Btw, copying collectors were thought to solve the problem of memory fragmentation but more recent research has shown that fragmentation is not a problem when using a good allocator such as dlmalloc (which is used on most platforms).

Concurrency

Python, Perl and Java use OS threads for concurrency. OS threads are heavy weight and not suitable for high performance servers. Ruby and Lua use internal stack manipulation to implement user level threads. These are light weight but difficult to use with C bindings. Io uses C stack manipulation to implement user level threads which is both light weight and and easy to use with C although less portable than Lua/Ruby style threads.

Bindings

Unlike Lua and Ruby, Io is tightly integrated with the C stack which makes bindings easier to write and allows bindings to call back into the VM. Also, Io's bindings are object-oriented which isn't the case for Lua and Python and I don't think it is for Perl.

Scoping

Io's default scope is local and "globals" are found by inheritance/delegation (which makes it easy to implement sandboxes). Lua's default scope (for variable assignment) is global. In Python, global variables are declared. Ruby has special operator characters in front of variables to specify the scope.

Embedding

Io and Lua are (both) well suited for embedding. The others can be embedded, but don't lend themselves to it. When I say well suited I mean: Io has no static variables, can run multiple VMs in the same process (and safely with a OS thread per VM), has hooks for standard output and errors, doesn't depend on shared libraries or environment variables and builds an embeddable static lib by default.

Typing

All are dynamically typed except Java which is statically (uses type declarations) typed (this makes Java less flexible in terms of being able to quickly add features to existing code).

Introspection

All offer some level of introspection (Java the least) but Io is unique in that methods/blocks are composed of objects that can be inspected and modified at runtime.

How production stable is it?

It hasn't been terribly well tested and isn't being used in any production environments that I know of. Please help us by testing things out! I generally release fixes to any bugs found in a matter of days. The up side of Io being young language (born in April 2002) is that your help and input can have a significant effect on it's future.

Will there be any major changes in the semantics or syntax anytime soon?

I'm still open to that possibility, but require such changes to make things significantly simpler and/or much easier to use.

Is the Server version capable of supporting multithreaded web applications? That is, is it possible to write 'Io Server Pages' in a multithreaded non-cgi way in which one VM handles multiple requests simultaniously like PHP or a Servlet-Engine?

Yes, with coroutines. They are essentially the same as normal threads but you have to call "yield" to allow other threads to continue. The benefits of coroutines are:

• much more CPU and memory efficient - good for high performance servers
  Example: comparison of a coroutine based web server vs. Apache
  Note: Io uses asynchronous sockets "under the hood" to avoid blocking issues.
• avoids most synchronization/locking issues
• more portable

Note that you may need to increase the limit on the number of open file descriptors per process to take full advantage of a high performance Io server. Here's some info on doing this on linux. Most unixes support a system call that can set this limit for the process. Here's some more info on this.

Do you have more documentation than the manual.html? How do I write 'addon' libraries?

There is also an ImplementationNotes.html in the IoVM/_docs folder. I haven't written much on bindings yet, but they're pretty easy to write. You might try copying the Directory add-on in the IoServer folder and modifying it to your own needs. It's a good example of a simple binding.

Why not use an infix message syntax like Smalltalk?

A few reasons:

Simplicity and Consistency
Ideally, the same syntax should be used for defining everything - methods, blocks, objects, control structures, etc. Infix syntax runs into difficulties here. Which is why Smalltalk ended up with different syntaxes for many of these things.
Clarity
Infix leads to the use of arbitrary parse rules. For example:
a b:c d:e
Is this to be understood as:
a b:(c d:(e))
or:
a b:(c) d:(e)
or:
a b:d:(c, e)
Smalltalk has rules to deal with this ambiguity, but the beginner won't know these rules. Also, it seems less than ideal to burden the developer with such rules. One solution is to use Objective-C style infix format where brackets always denote the boundaries of a message:
[a b:[c d:e]];
But this is verbose and it's a pain to have to predict the number of brackets you'll need when you start writing a line. Also, it doesn't feel right for Io's semantics of each message applying to the return value of the last.
Variable arguments
Infix has issues with variable arguments. The ":"s in Smalltalk are part of the message name, for example. Even if ":"s were not included in the message names, then would be other problems. For example:
a b:1 c:2
and:
a bc:1
would invoke the same method - while they look like different ones.

Why use a CamelCase naming convention instead of underscore_separated compounds?

Personal preference.

Would it be possible to run Io on a Java VM or .Net?

Yes, but I would guess it would involve reimplementing the Io VM in Java or .Net instead of directly converting Io code to byte codes. Io does many dynamic things which I doubt are possible to do at a low level in either of those. It's also worth asking why one would want to considering that Io is already implemented in C, which is supported on far more systems than Java or .Net.

Is there a syntax highligher for Io?

Several can be found in the source distribution folder Io/projects/SyntaxHighlighters. Contributions of more highlighters or improvements to these are welcome.

Why don't you use [my favorite source control management software]?

We use git because it's simple, reliable, distributed and fast. If you know of a better scm that supports this model and these features, we'd like to hear about it.

Why the name 'Io'?

A simple name to reflect the goal of a simple language.

Wasn't there another language named 'Io'?

When I chose the name Io, I searched the net and wasn't able to find any mention of a programming language with that name. Long after the public release, someone mentioned it and I was only able to find one reference to it in a book review on Amazon. The earlier Io turned out to be an interesting language based on continuations and written by Raph Levien. Since then, Martin Sandin has written an implementation of Raph's language called Amalthea. My apologies for any confusion.

What is the proper pronunciation and capitalization of 'Io'?

Io is pronounced "eye-oh".
When written, the "I" is capitalized and the "o" is lowercase.
As a file suffix, both letters are lowercase. For example: "test.io".

How can I help?

Testing, suggestions and participation in the mailing list are a big help.
If you'd like to get even more involved, you might drop by the Io irc channel and ask if there's something that needs to be done that you'd enjoy working on.