A Vision for Future Low-Level Languages I’ve had this vision in my head for quite a while now on what code written in a low-level language could look like. This vision has shaped my design of Ante and although I’ve alluded to it before, I’ve never explicitly stated it until now. Now, what makes a language low-level is a bit contentious. I’m using it here to describe a group of languages I have no better descriptor for: C, C++, Rust, and Zig, among others.
Introduction In my first blog post I introduced &shared mut references as a way to achieve safe, shared mutability in a language with unboxed types. For more information on those, start with the first blog post. As a brief summary though, &shared mut references can be aliased freely and mutate freely with the one restriction of not being able to be projected into any “shape-unstable” types. What is a shape-unstable type?
Why Algebraic Effects Algebraic effects1 (a.k.a. effect handlers) are a very useful up-and-coming feature that I personally think will see a huge surge in popularity in the programming languages of tomorrow. They’re one of the core features of Ante, as well as being the focus of many research languages including Koka, Effekt, Eff, and Flix. However, while many articles or documentation snippets try to explain what effect handlers are (including Ante’s own documentation), few really go in-depth on why you would want to use them.
Ante’s goal was always to be a slightly higher level language than Rust. I always imagined Ante to fill this gap in language design between higher-level garbage collected languages like Java, Python, and Haskell, and lower level non-garbage collected languages like C, C++, and Rust. I still think there’s room there for a language which tries to manage things by default but also allows users to manually do so if needed as an optimization.
Introduction Algebraic Effects are a useful abstraction for reasoning about effectful programs by letting us leave the interpretation of these effects to callers. However, most existing literature discusses these in the context of a pure functional language with pervasive sharing of values. What restrictions would we need to introduce algebraic effects into a language with ownership and borrowing - particularly Ante?1 Ownership Consider the following program: effect Read a with read : Unit -> a the_value (value: a) (f: Unit -> b can Read a) : b = handle f () | read () -> resume value This seems like it’d pass type checking at first glance, but we can easily construct a program that tries to use the same moved value twice:
This is part of Ante’s goal to loosen restrictions on low-level programming while remaining fast, memory-safe, and thread-safe. Background When writing low-level, memory-safe, and thread-safe programs, a nice feature that lets us achieve all of these is an ownership model. Ownership models have been used by quite a few languages, but the language which popularized them was Rust. In Rust, the compiler will check our code to ensure we have no dangling references and cannot access already-freed memory (among other errors).
Template by Bootstrapious. Ported to Hugo by DevCows.
