# zero-allocation server: NLNet round 2 questions

## Is there a specification for Roc?

There is no official language specification yet. I suspect we'll hold of on that util a 1.0 release.

For a general overview of the language, this page is a good starting point https://www.roc-lang.org/tutorial.

## What do you expect to be the biggest driver in its adoption?

Custom platforms.

Roc is a modern language and tries to incorporate recent research and insights. This includes features like sum type (or ADTs, tagged unions) and anonymous record types. But on the language level is it not revolutionary, and tries to mostly go down well-explored paths.

In terms of compiler infrastructure we are ambitious. Not only do we want to deliver a fast compiler that provides good error messages, we also want to (and need, in order to succeed) a formatter, test runner and similar tooling. Furthermore to achieve our performance goals we implement our own lowering to assembly, and perform our own linking. We believe this will deliver a top class user experience.

However, the most revolutionary aspect is that we provide the unique ability to just change the runtime system of the language, and really tailor it to a particular problem domain.

From a performance perspective, the most interesting result of this ability is to change the memory allocation strategy. A roc platform can do arena allocation under the hood, without the roc programmer ever having to care. A platform can expose just the system primitives that its domain needs, cutting down on security risks.

## What kind of target audience do you believe would start using this webserver in production when done? If this goes beyond static content, would its properties still hold up?

This webserver makes some tradeoffs that mostly make sense for serious web applications. We assume scaling happens by adding more instances, and that memory usage is a problem (to the point that the process runs out of memory and requests are cancelled). That is not something that would really happen for a personal blog.

So the proposed webserver makes most sense exactly when the content is not static. When there is significant work to be performed to respond to the request, and when requests failing ocasionally is already something that is part of normal operations (and e.g. handled by the client).

The proposed webserver does not make sense when a request stays alive for a long time and requires state to be persisted on the server. A typical example is a websocket connection. The downside of our approach in this scenario is that memory will only be free'd after the request is completely done and so a long-lived request has a higher risk of running out of memory.

## You write this will produce a "web server framework written in rust". What is the reusability for those remaining within the Rust world, and not looking to add other dependencies like Zig? Can you clarify the relationship between Rust and Zig, Roc and the codebase(s) you will create within this project?

The project will primarily create a rust library that defines components for running this webserver (the memory allocator and async runtime). Then the project includes the creation of a roc platform that uses this rust library. This will involve both rust and roc code, to hook everything up.

But it should also be possible to use rust or zig to build applications on top of the library. I think zig is truly out of scope for this project, but rust is relevant. It is likely that we'll implement a rust app on top of the rust library for testing anyways.

## Could you reflect on Inko [1] (another Dutch effort) and its deterministic memory management? To what extent would this approach be a solution for the challenge you are taking up? What about dynamic garbage collection?

[1] https://nlnet.nl/project/Inko

Inko looks like a modern language, and as such shares many characteristics with roc.

However, its documentation mentions:

> The native code is statically linked against a small runtime library written in Rust, which takes care of scheduling processes, non-blocking IO, and provides various low-level functions.

Which means that it has nothing like roc's platforms. There is just the one runtime, supplied by the compiler. Nothing is mentioned about how memory management works under the hood, but because it aims to be simpler, I suspect (de)allocation is entirely opaque to the user and handled in the runtime. (De)allocation being deterministic says nothing about how it actually happens

The faq at https://docs.inko-lang.org/manual/main/guides/goals/ mentions that:

> Inko is explicitly not a systems language, and this means it will never (publicly) support low-level memory operations, such as raw memory allocations, pointers, **custom allocators**

> Inko's runtime makes it difficult to expose Inko programs through a C interface, thus making it difficult to use Inko from other languages

therefore, as far as I can see based on their documentation:

- it would be difficult to integrate Inko with the rust library that this project proposes.
- it would be effectively impossible to enforce a per-request upper bound for memory usage with a server written fully in Inko

### What about dynamic garbage collection?

Here we run into what those words mean exactly. Roc uses reference counting as its memory management strategy. This is dynamic in the sense that there is runtime overhead because reference counts need to be checkend and in/decremented. We also could call this garbage collection, but crucially we do not have a garbage collector: we do not have a system that pauses program execution to free up memory that has become unused.

It is not entirely clear to me what Inko does. It seems to be able to insert deallocations statically, but presumably has or will eventually require some dynamic memory management too (similar to rust's Arc and Rc types).

## What kind of memory footprint would this solution have compared to its competitors in the webserver space? If your webserver would be predictable and have constant memory, but would offer the performance of the worst possible scenario of non-constant memory, there would be a net loss in energy usage...

Our competition is languages like Ruby and Python. Rewriting entirely in rust is often not an option. Its (perceived) complexity and slow compile times mean that rust is often not a viable alternative for a team that currently uses ruby or python.

Based on table 4 in "Energy Efficiency across Programming Languages" (https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf), languages like ruby and python use significantly more memory than rust. The higher memory use and runtime in turn mean a much higher energy consumption.

We cannot know yet exactly what our memory consumption will be. In certain scenarios we should be able to beat standard rust, but generally we expect to do slightly worse than rust. Still this is a significant improvement over the status quo of dynamically typed interpreted languages.

But part of our assumption is that we run multiple instances of this webserver, and they generally run at capacity. Therefore all memory that it has allocated is used in an effective way. If there is insuficient traffic to keep all instances busy, you would spin down one of the instances.

Finally, zero-allocation has inherent benefits for energy use. To quote Bernard van Gastel:

> In the computer, 3 things cost energy: calculations, storage, and moving data. A zero-allocation project reduces on 2 of these 3 points: storage and moving data

-- Bernard van Gastel, asisstent professor at Radboud University. His field of expertise is sustainability of software and analysing resource consumption sustainablesoftware.info/about.page

## You have some references, but would you or anybody else be using this in anger at the end of the project?

Yes. Vendr (the current employer of Roc's creator, Richard Feldman) is currently writing an internal tool in Roc. They intend for the application to switch over to the zero-allocation webserver. (this is a recent development since we submitted the application)

But, in general we suspect the end result will still be too experimental for production usage. In particular, the server will lack a good way to support databases (in particular database connection pooling) given the current set of milestones.

Bernard van Gastel wants to measure the energy efficiency of our implementation:

> It will be interesting to measure the final effect on energy consumption in our Software Energy Lab. Web servers are unpredictable in terms of energy consumption. For devices with limited resources, a web server that has a bound on energy is important.