Cone: a systems language with four memory management modes, still under development

Memory management as a language feature you switch on

Cone is a fast, fit, friendly, and safe systems programming language, and the first item in its feature list is do-it-your-way memory management. That phrase is doing more work than it appears to, because the list under it is where the design becomes concrete.

When finished, Cone will support safely manage memory your way, and the ways offered are a lexical, single-owner strategy for performance, a ref-counted or tracing garbage collector for flexibility, lifetime-constrained references for performance and simplicity, and custom allocators such as pools and arenas for performance. Those are four different models of ownership presented as a choice within one language rather than four separate languages with separate toolchains.

The point is that the cost profile of memory management differs by workload. A single-owner lexical scheme gives you performance with no reference counting overhead and no collector pause. A tracing collector gives you flexibility at the price of unpredictable pauses and a harder memory story. Constrained lifetimes let the compiler reason about what is still live. Pools and arenas let you control allocation behaviour in a hot loop.

Every other systems language picks one of these for you. That is the differentiator, and it is also the thing to be sceptical about, because a language that offers a menu of memory models is a language whose interactions between those models have to be specified carefully, and the documentation here describes the intended feature set rather than a shipped, settled design.

The rest of the language, and what is promised rather than shipped

The README is careful with tense, and that matters for an evaluator. It says that when finished, Cone will support these features, and then lists them.

Lightweight concurrency is the second area, with co-routines, threads and actors, and lockless and locked permissions for safe data sharing. There is compile-time memory, type, and concurrency safety, and a robust type system with sum types, structs, arrays, slices, ranges and aliases, plus struct subtyping via trait with ampersand delegated inheritance, and methods attachable to any nominal type.

The language surface also includes modules, macros, templates and meta-programming, extensible pattern matching through match blocks using custom match methods with content extraction during matching, functions, methods and closures with multiple return values and implicit return, computed properties, a with block for context management, and a set of concision features: this-implied prefix operators for method cascading, operator overloading, type inference, parallel assignment, an auto-detected off-side rule, and blocks and if as expressions. Text strings and variable names are Unicode-aware, using UTF8.

The interesting structural point is the off-side rule being auto-detected. Most languages with significant indentation either require it or do not have it. Auto-detection means the compiler works out the layout, which is friendlier for a mixed audience and considerably harder to implement.

The summary line in the README is the one to keep: the Cone compiler is currently under development, and the current status and next steps are documented in PLAN.md. Every feature above is a statement of intent. The repository tree confirms the scale of the work, with compiler/, packages/, samples/, test/, tools/, doc/, conesite/ and workitems/ directories, and a Cone.sln with Visual Studio project files, so this is a real codebase rather than a sketch, but a codebase mid-construction.

Building it needs LLVM with three targets

The build is the clearest signal of the project's maturity, because it requires a specific, recent LLVM with three target backends enabled.

The build depends on LLVM 23.1, built with the X86, WebAssembly and SPIR-V targets, and the test suite compiles for all three. On Windows the instructions use CMake with the Ninja generator from a VS 2022 x64 prompt.

	cmake -S . -B build\x64-release -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_DIR=<llvm root>\lib\cmake\llvm
	cmake --build build\x64-release

Linux and WSL in Windows are documented for x86-64 with Ubuntu 24.04 as the measured configuration, with LLVM 23.1 from apt.llvm.org and cmake, ninja-build and build-essential.

	cmake -S . -B build/x64-release -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_DIR=/usr/lib/llvm-23/lib/cmake/llvm
	cmake --build build/x64-release
	python3 test/run.py --conec build/x64-release/conec

Mac OS is the shortest path, with CMake auto-detecting LLVM.

	brew install --with-toolchain llvm
	llvm-config --bindir

followed by cmake and make. And there is a memory warning worth knowing: linking LLVM's static components takes about 850 MB of memory, and on a small machine changing the target_link_libraries call in CMakeLists.txt to link the shared libLLVM.so instead brings that down to about 100 MB, a change the author recommends keeping local.

The build also produces conec, the compiler, and the test suite runs it through test/run.py.

The standard library, and how much is actually there

The Linux section of the build notes contains the most concrete description of what works today, and it is worth reading as a status report rather than a feature list.

A plain program compiles, links and runs, and so do threads, the sync package's locks and channels, and actors, with the thread, sync and actors packages binding pthreads and the futex. The operating system layer follows: fs, path, env, process and posix over POSIX calls, and iocore for sockets, UDP, timers and files over epoll, with aio, http1 and httpconn on top.

The honest line in the middle is that TLS on Linux is not built yet. That is a significant gap for a language that otherwise wraps pthreads, the futex and epoll. It also narrows what the HTTP packages can be used for.

There is a second operational detail that says a lot about the project's stage. conec makes position-independent code by default on Linux, the way the usual cc links position-independent executables, and the --nopic flag opts out. Building a systems language around LLVM 23.1 means it inherits the LLVM ecosystem's conventions, which is both its strength, since the WebAssembly and SPIR-V targets come along for free, and its cost, since an LLVM major version bump is a migration rather than an update.

The WebAssembly and SPIR-V targets are what make the web3d topic tag and the sample directories meaningful: samples/oslayer/ and samples/webgl/ show the intended use of the browser target, and the manual's source is in doc/manual/.

Where Cone stands against the alternatives

There are three limits, and the first one is simply that the language is unfinished.

The first is that a feature described as a planned feature is not a feature you can rely on. The README frames the whole language surface as what Cone will support when finished, and the roadmap is PLAN.md. Anything you write against it today is written against a design that is still moving, which for a systems language is a much bigger caveat than it would be for a library, because the semantics of ownership and lifetimes are the parts you cannot easily patch later.

The second is the toolchain requirement. LLVM 23.1 with three backends is a heavy prerequisite for a language whose distribution is a source repository rather than a package. There is no binary release, no tagged release, and no version to pin; the last push was on 2026-10-20 and the repository has no GitHub releases. Every build is from the tip of master.

The third is the memory management feature itself, and it cuts both ways. A language where you choose between four ownership models is attractive for a systems programmer who knows their workload. It is also a larger surface to learn, and the interactions between a lexical scheme and a tracing collector in the same program are where the specification will be hardest to get right.

The alternative to compare against is not another small language but the pair of established choices. Rust gives you one ownership model, checked at compile time, with a borrow checker that is difficult but well-specified. C gives you none, and you manage lifetimes yourself with a debugger. Cone's proposition is that the choice belongs to the programmer rather than the language, which is a defensible position in a domain where workloads genuinely differ, and is a real gap in the current landscape. The evidence for whether the gap is worth the cost is what the compiler actually does once it is finished.

Editorial conclusion

Adopt Cone only if you are evaluating systems languages and want to compare its memory management choices against what Rust or C++ give you, since the language is still under development and the documentation says so plainly. Do not build a production system on it yet. Before spending time, read PLAN.md for the current status, check that your toolchain has LLVM 23.1 with the X86, WebAssembly and SPIR-V targets, and note the last push was on 2026-10-20 with no GitHub releases to pin against.

Frequently asked questions

Official sources

1. Issues
2. jondgoodwin/cone on GitHub
3. License: MIT
4. README