An Object Capability Language with the Wiki Un Friendly Name E.
E is "the secure distributed pure-object platform and Peer To Peer Scripting Language for writing Capability-based Smart Contracts" (contracts expressed as programs, where the logic of the program's execution helps enforce the terms of the contract. See www.erights.org 
.)
E is a Big Idea language, the big idea being Capability Computing. E also implements distributed capability computing, which is where things get interesting - your program can safely interact with remote E programs. The implementation enforces the above constraints securely: it ensures (by the use of cryptography in the distributed case -- see Distributed Object Capability Model) that the rules cannot be violated. Lastly, E is specified to support (but at present does not implement) Orthogonal Persistence and 'Automatic Mobile Code'.
Ee Language is descended from Joule Language -- see also www.erights.org . Like Joule,
E belongs to the family of Actor Languages. It supports synchronous method calls (like most OO languages) as well as the asynchronous calls normally associated with the Actors Model.
Money in 21 lines of code: www.erights.org
The reference implementation of E is currently implemented in Java Language, and programs written in E can use most of Java's libraries.
There is a current project to run E code on the Squeak Smalltalk Virtual Machine, called Ee On Squeak: www.google.com (not to be confused with Squeak Ee)
As an experiment, it has been suggested to use this Wiki to discuss E development issues -- see below.
[But also see Walled Gardens. E language is very cool, but keep the E stuff on this page, or start an E wiki elsewhere]
I am finding the 'eventual' sends very interesting, as they return promises [Promise Pipelining]. It's not quite like promises in Scheme Language, but more in the asynchronous sense of, when the send arrives to that object, it will do as the message says, even an eventual creation returns an immediate promise of that object so you can send eventual messages. There's a try-catch mechanism for this called when-catch, which is the only part on the program that waits until the promise is resolved (either remotely or locally). This prevents deadlocks, very interesting... -- David De Lis
(Besides being wiki-unfriendly this name is also Google Hostile, not that C [Cee Language], C++ [Cee Plus Plus], PL/I [Pli Language], Icon [Icon Language] or TOM [Tom Language] are any better in this respect...)
Open E development issues below:
E-like asynch I/O
Ee Language needs to replace its current I/O API with a non-blocking one. The non-blocking API should be designed according to the principles of E's eventual-send messaging style.
The thread root is www.eros-os.org
The dangling end is
www.eros-os.org
Is there some concrete proposal for an API to comment on?
Yes: www.erights.org
www.erights.org says
The sched parameter says how the operation should be scheduled:
NOW - The operation is performed immediately, whether or not sufficient elements are ready. [...]
WAIT - Warning:
may block the vat and cause deadlock. If the operation can succeed immediately, it is performed immediately. [...]
LATER - Registers a claim for the next atLeast..atMost elements, and returns a promise for them.
These should be considered different primitives, not variations of the same primitive. IIUC, E has a naming convention for methods that return promises, and I think it should also have one for methods that can (intentionally) block. Methods that have one of several concurrency behaviours depending on their parameters arguably should not be encouraged.
This is part of the motivation for providing the convenience methods. However, currently, we have no convenience methods for the WAIT case; perhaps we should? Perhaps we should have "readNow", "readWait", and "readLater"? (This is especially appealing because the current "read" really means "readNow"; whereas someone coming from the C tradition may very well expect "read" to mean "readWait".)
Even if we introduce further convenience methods, your question remains: should we split the obtain primitive up into more simpler primitives according to their return type? The problem with this argument is knowing when to stop. ELEMENTS vs STATUS also makes for different return types -- making for 6 primitives instead of one.
Also, the OutStream design doesn't seem to be sufficient to provide proper backpressure on the producer. The pending messages sent to the OutStream will act as an unlimited buffer, so the producer's vat may run out of memory if it sends a lot of data faster than it can be consumed. One way of fixing this is for a client of an OutStream to be able to tell how much data is locally buffered. There probably also needs to be a variant of 'write' that returns a promise when the amount of local buffered data has fallen below a threshold.
You may have missed www.erights.org
The intention of whenAvailable/2 is to enable just this kind of cooperative backpressure. It doesn't do what you're suggesting (it doesn't tell you how much is locally buffered), but does it tell you what you need? Does it address your concern?
What issue tracking software should we use?
Current candidates are Wiki, The software used by Ruby Garden, and Roundup.
News: We now have a Roundup at lambda.sieve.net
Many thanks to Ka-Ping Yee and Steve Jenson!
The thread root is
www.eros-os.org
The dangling end of the e-lang thread is
www.eros-os.org
See Capability Security Model, Object Capability Model, Object Capability Language, Actor Languages, Actors Model, Distributed Object Capability Model
See original on c2.com