1 What is Goblins?
Goblins is a quasi-functional distributed object system, mostly following the actor model. Its design allows for object-capability security, allowing for safe distributed programming environments.1By now you may have noticed that we’ve used the term "object" twice... we may not be meaning the term the way you think! In the early to mid 2000s, "object oriented programming" was all the rage such that being reprimanded by an OOP zealots for not fitting into their worldviews was common. These days the pendelum has swung in the opposite direction such that one is more likely to be reprimanded by anti-object-oriented zealots. In fact, "Object Oriented" has many different meanings. If you have PTSD from complex Java or C++ class structures, please read on... our use of the term doesn’t involve any fundamental form of "classes" or "inheritance". Furthermore, "object" in "object capability security" refers to security based on holding onto references to an external entity. What you hold onto is what you can do. Even most purely functional languages can fit into that definition, and so too can most functional languages follow object capability security. Its design is inspired by the E programming language and by the observation that lambda is already the ultimate security mechanism (ie, normal argument-passing in programs, if taken seriously/purely, is already all the security system we need).
1.1 What works so far?
Quasi-functional object system: Users hold on to references of objects/actors, but objects/actors are just procedures. Rather than directly mutating, objects/actors can specify that they should "become" a new version of themselves when they handle the next invocation.
Transactional updates: Changes happen within a transaction. If an unhandled exception occurs, we can "roll back" history as if the message never happened, avoiding confused state changes throughout the system.
Time travel: We can snapshot old revisions of the system and interact with them.
Asynchronous programming with sophisticated promise chaining: Asynchronous message passing with promises is supported. Promises work such that there’s no need to wait for promises to resolve before interacting... you can communicate with the future that doesn’t even yet exist! Sent a message to that remote car factory asking for a new car? Why wait for the car to be delivered... you can send it a drive message at the same time, and both messages can be delivered across the network in a single hop.
Communicating event loops: Objects across multiple event loops (aka "vats") can communicate, whether in the same OS process or (soon) across the network.
Synchronous and asynchronous behavior, integrated but distinguished*: Both synchronous and asynchronous programming is supported, but only objects in the same "vat" (event loop) can perform synchronous immediate calls. All objects can perform asynchronous calls against each other.
A library, not a language: Goblins is itself a library that can be utilized with nearly any Racket program, including many Racket #langs. (However, some languages may be provided or encouraged for additional security / convenience later).
Object capability security: Goblins itself is built for object capability (ocap) security, which is to say that you can only operate on the references you have access to. Goblins embraces and builds upon this foundation. (However, full ocap security will require a safer module system than the one Racket provides; coming eventually.)
Fully distributed, networked, secure p2p communication: Via CapTP, you can communicate with other objects over a network connection. Distributed object interactions is safe because of ocap security guarantees. (Okay, actually see the first caveat in the next section.)
1.2 What’s on its way?
The rest of CapTP: There’s still a few things left to CapTP to allow for easier connection setup, proper disconnect handling, and capability introductions between multiple machines. (Coming in v0.8, presumably!)
A separate module system: While not part of Goblins itself, a future project named "Spritely Dungeon" will help close the loop on ocap security for Racket.
1By now you may have noticed that we’ve used the term "object" twice... we may not be meaning the term the way you think! In the early to mid 2000s, "object oriented programming" was all the rage such that being reprimanded by an OOP zealots for not fitting into their worldviews was common. These days the pendelum has swung in the opposite direction such that one is more likely to be reprimanded by anti-object-oriented zealots. In fact, "Object Oriented" has many different meanings. If you have PTSD from complex Java or C++ class structures, please read on... our use of the term doesn’t involve any fundamental form of "classes" or "inheritance". Furthermore, "object" in "object capability security" refers to security based on holding onto references to an external entity. What you hold onto is what you can do. Even most purely functional languages can fit into that definition, and so too can most functional languages follow object capability security.