The case for Rell, a new blockchain language

Rell is a new language designed for blockchain programming. Many have asked us why a developer should take the time to get to know a new language when there are so many out there already. Wikipedia lists over 700 programming languages, does the world really need another one? This article is intended to answer that question.

Relational blockchain development

Photo by israel palacio / Unsplash
Relational blockchain is all about leveraging a mature and optimized database technology to fix what's wrong with blockchain. Postchain and Chromia offload as much work as possible onto an RDMBS. A relational blockchain is a blockchain that uses the relational data model. This means that it supports a lot of features you won't be used to seeing in a blockchain platform:

Complex queries

Complex validation

Minimal novel code

Efficient execution

Good developer UX

Our initial assumption was that relational blockchains could closely follow existing best practices for app development: a backend with a SQL database and a frontend coded in some appropriate language, probably Javascript. Indeed it is entirely possible to develop complete decentralized applications (dapps) in this way. However, this model has some problems, and as we moved towards building dapps at ever greater scale, we found that they became more and more severe. The more "decentralized" the execution environment, the more critical the usability and security posture of the development tools.

What's wrong with SQL + Javascript

Photo by Jamie Street / Unsplash
Firstly, the development process is quite cumbersome. A lack of static checking means that typos and syntax errors are not apparent without running tests, and that types of arguments can be ambiguous. A language with static checking gives immediate feedback if something is wrong, and precise information about the location and nature of the error.

While in theory being able to use established languages is a blessing, in practice it can make things more complicated. In this case the need to load data to and from SQL makes application code more verbose, a problem that is avoided in a more tightly integrated language. All this is manageable in a centralized setting, but the increased risk of bugs and the burden of shipping patches is compounded in a distributed system. In short, these languages are not well adapted to the specific challenges of blockchain.

We stress that "SQL+" is still a good option for private blockchain implementations in an enterprise setting. In this environment, the positives of using existing dev resources and easing integration with existing systems may well outweigh the negatives.

For a public dapp platform like Chromia, we saw the need for a language that was safer, easier to use, and enforced the kind of constraints that are sensible if not critical when building distributed applications. It is that which led us to closely analyze what an ideal blockchain language might look like, then to try and identify an existing language we could use or adapt, and finally to develop Rell.

There is no proper language for blockchain out there

Rell is not a fork of an existing language, it is a new language. We made it because we looked for a language that met our needs and did not find one. These needs can be summarized as follows:

Support for a combination of imperative constructs and database constructs.

Basically database constructs are equivalent to SQL, and imperative constructs like variables, functions, loops are equivalent to a normal programming language. And you can use both. For example:

for (prod in running_production@*{completion <= op_ctx.last_block_time}) {
process_production_completion(prod);
}

Here we execute a query running_production@*{completion <= op_ctx.last_block_time}
to retrieve productions which are complete and then use an imperative constructs (for and function call) to deal with retrieved objects. This is similar to PL/SQL in principle, but with better syntax and a better type system.

A runtime which is good for blockchain.

Working with blockchain requires deterministic operations which can't access anything outside of what they are meant to access, and that can't exceed their memory and computation allowance. Existing programming languages typically have large runtime libraries which includes lots of stuff. Most of that stuff is going to be unnecessary or harmful. If we make a custom runtime we can easily satisfy these properties by not including anything which is non-deterministic or which has potentially dangerous access permissions. We can also more easily control resource use.

Persistence libraries which work in a decentralized context.

A typical programming language runtime also includes file I/O or database connection components which are also irrelevant and potentially dangerous.

Rell is less complex

Some worry that a new language adds complexity and places an unnecessary burden on programmers. There is a concern that that this will hurt adoption and the long term prospects of a platform dependent on it. We don't think this will be the case here. Rell is demonstrably simple and straightforward to learn. It shares a lot of concepts with modern languages with static type checking like Typescript, Swift, and Kotlin. If you have any familiarity with those you should be able to become proficient in a few days. For example, basic code like:

val x = 5;
val y = x + 10;

works identically in Kotlin and Rell. There's also a lot of similarity in the collections library.

Further, learning a new language is not necessarily harder than learning to do something new in a language you are already familiar with, especially if the new language is purpose built for the domain in question. For an experienced Javascript developer, the burden of learning Rell compares favourably with the burden of learning a new framework like React.

Rell has native constructs which are specific to blockchain programming. This means that a good programmer can code something quite complex in Rell in just a few hours. The frontend components of your dapp will likely take orders of magnitude more time than your Rell backend.

Getting started with Rell

You can already try an early developer preview of Rell by following the instructions here. We are working on new releases, subscribe to our newsletter to stay up to date.