Concurrency refers to situations in which multiple programs concurrently modify shared data. Concurrency is challenging because it introduces ambiguity in program execution order - programs may be distributed across threads, processes, or even sometimes, in the case of distributed systems, networks.

It is precisely this ambituity that causes a particular nasty class of erros known as race conditions. A race condition is a situation in which execution order affects the outcome. As a motivating example, suppose there exist two programs A and B that would like to concurrently increment a shared counter x. Formally, each program reads x, sets x' = x + 1, and writes x'. If B reads after A finishes writing, then B reads x' and writes x' + 1. However, if B reads before A finishes writing, then B reads x and also writes x'. Clearly, this is a race condition because the value of the counter, x' + 1 or x', depends on the order in which A and B perform reads and writes. This particular race condition may seem relatively benign. Who cares if two increments were successfully performed, but the effect of only one was recorded? Imagine if the value of x corresponded to your bank balance, and the increments corresponded to deposits. What if your bank only recorded every second deposit? Still don't care? While race conditions manifest themselves in subtle ways in concurrent systems, they can often have catastrophic consequences.

Most programming languages provide the fundamental tools like locks, semaphores, and monitors to explicitly deal with race conditions. Some, like Rust, go a step further and are able to detect race conditions between concurrent threads during compilation. But none, however, are able to guarantee correctness in distributed systems. Distributed systems form the computing backbone of nearly every major technology from social networks to video streaming, but their intricate complexity coupled with the inability to detect race conditions makes designing them extremely error-prone.

Caustic is a programming language for building correct distributed systems. Programs written in Caustic may be distributed arbitrarily, but they will never exhibit race conditions.

Background

A transaction is a sequence of operations that are atomic, consistent, isolated, and durable. Together, these ACID properties (from which Caustic derives its name!) allow transactions, when used correctly, to completely eliminate race conditions.

• Atomic: Transactions are all-or-nothing. Either all of their operations complete successfully, or none of them do.
• Consistent: Transactions must see the result of all successfully completed transactions.
• Isolated: Transactions cannot see the result of an in-progress transaction.
• Durable: Transactions are permanent.

A key-value store is a data structure that associates a unique value to any key. For example, a dictionary is a key-value store that associates a unique definition to any word. Key-value stores are the essence of every storage system; memory is a key-value store that associates a unique sequence of bytes to any address, and databases are key-value stores that associate blobs of data to any primary key. A transactional key-value store is simply a key-value store that supports transactions. While transactions are challenging to correctly implement, there are an enormous number of storage systems that are capable of handling them. Examples range from software transaction memory solutions for single machines to powerful databases like Cassandra and MySQL for larger clusters.

Clearly, transactions are a useful primitive for building correct distributed systems and there are a plethora of storage systems capable of handling them. However, these transactional storage systems each have their own unique language for specifying transactions that are often lacking in functionality and performance. Recent years have marked an explosion in NoSQL databases, that scale well by shedding functionality. These databases were not popularized because of their query languages, they were in spite of them. Some like CQL and AQL attempt to mimic SQL, but, while similar in name and intent, most fall short of implementing the entire SQL specification. Others like MongoDB and DynamoDB have their own bespoke interfaces that are often so complicated that they require classes. But even SQL is not beyond reproach. In his article "Some Principles of Good Language Design", CJ Date, one of the fathers of relational databases, outlined a number of inherent flaws in the SQL language including its lack of a canonical implementation and its ambiguous syntax. While these storage systems provide the necessary transactional guarantees that are required to build correct distributed systems, their lack of a robust interface makes it impossible to design nontrivial applications.

Caustic is a powerful and performant programming language for expressing and executing transactions against any transactional key-value store. Caustic couples the robust functionality of a modern programming language with the ACID guarantees of a transactional key-value store, both of which are necessary to architect correct distributed systems.

Example

Consider the following example of a distributed counter written in Caustic. It is statically typed and distributable. It interoperates with any transactional key-value store (currently supports MySQL, PostgreSQL, and memory), and compiles into a Scala Library that is compatible with all existing frameworks, tooling, and infrastructure for the JVM. Please refer here for information about how to bootstrap the runtime and here for information about how to compile and run Caustic programs.

module counter

/**
 * A counter.
 *
 * @param value Current value.
 */
record Total {
  value: Int
}

/**
 * A distributed counting service.
 */
service Counter {

  /**
   * Increments the total and returns its current value.
   *
   * @param x Total pointer.
   * @return Current value.
   */
  def increment(x: Total&): Int = {
    if x.value {
      x.value += 1
    } else {
      x.value = 1
    }
  }

}

Organization

# Programming Language
caustic/                            https://github.com/ashwin153/caustic
+---caustic-assets/                 Documentation, results, and graphics.
+---caustic-benchmarks/             Performance tests.
+---caustic-compiler/               Programming language and compiler.
+---caustic-runtime/                Virutal machine.

# Syntax Highlighting
caustic.tmbundle/                   https://github.com/ashwin153/caustic.tmbundle
+---Preferences/                    TextMate preferences.
+---Snippets/                       TextMate code snippets.
+---Syntaxes/                       TextMate grammar.

# YCSB Benchmarks
ycsb/                               https://github.com/ashwin153/YCSB
+---caustic                         Caustic integration.

Requirements

• Java 1.8
• Python 2.7 (build-only)
• Scala 2.12

Artifacts

Artifacts are published to the Sonatype Nexus and synced to Maven Central. Snapshots of the master branch are built using Travis CI and images are available on Docker.

<!-- Client Library -->
<dependency>
  <groupId>com.madavan</groupId>
  <artifactId>caustic-service_2.12</artifactId>
  <version>1.3.1</version>
</dependency>

<!-- Runtime Library -->
<dependency>
  <groupId>com.madavan</groupId>
  <artifactId>caustic-runtime_2.12</artifactId>
  <version>1.3.1</version>
</dependency>