Python

Delight's main advantages over Python are that it is faster and has lower overheads, and has static type checking.

PyRex, Pycho and PyPy all try to make Python faster by converting it to native code in some way. However, I found that when writing PyRex programs the only way to get good speed was to keep looking at the generated C code and thinking "What PyRex code could I write to make it generate the C I want?". It's very good for connecting C and Python code, though. PyPy compiles Python to native code, but still has to support most Python features, which limits what it can do. Pycho is very cool, but doesn't work on x86_64. It optimises code as it runs by looking at the input types and generating code specifically to handle those types.

For the most part, Python's lack of static checking isn't a big problem. You need to unit-test your code, and if it passes the testing then the types are probably right. However, I find I often have problems in error handling code for Python (since that rarely gets tested) and in GUI code (which is hard to test).

Pychecker, Pylint and Pyflakes can all help here, but the dynamic nature of Python means that they can, at best, print warnings.

Finally, having types on function arguments and return values is useful documentation, and the not-null types may also be useful.

Java

Compared to Java, you lose the byte-code verifier and the dynamic class loading. Checked exceptions, now widely regarded as a failed experiment, are replaced by the non-null type checking which is hopefully more useful.

You also get some features which are strangely lacking from Java, such as properties (where foo.x = 3 can invoke a setter method automatically). Also, having a built-in logging system avoids the Log4j / Java Logging / Commons Logging nightmare.

D

Most things in D have a direct equivalent in Delight. Internally, Delight and D parse down to the same code. You can import D modules from Delight code, and even instantiate D templates! There are some issues with non-null types to watch out for when mixing code, however.

Things that are in D but not in Delight:

• Labels (and, therefore, the goto statement). This is easy to bring back if required, though an alternative syntax will be needed as colon is used to start a block.
• Global state is not available by default.

The main things that are in Delight but not D.

• Dependency injection syntax (in fields).
• Non-null types.
• Built-in logging.

E

Like Delight, E only allows objects to communicate with other objects to which they have been given access explicitly. However, E goes much further than Delight; where Delight encourages this style of programming, E enforces it. E is also designed for secure distributed computing, and has a wonderful "promise-pipelining" architecture for dealing with network latency.

E's main downsides are that it is currently much slower than Delight (the default implementation is built on Java, though others are available) and lacks a good static type system (not unreasonable, given its distributed nature). It is, of course, much more mature than Delight.

Boo

Boo is similar kind of thing for .NET. Looks very nice, and much more mature than Delight.

Nice

Nice is where I first saw the maybe-null type annotations. It had a lot of other good ideas too (many of which are now part of Java).

Genie and Vala

Genie and Vala are languages for writing GNOME applications. They are convert source to C code and then compile that using a normal C compiler. They both integrate well with GObject; Delight has a GObject linkage type (see the GTK page).