DEV Community: Jayson Reis

Beni: a typed functional language for the browser, with no async/await

Jayson Reis — Fri, 16 Oct 2026 18:37:04 +0000

Beni is a statically typed functional language that compiles to JavaScript. My friend Cesar (@canassa) started it, and I've been working on it with him. It's pre-1.0, but it's far enough along that we'd like people to try it.

You can try it in the playground without installing anything. The compiler runs in the browser as WebAssembly. The code is at github.com/canassa/beni.

Why Beni?

Elm showed that a web app can run for years without a runtime error. Most web apps are written in TypeScript instead, and its types don't always mean what they say.

Beni started as an Elm clone for the browser and turned into an experiment in how far current tools can be pushed, borrowing from Roc, Solid, Effect and Zig. It has three goals, and the rest of this post takes them one at a time.

TypeScript's types can lie

TypeScript doesn't try to be sound. It's listed as a non-goal, and it's easy to end up with a string[] that holds a number:

const names: string[] = ["ada", "grace"]
const items: (string | number)[] = names // allowed
items.push(42)

for (const name of names) {
  console.log(name.toUpperCase()) // compiles, then throws on 42
}

This compiles without a warning, because arrays are covariant in TypeScript. And when the checker does complain, it's easy to switch it off with as or any. That matters more now that agents write a lot of code unattended: at the first sign of a type error, an agent will often reach for as any and move on. Errors aren't in the types either. Nothing in a function's signature says it can throw, so the compiler can't tell you which failures you haven't handled.

Beni has no any, no casts and no subtyping, so a List String only ever holds strings, and there's no escape hatch for a person or an agent to reach for. Failures are values in the type, like the Result that fetchName returns further down. Data from outside, like JSON, comes in through a schema that checks it. And because Beni uses Hindley-Milner inference, the compiler works out the types, so you get all this without writing annotations everywhere.

Programs that don't crash

The first goal is the one Elm already reached: if a program compiles, it shouldn't crash. Beni keeps that rule and tightens it where your code meets the browser.

Runtime errors

Beni has no null, undefined or exceptions, and a case has to cover every variant. If you add a variant, the compiler lists every place that needs updating. This works the same as in Elm.

Beni code can't call JavaScript directly. Browser and Node APIs are wrapped by hand in the platform layer, and each failure an API documents is returned as a typed error such as QuotaExceeded or NotFound. Catch-all try/catch isn't allowed there. If an API fails in a way its docs don't mention, we treat it as a bug in Beni, and the program stops instead of continuing in a bad state.

So the guarantee covers the code you write. The platform layer is written and reviewed by hand, and the compiler doesn't verify it.

Error messages

Error messages get the same attention as in Elm, and almost every one has a test that pins its wording. If you pass foldl a lambda that takes one argument instead of two, you get:

I need a function of 2 arguments, and this one takes 1.

With currying, the compiler couldn't give that message, which is one of the reasons Beni dropped it.

No automatic currying

In a curried language, a lambda with a missing parameter often still type checks, because the compiler assumes you meant to return a function. The error shows up later, usually far from the mistake. Without currying, a one-argument function and a two-argument function have different types, and the error points at the lambda.

Partial application is written with _, as in List.map xs (scale 2 _). The _ can stand for any argument, including the first. What you lose is point-free style.

Output as small as hand-written JavaScript

The second goal is output that's about as small and fast as JavaScript you'd write by hand.

Compilers are a good thing

A TypeScript project usually needs a type checker, a bundler, a minifier, a formatter and a dev server. Beni is one binary that does all of it.

We own the language as well as the compiler, so the compiler knows much more about the code than a JavaScript bundler does. It has the types, and it infers which functions are pure. That opens up optimisations a bundler can't safely do: removing code nothing uses, inlining functions, reordering and rewriting them to get the smallest bundle possible. Some of this is built, and a lot of it is still research.

Compilers for C and Haskell have done this kind of whole-program optimisation for decades. We want to see how much of it works for code that ships to a browser.

Immutable lists without a trie

Every value in Beni is immutable, lists included. The usual way to make immutable lists fast is a persistent data structure like a trie, but in the browser that's more code to download: 1 to 1.5 kB with brotli, even for a minimal one.

Beni uses plain JavaScript arrays instead. An ownership checker, similar to Rust's borrow checker but with no annotations, works out when nothing else can see a list, and then the update happens in place. When it can't prove that, you get a compile error and add a List.copy.

Its core rules are modelled in Lean 4. All that to save a kilobyte and a few nanoseconds is a bit crazy, and we know it.

A language that gets out of your way

The third goal is that safety shouldn't come with ceremony, and that the compiler should be fast enough that you never wait on it.

No async/await

In TypeScript, once a function awaits something, every function that calls it has to become async too:

async function fetchName(id: number): Promise<string> {
  const res = await fetch(`/users/${id}`)
  return res.text()
}

// greet has to be async now, and so does everything that calls it
async function greet(id: number): Promise<string> {
  try {
    return `Hello, ${await fetchName(id)}`
  } catch {
    return "Hello, stranger"
  }
}

Bob Nystrom called this function coloring in What Color Is Your Function?. In Beni the same code looks like this:

fetchName : Int → Result Http.Error String
fetchName id = Http.get { url = "/users/${String.fromInt id}", expect = Http.expectString }


greet : Int → String
greet id =
    case fetchName id of
        Ok name →
            "Hello, ${name}"

        Err _ →
            "Hello, stranger"

fetchName waits on the network, and greet calls it like any other function. An HTTP failure comes back as a Result, so the compiler makes you handle it.

The compiler works out which functions might wait. Each function gets two flags, whether it can suspend and whether it has side effects, and you don't write them anywhere. Functions that can suspend are compiled to run on a small fiber runtime that ships with the program. Functions that can't are compiled to plain JavaScript. Higher-order functions only need one version: List.map takes a callback that makes network requests the same way it takes one that doesn't.

The runtime is modeled on Effect, so timeouts, retries, cancellation and concurrency limits are library functions. This example fetches up to 4 pages at a time, retries each one with exponential backoff, and stops after 10 seconds:

backoff : Schedule.Schedule Http.Error
backoff = Schedule.exponential (Duration.millis 100) 2.0 ▷ Schedule.upTo (Duration.seconds 5)


loadAll : List Int → Maybe (Result Http.Error (List String))
loadAll pages = Task.timeout (Duration.seconds 10) λ⊤ →
    Task.forEachOk pages 4 λn → Task.retry backoff λ⊤ → fetchPage n

A cancelled fiber always runs its cleanup. The runtime with these pieces is about 2.1 kB, compared to about 27 kB for Effect.

The downside is that the source doesn't show where a function might suspend. Where that matters, a sync block tells the compiler the code inside must never suspend, and the compiler checks everything that code calls.

Static dispatch

Beni has static dispatch, modeled on Roc's. A type's methods are the public functions of the module that defines it, so v.add w calls Vec.add v w, resolved at compile time. Generic code can ask for a method with a where a.add : a, a → a clause. == and < call the type's eq and compare, which records and custom types get automatically.

This fixes two things that come up a lot in Elm. Custom types can be Dict keys and can be sorted, without Elm's special comparable type. And a method can be picked by the type you expect back, which is how JSON decoding works: Json.decode text finds the decoder from the result type, so you don't write one by hand for every record.

You get most of what type classes give you, without instances, orphan rules or the compile-time cost that comes with them.

Unicode syntax

Maybe the most controversial decision 😅

We use Unicode symbols where we think they make code easier to read. It's 2026, and editors and terminals render them fine.

Also, we're having fun. What's the point of writing your own language if it looks like every other C clone?

Haskell writes a lambda as \x -> … because the backslash looks a bit like a λ. Beni just uses λx → ….
Tuple types are written Int × String. Function types already use commas for multiple arguments, so Int × Int → Int takes one pair and Int, Int → Int takes two arguments.
Functions that return nothing useful get their own symbol, ⊤, as in String → ⊤.
The pipe is ▷.

For the hardcore folks still typing code by hand: write -> and beni fmt --migrate-unicode turns it into → for you. Editor plugins will do the same as you type, once they exist.

Batteries included

JSX

Markup is part of the language and is type checked against the elements the platform defines. It compiles the way Solid does: each template is cloned from HTML once, and only the parts that depend on changed values get updated. There's no virtual DOM. Records are immutable and unchanged fields keep their identity, so one reference comparison per dynamic part is enough to tell whether it changed.

