Motivation

Query languages suck¶

Most query languages are not designed as a programming language, but have started as a few very basic queries and then evolved by patching-in more and more features on top. This makes them hard to use for writing complex programs. SQL is the biggest offender (see 1, 2, 3, 4, 5, 6, 7, 8, 9 ), but many other languages are similarly problematic.

Lutra aims to be a "proper" programming language, with user-defined functions, an algebraic type system, generic function type parameters, Hindley-Milner-like type inference and many small, "quality of life" features.

That all compiles to a minimal intermediate representation that should be easy to compile for different execution targets. The goal is to support SQL and most major relational databases, but also other runners like WebAssembly or Polars.

Because a different compilation model, Lutra compiler can emit better error messages, provide better guarantees about compiled code and evolve the language without the need to change any database query language.

Essentially, it is treating SQL as an instruction set instead of a user-facing API.

Type safety¶

Many challenges in modern programming arise from losing type information within a system. Often this is the fault of the programming language, but in many cases it is caused by passing data through type-erasing points.

For example, API calls that return JSON, reading from files, or calling out to a database all lose type information. While these interfaces usually have a notion of expected data format, most tools fail to express this information in a way that can be used by the toolchain and the programmer.

The Lutra Project aims to provide this tooling and establish a standardized interface for interaction between software operating across different machines, processes, or programming languages.