I didn't know it. But according the introduction in its website, the differences are very easy to spot on: the syntax is obviously different; Stanza compiles directly to native code, but Dao doesn't; Dao supports class and inheritance, but Stanza not; concurrency support is also different. The main similarity seems to be both having optional typing.
A. Is the language stable/mature enough for production use?
B. Do the concurrent features allow shared memory parallelism?
I currently use Lua if I need an embedded scripting language for a personal project and the one thing that annoys me is that Lua cannot utilize multiple cores effectively.
> A. Is the language stable/mature enough for production use?
The language is stable now in terms of features, there will be no more significant changes in the language in the forseeable future. However, the document on the website is a bit outdated, I will update it in the coming days.
As for the implementation, I cannot say for sure, but I believe it is sufficient stable now. My colleagues and I have been using Dao to develop commercial product prototype in the past half year, the only tricky problems we experienced had something to do with the wrapping of a game engine. All (no many actually) other problems are quite trivial. After solving the problems related to the wrapping, the product prototype has been working quite smoothly.
However, our use may not have covered all the features of Dao, so there could be some parts less stable than the parts we have been using. But since we are actually using Dao in real products, we are obviously obliged to make it as stable as possible:)
> B. Do the concurrent features allow shared memory parallelism?
Yes, I wrote the GC from scratch. I am not sure if it can be integrated well with llvm, I never thought about it. The concurrent GC algorithm (plus a single threaded incremental collector) in Dao was inspired by the algorithm proposed in http://researcher.watson.ibm.com/researcher/files/us-bacon/B....
IIRC reference counted GCs are easier to integrate with LLVM as there is no need to generate a global root set (which is one of the things that llvm makes hard).
Right, this property of reference counted GCs can make certain things simpler.
I just realized that you asked the question probably because of the LLVM-based JIT compiler for Dao. This JIT compiler actually does not deal with GC at all, it just compiles consecutive segments of VM instructions into functions that will be called by the VM. Only a subset of the total VM instructions are compilable this way. It was intended for programs with a significant amount of numeric computation.
