You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A faster, safer, and more productive systems programming language
This is not an officially supported Google product.
NOTE: Rune is an unfinished language. Feel free to kick tires and evaluate the
cool new security and efficiency features of Rune, but, for now, it is not
recommended for any production use case.
Rune is a Python-inspired efficient systems programming language designed to
interact well with C and C++ libraries. Rune has many security features such as
memory safety, and constant-time processing of secrets. Rune aims to be faster
than C++ for most memory-intensive applications, due to its Structure-of-Array
(SoA)
memory management.
It provides many of its features by deeply integrating features similar to the
"DataDraw" tool into the primitives and
constructs of the language. DataDraw is a code-generation tool that generates
highly-optimized C code which outperforms e.g., the C++ STL given a declarative
description of data-structures and relationships between them. For more
information, see the DataDraw 3.0
Manual.
Let's take a look at two examples that showcase many of the unique features of Rune:
A simple example of a secret type, and how it can be used to protect against timing attacks.
A more complex example of a data-structure with nullable, self-referential recursive references.
(This can present footguns in many languages, but it is trivial in Rune)
Dedicated "secret" types
Consider the following example for treatment of secrets:
// Check the MAC (message authentication code) for a message. A MAC is derived// from a hash over the `macSecret` and message. It ensures the message has not// been modified, and was sent by someone who knows `macSecret`.funccheckMac(macSecret: secret(string), message: string, mac: string) ->bool {
computedMac=computeMac(macSecret, message)
returnmac==computedMac
}
funccomputeMac(macSecret: string, message: string) ->string {
// A popular MAC algorithm.returnhmacSha256(macSecret, message)
}
Can you see the potential security flaw? In most languages, an attacker with
accurate timing data can forge a MAC on a message of their choice, causing a
server to accept it as genuine.
Assume the attacker can tell how long it takes for mac == computedMac to run.
If the first byte of an attacker-chosen mac is wrong for the attacker-chosen
message, the loop terminates after just one comparison. With 256 attempts,
the attacker can find the first byte of the expected MAC for the
attacker-controlled message. Repeating this process, the attacker can forge
an entire MAC.
Users of Rune are protected, because the compiler sees that macSecret is
secret, and thus the result of hmacSha256 is secret. The string comparison
operator, when either operand is secret, will run in constant time, revealing no
timing information to the attacker. Care must still be taken in Rune, but many
common mistakes like this are detected by the compiler, and either fixed or
flagged as an error.
A "DB-embedded" language: relational data-structures and optimal memory-efficiency
As for the speed and safety of Rune's memory management, consider a simple
Human class. This can be tricky to model in some languages, yet is trivial in
both SQL and Rune.
class Human(self:Human, name: string, mother:Human? = null(self), father:Human? = null(self)){self.name = name
// The methods "appendMotheredHuman" and "appendFatheredHuman" are generated// by code "transformers", a key factor in Rune's performance.//// We'll learn more about these methods in the next section ("How does this work?").if !isnull(mother){
mother.appendMotheredHuman(self)}if !isnull(father){
father.appendFatheredHuman(self)}
func printFamilyTree(self, level:u32){for i inrange(level){
print " " } println self.name for child in self.motheredHumans() { child.printFamilyTree(level + 1) } for child in self.fatheredHumans() { child.printFamilyTree(level + 1) } }}// Relation statements are similar to "ForeignKey" constraints inSQL.// They are used to define the relationships between data-structures.//// The "cascade" keyword means that when a Human is destroyed, all of// its children are recursively destroyed.// (In other words, manual invalidation of pointers is not required)//// This ability is also provided by code transformers. See// builtin/doublylinked.rn
relation DoublyLinkedHuman:"Mother" Human:"Mothered" cascade
relation DoublyLinkedHuman:"Father" Human:"Fathered" cascade
// Let's create a family tree.adam = Human("Adam")
eve = Human("Eve")
cain = Human("Cain", eve, adam)
abel = Human("Abel", eve, adam)
alice = Human("Alice", eve, adam)
bob = Human("Bob", eve, adam)
malory = Human("Malory", alice, abel)
abel.destroy()
adam.printFamilyTree(0u32)
eve.printFamilyTree(0u32)
When run, this prints:
Adam
Cain
Alice
Bob
Eve
Cain
Alice
Bob
How does this work?
Note that Abel and Malory are not listed. This is because we didn't just kill
Abel, we destroyed Abel, and this caused all of Abel's children to be
recursively destroyed. Also note that Rune now supports null safety. Null safety does not mean null does not exist in the language. It means types by default cannot be null. This can be overridden with <type>? in the type constraint.
Relation statements are similar to columns in SQL tables. A table with a Mother
and Father column has two many-to-one relations in a database.
Relation statements give the Rune compiler critical hints for memory
optimization. Objects which the compiler can prove are always in
cascade-delete relationships do not need to be reference counted. The relation
statements also inform the compiler to update Human's destructor to recursively
destroy children. Rune programmers never write destructors, removing this
footgun from the language.
To understand why Rune's generated SoA code is so efficient, consider the arrays
of properties created for the Human example above:
A total of 12 arrays are allocated for the Human class in SoA memory layout. In
printFamilyTree, we only access 5 of them. In AoS memory layout, all 12
fields would be loaded into cache during the tree traversal, and all fields
would be 64 bits on a 64-bit machine. In Rune, only the string references are
64-bits by default. As a result, Rune loads only 25% as much data into
cache during the traversal, improving memory load times, while simultaneously
improving cache hit rates.
This is why Rune's binary_trees.rn code already runs faster than any other
single-threaded result in the Benchmark
Games.
(Rune is not yet multi-threaded). The only close competitor is C++, where the
author uses the little-known std::pmr::monotonic_buffer_resource class from the <memory_resource> library.
Not only is Rune's SoA memory layout faster, but its solution is more generic:
we can create/destroy Node objects arbitrarily, unlike the C++ benchmark based
on std::pmr::monotonic_buffer_resource. When completed, we expect Rune to win most memory-intensive
benchmarks.
Installation
Compiling the Rune compiler:
You'll need 6 dependencies installed to compile Rune:
Bison (parser generator)
Flex (lexer generator)
GNU multi-precision package gmp
Clang version 10
Datadraw, an SoA data-structure generator for C
CTTK, a constant-time big integer arithmetic library
The first four can be installed with one command: