| I have been thinking recently about a set of features that might be | |
| interesting for an interpreted language. Largely I am uninterested in the | |
| syntax for now, just the properties of the language and implementation. | |
| 1. Actor model similar to erlang with total isolation of actors except | |
| via message passing. Crashing one actor does not affect other actors | |
| unless they want to be affected. | |
| 2. Mutability within an actor, but only immutable objects can be passed | |
| between actors. Or mutable objects can be transferred but a runtime | |
| error occurs on accessing a mutable structure after it has been 'moved'. | |
| 3. Embrace the unix security model. Actors can be local to the vm or forked actors | |
| with a different pid and user id. Actors could embrace OS level privsep | |
| code, perhaps integrate the language with OS level jails/containers. Make | |
| writing privsepped code a first class citizen of the language... | |
| 4. Object/actor capability system. If you do no have an unforgeable | |
| reference to an actor, you cannot message it. See pony for | |
| inspiration. All OS/runtime functionality is controlled by actors, hence | |
| sandboxing code is as simple as not passing references to the relevant | |
| actors to the sandboxed actor. | |
| 5. The actors in a different process can be remote or local. spawn an actor over | |
| an ssh link then send it a reference to an open file actor. | |
| Perhaps the runtime needs some smart routing to get messages | |
| to distant actors, especially in the presence of a tree of unix | |
| processes. I think this is slightly different to erlang which has a | |
| notion of 'nodes', and no security isolation or tree structure. | |
| 6. Unreachable actors can be garbage collected. This might not be well | |
| thought out or possible. | |
| 7. Runtime resource limits can be put on individual actors, or groups | |
| of actors. Be able to say - "This http server actor (tree) cannot use | |
| more than N resources" which is imposed at runtime. | |
| 8. Erlang style supervisors should be possible via links. | |
| 9. Live code reloading. Code changes are propagated down the process tree. | |
| Some of these are already possible with erlang, but I think some of it | |
| would be a unique combination. Let me know if any of this is new, good, | |
| bad or impossible. | |
| Misc: | |
| Remote messages may need to be unforgeable using cryptography. This can be accomplished by giving each actor | |
| a secret or pub/private, and messaged recieved must be HMACED/signed. local actors can trust the runtime | |
| that the actor id hasn't been faked for performance, Pony accomplishes this with memory safety. | |
| Examples for the imagination: | |
| Spawning a privsepped remote actor, and getting it to write a file: | |
| write_file(file) { | |
| // the remote actor can ONLY write to this file, thats all it has a reference to. | |
| // The chroot and remote message signing add security from runtime exploits. | |
| file.write("hello from remote actor!") | |
| file.close() | |
| } | |
| main(world) { | |
| // world, remote_world, and file are all references to actors. | |
| file = world.open("/local/file.txt") | |
| remote_world = world.spawn_world(host="remote@distant.com", chroot="/jail/") | |
| remote_actor = remote_world.spawn(write_file, file) | |
| remote_actor.wait_for_exit() | |
| // Prints "hello from remote actor!" | |
| world.print(world.readfile("/local/file.txt"")) | |
| } | |
| Perhaps we could send a handle for the current world to the remote world! | |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
MostAwesomeDude
commented
Oct 27, 2017
|
Have you seen Monte yet? http://monte.readthedocs.io/en/latest/ |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment
Hide comment
|
I hadn't actually, thanks for pointing it out :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Have you seen Monte yet? http://monte.readthedocs.io/en/latest/