Sodium: an FRP library that spread across nine languages and then stopped moving

A status table instead of a feature list

The README of Sodium is unusual, and the first thing worth noticing is what it does not contain. There is no quick start, no API tour, no installation instructions and no example program. What there is, is a per-language status list.

Each line pairs a language with a judgement. C++ is complete, but the memory management is not quite right yet. C# and F# are complete but not in active development. Java and Scala are complete. Kotlin, TypeScript and Rust are complete in separate repositories. Haskell is deprecated in favour of Heinrich Apfelmus's Reactive Banana, and Embedded C is described as just an experiment.

That list is the project's real documentation, and it is more useful than it first appears, because it tells you not just what exists but what to expect from each port. A port marked complete without the maintenance note is a different proposition from one marked complete but no longer developed, and the difference determines whether you are adopting a library or reading a fixed point in time.

The lineage it names and what it claims for itself

Sodium describes itself as based on Flapjax, Yampa, scala.React and a number of other functional reactive programming efforts, as well as a lot of personal experience. That sentence is a design lineage rather than a feature list, and it locates the library among a family of event and behaviour based approaches to reactive programming.

The framing is worth holding on to when you evaluate the project, because FRP libraries differ enormously in what they mean by the term. Some are pull-based value streams, some are push-based event systems, some model time explicitly with a signal function over time. A library that names Flapjax, Yampa and scala.React as its inspirations is drawing on the event-passing and behaviour lineage rather than the pure signal-calculus tradition.

The other piece of context is the book. The README points readers to Functional Reactive Programming at manning.com, and the repository contains a book directory. For a library whose API surface is not documented in the README, the book is the reference a new user would actually learn from, which is a normal arrangement for research-flavoured projects of this vintage and a real cost for someone who wants a quick lookup instead.

Ports moved to their own repositories, and that changes the upgrade story

Several languages no longer live in this tree at all. The C++ implementation is in a separate sodium-cxx repository, Kotlin is in sodium-kotlin, TypeScript and JavaScript are in sodium-typescript, and Rust is in sodium-rust. What remains here at the top level is a mixture: appveyor.yml for continuous integration, a book directory, a clojure directory, a common-tests directory, a denotational directory, a dotnet directory, an embedded-c directory, a haskell directory, a java directory, a rust directory, a scala directory, a COPYING file and a README.

The split has a practical consequence that is easy to miss. A port in its own repository has its own release cycle, its own maintainer and its own compatibility story, so a change to the shared semantics of the library has to be pushed out to several places. For a user this means the versions of the different ports can drift apart, and the word complete in the status list describes a port rather than a whole.

The common-tests directory in this tree suggests the intended answer to that problem: a shared conformance suite that each port can run, so the ports are checked against the same expectations rather than merely sharing a name. The denotational directory points the other way, at work on the formal semantics of the library rather than on the ports themselves.

The C++ port and its memory management problem

The C++ line is the one with an explicit defect attached: the implementation is complete, but the memory management is not quite right yet. That is a precise and unusual thing to write in a README, and it tells you the port works in the sense that the functionality is there, while the resource handling still needs work.

The C++ port lives in its own repository, sodium-cxx, which means the main tree is not where you will find the code you would compile. Anyone starting with Sodium and C++ is really starting with two repositories and a README that tells them which one to fetch.

The root of the repository uses dotnet for the C# and F# implementations and has appveyor.yml at the top, which is the configuration for a Windows CI service. The presence of that file dates the project and tells you how the build was expected to be checked at the time, which is relevant context for how actively the code is exercised today.

The .NET handover and the Haskell deprecation

Two of the status lines point at other projects, and they are the most actionable sentences in the README.

For .NET, the note says that the .NET version of Sodium is no longer being maintained and asks you to use SodaFlow instead, with a link to morsecode-software.github.io/SodaFlow. The C# and F# source stays in the dotnet folder here and the binaries are published in the SodiumFRP and SodiumFRP.FSharp NuGet packages, so the packages remain available but they are the output of a stopped line of work. A package that still resolves in your restore is not the same as a package that is still being fixed, and this is exactly the case where the difference matters.

For Haskell, the port is deprecated in favour of Heinrich Apfelmus's Reactive Banana. Here the project names a specific successor, which is more useful than a general abandonment note, because Reactive Banana is the Haskell FRP library most people in that ecosystem would otherwise reach for.

Taken together, the two entries are a candid accounting. The library found homes for its ports, and for two of them it points somewhere else. That is a normal outcome for a project of this kind and a useful signal for anyone choosing one today.

What the repository itself does and does not tell you

The licence field on the repository is classified as a custom licence that GitHub cannot classify, and the tree carries a COPYING file rather than a standard LICENSE. The homepage is sodium.nz. There are no GitHub releases, so there is nothing to pin a version to and no changelog attached to a tag, although a ChangeLog file exists in the tree.

The last push to the repository was on 2026-09-28, so the code is not frozen in the archaeological sense. Whether that push represents ongoing work or a periodic tidy-up is not something the README resolves.

What the repository does not offer is the practical documentation a modern dependency needs: no statement of supported language versions, no CI matrix, no security policy, and no guidance on which port is the reference implementation when the status lines are ambiguous. If you are evaluating Sodium for a production dependency, you will be reading the source of the specific port rather than the documentation, and you will be making the maintenance call yourself from the status list and the activity of the port's own repository.

Where Sodium is the wrong choice

The honest reason to look elsewhere is that most of this ecosystem has consolidated. The Haskell line says so itself, pointing at Reactive Banana, and the .NET line points at SodaFlow. If the language you would use is one of those two, the project itself has already told you what to use, and that recommendation carries more weight than any comparison you would make.

For the other ports, the concern is different and is about the shape of the project rather than any single implementation. This is a research-flavoured library that spread widely, and it left a wide set of ports behind in a state that is complete but not uniformly maintained. That is a reasonable thing for a library to be, and it is not what a team with a support obligation wants underneath a production dependency.

The counterargument is real. If you want an FRP model, having a port in your language saves you from writing one, and the shared common-tests suite is evidence that the ports were intended to behave alike rather than to drift. The book gives you the model properly rather than through a scattering of blog posts.

What to decide, then, is whether you are adopting an implementation or a reference. If you need a maintained library with a bug fix path and a release cadence, look at the successor projects the README names, or at a mainstream reactive library for your stack. If you want to understand or extend FRP, and you are willing to read source and maintain a fork if needed, Sodium is a well-documented and deliberately constructed place to start.

Editorial conclusion

Sodium suits a developer who wants a functional reactive programming model with a port already written in their language of choice, and who is prepared to read the library's own status list before choosing it. It does not suit a team that needs a maintained library with a steady release cadence, since the repository has no tagged releases and several ports are marked complete but no longer in active development. Before picking a port, check its status line in the README, confirm the language implementation lives where you expect, and for .NET work follow the pointer to SodaFlow instead, because the Sodium C# and F# ports are stated to be unmaintained.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. SodiumFRP/sodium on GitHub