import Html exposing (Html)
import Tea


type Msg
    = Increment
    | Decrement


update : Msg, Int → Int
update msg count =
    case msg of
        Increment →
            count + 1

        Decrement →
            count - 1


view : Int → Html Msg
view count =
    <main>
        <button onClick={Decrement}>-</button>
        <span>{count}</span>
        <button onClick={Increment}>+</button>
    </main>


main : Tea.Program
main = Tea.sandbox { init = λ⊤ → 0, update = update, view = view }

Try the counter in the playground

Schemas

Almost every project I've worked on has needed a validation library like Zod or Joi. In Beni, schemas are part of the language. Because the compiler handles them, each schema is compiled into its own small, specialised JavaScript parser. You ship code only for the schemas you actually use, not a whole validation library.

schema Item =
    id : Int
    title : String
    done : Bool


firstTitle : String → String
firstTitle json =
    case Item.parse json of
        Ok item →
            item.title

        Err _ →
            "invalid"

Run this example in the playground. It parses one valid and one invalid JSON string.

Often you don't need a schema at all. Json.decode works out the type from how your code uses the result, and checks the JSON against it. If your code reads user.name as a string, the JSON has to have a name that's a string, and you never write a type annotation. When decoding fails, each error says whether the text wasn't JSON at all or the JSON didn't fit, along with where and why. This small page in the playground shows it: type into the box, and it shows the name in capitals, "invalid JSON" when the text can't be parsed, or "not a user" when it parses but doesn't fit.

When the JSON doesn't match your types, for example renamed keys or default values, you write a schema.

Platforms

The language itself knows nothing about where it runs. That idea comes from Roc. A platform supplies the program's main, its effects and its bindings to JavaScript. Beni ships platforms for Node and for the browser, with or without The Elm Architecture.

This is also how Beni gets out of Elm's walled garden. In Elm, your code can't call JavaScript, and ports are the only way out. In Beni, every line of JavaScript lives in a platform, wrapped so that each failure comes back as a typed value. When you need something the shipped platforms don't cover, like an npm library or a browser API, you add your own platform layer to the project. Libraries stay pure Beni, so a dependency can't break the guarantees.

We want people to fork the shipped platforms and change them for their own needs. A Bun or Deno platform could expose what those runtimes offer beyond Node. A node-static platform could render each route of an app into a static HTML file.

Apps built with Beni

The examples site has three apps, each built with --release and served as is, without a bundler:

Conduit, the RealWorld Medium clone, structured like elm-spa-example
Bike Wars, a two-player light-cycle game ported from Elm
Sternhalma, Chinese checkers for up to six players, also ported from Elm

Current state

Beni is pre-1.0, and the syntax still changes often. There's no package manager, editor support, user documentation or test runner yet. It's not ready for production.

Trying it

The easiest way is the playground. Pick a sample such as Counter or TodoMVC, edit it, and share the link. You can add your own CSS too.

To run it locally, the repo pins Zig 0.17 and Node 24 with a Nix flake (direnv allow puts them on your PATH):

git clone https://github.com/canassa/beni && cd beni
zig build
./zig-out/bin/beni new --platform=browser-tea hello
./zig-out/bin/beni serve hello

serve rebuilds and reloads the page when you save.

If something breaks, or an error message doesn't make sense, please open an issue. We'd especially like to hear from Elm users about the changes, removing currying in particular.

Connecting to services that require jumphost from terraform

Jayson Reis — Sun, 29 Aug 2021 20:20:03 +0000

If you have services that require jumphosts to connect to them because there is no VPN, direct access, or configured zero trust mechanisms, it used to be a bit painful doing it with terraform.
Some would use things like null_resource to start the ssh command but still having a static number of tunnels.
Thinking of that use case, I've created a terraform provider that can play well with dependencies on resources being created like databases instances or any other services that are to be provisioned and will have a non deterministic hostname.

The cool thing is that the provider connects once to the jump host and you can have an arbitrary number of tunnels that connect to remote servers and assign a local port by using data sources. The provider itself only connects to the jump host when the first data source is being read, this will make sure that the connection only starts when you have a definitive hostname (i.e. an RDS instance that finished being provisioned). Once the jump host connection is done, many data sources can create tunnels using the same jump host connection.

how to use it

Cutting to the chase, to use it you need to configure the provider itself with the following:

terraform {
  required_providers {
    jumphost = {
      source = "jaysonsantos/jumphost"
      version = "0.0.2"
    }
  }
}

Next, configure where your jumphost is:

provider "jumphost" {
  hostname = "my-server"
  username = "ubuntu"
}

Then configure the tunnels you are going to need to use:

data "jumphost_ssh" "my_database" {
  hostname = aws_db_instance.my_database.address
  port     = aws_db_instance.my_database.port
}

// Configure a postgresql provider to use the tunnel

provider "postgresql" {
  host = "localhost" // As this will be tunneled, just use localhost
  // The port usage bellow makes sure that the provider only gets created
  // when after the database is created and the tunnel is established
  port = data.jumphost_ssh.my_database.local_port // This is the tunneled port
  // omitted the rest of the parameters
}

Or you can also use to reach services that you already have the host bust still need to proxy through the tunnel.

data "jumphost_ssh" "my_api" {
  hostname = "httpbin.org"
  port     = 80
}

data "http" "my_api" {
  url = "http://localhost:${data.jumphost_ssh.my_api.local_port}/method"
}

output "api_response" {
  value = data.http.my_api.body
}

I hope this can help other people out there and don't forget to send issues and pull requests to my github.

Using terraform's remote-exec provider with AWS SSM

Jayson Reis — Sat, 20 Feb 2021 07:48:40 +0000

In an effort to harden our infrastructure at Grover, we decided to block all SSH connections, from both public and private subnets. Instead, we want to use AWS's SSM agent to manage SSH connections so we don't have to handle each of the machine's authorized keys. Users can connect with the provided tool as long as they have the right IAM permissions.

This worked great! I mean, almost perfect. Well, some stuff broke. There were problems because some of our terraform modules used provisioners with remote-exec so we have fine-grained control on when the creation of the machine failed.

To fix it, we tried to set up an ssh_config and change the host where it tried to connect, so terraform could execute the proxy command to connect and then do its thing. But it seemed that terraform was not reading the config at all so that just failed. I assumed that terraform was using some go module to connect and not something like libssh.

Then I thought I could run ssh on a local-exec provider with a random port forwarding to the target machine, then going to the background so it would go to the next provisioner on our module. But instead of going to the next step, it would always get stuck, waiting for it to finish somehow no matter how I tried running it. I tried ssh -f, nohup ssh -f & && disown, but I was getting nowhere and decided to take a look on the go code.

First I saw that the code opens a pipe.

pr, pw, err := os.Pipe()

But a few lines later it just waits for the process to finish.

err = cmd.Wait()

And I thought: "Well when I disown, the bash program should have finished without any children as disown would move the subprocess up into the tree". And it indeed was working properly.
A few lines later, I noticed a select on a couple of channels.

select {
    case <-copyDoneCh:
    case <-p.ctx.Done():
}

See that copyDoneCh? It is used on a function that keeps reading the pipe until it is finished and then it gets closed when the function is finished.

func copyUIOutput(o provisioners.UIOutput, r io.Reader, doneCh chan<- struct{}) {
    defer close(doneCh)
    lr := linereader.New(r)
    for line := range lr.Ch {
        o.Output(line)
    }
}

Remember that opened pipe on the top? Well, my naïve approach with ssh -f was inheriting the main process' pipe and never closing it when ssh went to the background.
So, it was a matter of making the process not inherit them so my bash script could and terraform could move to the next step.

To test this, you can start with a null_resource.

resource "null_resource" "test" {
  provisioner "local-exec" {
    command     = file("ssh-port-forward.sh")
    interpreter = ["bash", "-c"]
    environment = {
      INSTANCE_ID = "i-bebacafe"
      USERNAME    = "your-user"
      RANDOM_PORT = random_integer.ssh_port.result
    }
  }

  provisioner "remote-exec" {
    inline = ["echo hello world"]
    connection {
      host = "127.0.0.1"
      port = random_integer.ssh_port.result
      user = "your-user"
    }
  }
}

resource "random_integer" "ssh_port" {
  min = "10000"
  max = "60000"
}

And then for the bash script that creates the port fowarding.

#!/usr/bin/env bash
set -ex
test -n "$INSTANCE_ID" || (echo missing INSTANCE_ID; exit 1)
test -n "$USERNAME"    || (echo missing USERNAME; exit 1)
test -n "$RANDOM_PORT" || (echo missing RANDOM_PORT; exit 1)

set +e

cleanup() {
    cat log.txt
    rm -rf log.txt
    exit $!
}

for try in {0..25}; do
    echo "Trying to port forward retry #$try"
    # The following command MUST NOT print to the stdio otherwise it will just
    # inherit the pipe from the parent process and will hold terraform's lock
    ssh -f -oStrictHostKeyChecking=no \
        "$USERNAME@$INSTANCE_ID" \
        -L "127.0.0.1:$RANDOM_PORT:127.0.0.1:22" \
        sleep 1h &> log.txt  # This is the special ingredient!
    success="$?"
    if [ "$success" -eq 0 ]; then
        cleanup 0
    fi
    sleep 5s
done

echo "Failed to start a port forwarding session"
cleanup 1

Notice how on the ssh command I redirect all the output to a file with &> log.txt? This is to avoid its process to inherit the pipes I was talking about before.
After this, your plan should just work the way you expect it.

null_resource.test: Creating...
null_resource.test: Provisioning with 'local-exec'...
null_resource.test (local-exec): Executing: ["bash" "-c" "#!/usr/bin/env bash\nset -ex\ntest -n \"$INSTANCE_ID\" || (echo missing INSTANCE_ID; exit 1)\ntest -n \"$USERNAME\"    || (echo missing USERNAME; exit 1)\ntest -n \"$RANDOM_PORT\" || (echo missing RANDOM_PORT; exit 1)\n\nset +e\n\ncleanup() {\n    cat log.txt\n    rm -rf log.txt\n    exit $!\n}\n\nfor try in {0..25}; do\n    echo \"Trying to port forward retry #$try\"\n    # The following command MUST NOT print to the stdio otherwise it will just\n    # inherit the pipe from the parent process and will hold terraform's lock\n    ssh -f -oStrictHostKeyChecking=no \\\n        \"$USERNAME@$INSTANCE_ID\" \\\n        -L \"127.0.0.1:$RANDOM_PORT:127.0.0.1:22\" \\\n        sleep 1h &> log.txt\n    success=\"$?\"\n    if [ \"$success\" -eq 0 ]; then\n        cleanup 0\n    fi\n    sleep 5s\ndone\n\necho \"Failed to start a port forwarding session\"\ncleanup 1"]
null_resource.test (local-exec): + test -n i-bebacafe
null_resource.test (local-exec): + test -n your-user
null_resource.test (local-exec): + test -n 45160
null_resource.test (local-exec): + set +e
null_resource.test (local-exec): + for try in {0..25}
null_resource.test (local-exec): + echo 'Trying to port forward retry #0'
null_resource.test (local-exec): Trying to port forward retry #0
null_resource.test (local-exec): + ssh -f -oStrictHostKeyChecking=no your-user@i-bebacafe -L 127.0.0.1:45160:127.0.0.1:22 sleep 1h
null_resource.test (local-exec): + success=0
null_resource.test (local-exec): + '[' 0 -eq 0 ']'
null_resource.test (local-exec): + cleanup 0
null_resource.test (local-exec): + cat log.txt
null_resource.test (local-exec): + rm -rf log.txt
null_resource.test (local-exec): + exit
null_resource.test: Provisioning with 'remote-exec'...
null_resource.test (remote-exec): Connecting to remote host via SSH...
null_resource.test (remote-exec):   Host: 127.0.0.1
null_resource.test (remote-exec):   User: your-user
null_resource.test (remote-exec):   Password: false
null_resource.test (remote-exec):   Private key: false
null_resource.test (remote-exec):   Certificate: false
null_resource.test (remote-exec):   SSH Agent: true
null_resource.test (remote-exec):   Checking Host Key: false
null_resource.test (remote-exec): Connected!
null_resource.test (remote-exec): hello world
null_resource.test: Creation complete after 3s [id=1103075062717627803]

I hope this helps someone out there as it took me a bunch of hours to figure out what the problem was.