# Roc + NLNET

## Abstract: Can you explain the whole project and its expected outcome(s).

A webserver framework for roc that performs 0 allocations for a request.

Roc is a functional language in the tradition of elm that can be described as "a strictly-typed performant lua". Roc applications are always built on a platform, that provides access to system resources. One of those resources is memory: the platform is in control of the roc allocator.

That makes it possible to write normal roc code for a web service, but under the hood use an allocator that uses an arena per request. When the request is done, the arena can be emptied. Unless the arena is full, no memory is allocated during the request. No memory is given back to the OS (the arena will be used for a future request).

Furthermore, the server can put a limit on a request's memory usage: when the limit is exceeded, a 500 error can be returned. When a limit is provided, memory use of the web server is constant.

outcomes

- a roc webserver platform, that limits or eliminates allocations for a request
- a roc application that can fetch some json and return HTML

## Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?

I am the person with the highest number of commits on the roc repository. I've been active on the project for over 3 years, and a member of the roc programming language foundation board.

## Explain what the requested budget will be used for

> Does the project have other funding sources, both past and present?
> (If you want, you can in addition attach a budget at the bottom of the form)

## Compare your own project with existing or historical efforts.

In roc, a platform can make choices about memory management that are domain-specific. In this case, memory can be managed per request.

This is not possible in languages with a garbage collector: memory is managed by the language runtime, irrespective of the application domain. There are some knobs that can be tuned, but getting it right is still hard.

It is also hard in languages with manual memory management. Fine-grained control over allocation relies on programmer dedication. A web service does not really want to be concerned with this sort of detail. The programmer that writes web services would rather not be concerted with this sort of detail.

Thus what roc provides is efficient use of memory, without burdening the web service programmer.

Furthermore, we will be able to put a hard limit on memory use per request. Any request that exceeds the limit will just get an error 500. Without language support like we propose, the best you can do is limit memory use for the service as a whole, and shut the whole service down when the limit is reached.

A project that is similar in spirit is TigerBeetle. It is a database that pre-allocates all its memory. After the initialization phase, no memory is allocated or given back to the OS.

## what are significant technical challenges you expect to solve during the project

We will need to effectively write our own async runtime

Setting up the allocator on the rust side

## describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes