solod, a strict subset of Go that compiles down to readable C

Go in, C out, and nothing in between

solod is described as a strict subset of Go that translates to regular C, and the headline in the README is that Go can be a better C. The highlights list is the argument in five lines. Go in, C out, where you write regular Go code and get readable C11 as the output. Zero runtime, with no garbage collection, no reference counting and no hidden allocations. A rich standard library using familiar types and functions ported from Go's own standard library. Native C interop in both directions, calling C from Solod and Solod from C with no CGO and no overhead. And Go tooling works out of the box, meaning syntax highlighting, language server support, linting and modules all behave as they do in a normal Go project. The audience is stated in two sentences, Go developers who want systems level control without learning a new language, and C programmers who like Go's safety, structure and tooling.

A subset on purpose, with the heap made explicit

The language tour in the documentation is the reference for what is and is not allowed, and the summary in the README is unusually informative. Solod supports structs, methods, interfaces, slices, maps, multiple returns and defer. Everything is stack allocated by default, and the heap is opt-in through the standard library, which is the single biggest behavioural difference from Go and the one you will feel first. There is limited support for generics. Concurrency is provided by the standard library rather than being built into the language, so the go keyword and the channel machinery are not part of the language itself. The syntax is strictly Go, with no extensions of their own, and the design document says the project is highly opinionated, that simplicity is key, that heap allocations are explicit, and that the syntax is strictly Go. That last constraint is what makes the project tractable: a translator that has to handle every Go program is a different project from one that handles a well-defined subset.

What the generated C actually looks like

The example in the README is a thread-safe account, and showing the input and the output side by side is the clearest explanation of the design. The Go source imports three Solod packages, solod.dev/so/conc, solod.dev/so/mem and solod.dev/so/sync/atomic, defines an Account struct with an atomic.Int64 balance, and runs a hundred deposits across four worker threads from a pool.

opts := conc.PoolOptions{NumThreads: 4}
pool := conc.NewPool(mem.System, opts)
defer pool.Free()
for range 100 {
    pool.Go(pay, &acc)
}
pool.Wait()

The output is a header and an implementation file, and the naming is systematic rather than opaque. The struct becomes main_Account, the method becomes main_Account_Deposit with the receiver passed as a void pointer, and the standard library calls become namespaced C functions, so atomic_Int64_Add and conc_Pool_Go. The implementation file carries the original comments across, which is the readability claim in practice.

void main_Account_Deposit(void* self, int64_t amount) {
    main_Account* a = self;
    atomic_Int64_Add(&a->Balance, amount);
}

Installing the tool and using it on a module

The command line tool is installed with the usual go install, and the Solod standard library is then added to a Go module.

go install solod.dev/cmd/so@latest

go mod init example
go get solod.dev@latest

The README notes that you can use main or a specific commit hash instead of latest to get the newest development version rather than the latest tagged release. The source you write is ordinary Go with one change, that you import from solod.dev/so/... rather than from the Go standard library, so a program starts like this.

import "solod.dev/so/math"

func main() {
    ans := math.Sqrt(1764)
    println("Hello, world! The answer is", int(ans))
}

Transpiling is one command, and the output lands in the generated directory.

so translate -o generated .

The build and run commands go one step further. so build -o main . compiles the C using the compiler named by the CC environment variable, which defaults to cc, and so run . transpiles, compiles and runs without keeping the binary. One constraint is stated plainly, that all the commands work with Go modules rather than with individual files, so it is so run . and not so run main.go.

Calling C from Solod, and generating bindings for anything else

The interop story is the reason most people would look at this project. The README says C interop in Solod is easy to write and has zero runtime overhead, with a guide in doc/interop.md, and the claim about performance is that Solod shines when it comes to C interop. There are native bindings for a set of popular C libraries, libuv, raylib, sodium and sqlite, each of which has its own repository under the solod-dev organisation. For anything else there is a separate tool, sobind, which generates bindings for a C library automatically from its headers. That is the piece that makes the approach general rather than a curated list, since a codebase that already has C libraries it wants to call does not need each of them to have been prepared for Solod by hand.

The generated C depends on compiler extensions

Solod generates C11 code, and the README is straightforward that it relies on several GCC and Clang extensions. The list is worth knowing before you commit to a toolchain. The output uses binary literals such as 0b1010, statement expressions of the form ({...}) inside macros, the constructor attribute for package level initialisation, auto type for local type inference, typeof for type inference in generic macros, and alloca and variable length arrays for make() and other dynamic stack allocations. The compatibility section in the README is truncated in the documentation, so the supported compiler list is not visible here. The project's own Makefile shows the range it tests against, with a clang mode, a gcc mode that runs inside a docker image of gcc 15.2.0, an analyse mode that turns on the GCC analyzer with fortified source, a fast mode without the sanitizers, and a bare mode that uses zig cc targeting wasm32-freestanding with no standard library. It also has targets for riscv64 and i386 docker builds and a Windows build run under wine. The practical advice is to try the tool on your target toolchain early, since this is where the compatibility surprises live.

Learning resources, testing and where the project is going

The documentation set is well organised for a young project. There is a language tour in doc/spec.md for the features and the limitations, a standard library guide in doc/stdlib.md, and a playground at codapi.org/so where you can run code or look at the translated C without installing anything. A separate repository, solod by example, holds annotated example programs, and there is an AI skill repository for people who would rather have the code written for them. Testing has its own document, because the so test command and the so/testing package are the Solod way, with the useful twist that Solod code is also valid Go code, so you can still use go test where it fits, and those tests are never transpiled, which means they may use all of Go. The FAQ, the design notes and the benchmark write-up are separate documents, and the benchmark document is where the claim lives that Solod is on par with or faster than Go on regular Go code. The releases show the scope growing quickly, with v0.2.0 in June 2026 adding networking, UUIDs and WebAssembly, v0.3.0 in July adding concurrency, JSON and testing, and v0.4.0 in September improving the C interop. The repository is not archived, the last push was on 2026-10-09, and the licence is BSD-3-Clause.

Editorial conclusion

solod fits a Go developer who wants to ship something into an environment where a C toolchain is the only option, an embedded target, or a codebase with an existing C interface, and it fits a C programmer who wants Go's structure and tooling without the garbage collector. It does not fit a project that wants the whole of Go, since the subset is strict and concurrency comes from the library rather than the language, and it does not fit a team that has to target a strictly conforming C compiler, because the output leans on GCC and Clang extensions. Verify three things before you start: which of your dependencies fit inside the subset, since generics support is limited and the language tour is the reference, whether your target compiler accepts the extensions the generated code relies on, including binary literals, statement expressions, constructor attributes, auto type, typeof and variable length arrays, and how the heap behaves in your program, since heap allocation is explicit rather than automatic and that changes how you write code.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. solod-dev/solod on GitHub