Fusion: a language whose only job is emitting the same library ten times

One .fu file, ten languages, one command

Fusion is designed for a specific job: implementing a reusable component, that is a library, once and having it translated into C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C.

The unit of work is a library rather than an application. The README's example is a "Hello, world" library written in a syntax that reads like C#:

public class HelloFu
{
    public static string GetMessage()
    {
        return "Hello, world!";
    }
}

and the translation is one command with an explicit target list:

fut -o hello.c,cpp,cs,d,java,js,py,swift,ts,cl hello.fu

The extension after each target name in the `-o` list is the target extension, and `cl` is OpenCL C. You name exactly the languages you want rather than accepting all of them, which matters because each backend is a separate code generator with its own conventions.

The stated goal for the output is specific: lightweight, with no virtual machine, no emulation and no dependencies, human-readable, and fitting well with the target language including naming conventions and documentation comments. The last clause is the one that matters in practice. Generated code that violates local naming style gets rejected in review no matter how correct it is.

The compiler is written in Fusion, with hosts in C++, C#, Java and JavaScript

The repository layout is the most informative thing about the project.

There is `Fut.java`, `fut.cs`, `fut.cpp` and `fut.js`, which are the four host implementations of the compiler. Alongside them sit `libfut.cpp`, `libfut.hpp`, `libfut.cs` and `libfut.js`, the corresponding host libraries. The `Makefile` sets `FUT_HOST = cpp`, so the C++ host is the one the test suite drives by default.

Then the compiler's own sources, written in Fusion: `Lexer.fu`, `Parser.fu`, `Sema.fu` for semantics, `AST.fu`, `SymbolReferenceVisitor.fu`, and one generator file per target. `GenBase.fu` and `GenTyped.fu` are shared, `GenC.fu`, `GenCpp.fu`, `GenCCpp.fu`, `GenCCppD.fu` cover the C family, and `GenCs.fu`, `GenD.fu`, `GenJava.fu`, `GenJs.fu`, `GenPy.fu`, `GenPySwift.fu`, `GenSwift.fu`, `GenTs.fu` and `GenCl.fu` cover the rest.

A bootstrapping compiler written in its own language is the pattern that makes this project more than a code generator demo, because it means the language is exercised as a host language, not only as a source language. The practical payoff for an adopter is narrower: four hosts means the tool can run wherever a runtime is available, and the `ConsoleHost.fu` file at the root is the console front end.

Other host artefacts suggest a focus on native packaging: `fut.spec` is an RPM spec file, `debian/` holds Debian packaging, `win32/` holds Windows resources, and `editors/` holds editor support.

The Makefile is the real test suite: nine toolchains in one file

The build file reveals what the project actually guarantees, and it is worth reading as the specification.

`VERSION = 3.3.8`, matching the published `fut-3.3.8` tag. `prefix := /usr/local` for installation. For C#, the Makefile locates the .NET base path with `dotnet --info`, resolves the reference pack directory under `packs/Microsoft.NETCore.App.Ref`, and then invokes Roslyn directly through `csc.dll` with `-nullable:enable` and an explicit reference list that includes `System.Collections`, `System.Console`, `System.Linq`, `System.Memory`, `System.Runtime`, `System.Text.Json`, `System.Text.RegularExpressions` and `System.Threading`.

That is the whole of the C# toolchain requirement: the .NET SDK must be on PATH, because there is no separate C# compiler to install.

Other tools are invoked by name: `JAVAC = javac` with a check for a Java 21 compiler, `DC = dmd` for D, `SWIFTC = swiftc`, `PYTHON = python3 -B`, and `MYPY = mypy`. Type checking is therefore part of the picture for the Python target rather than an afterthought.

There is a `.csproj` for the C# host and a `package.json` for the JavaScript host, whose name is `fut-js`, marked `"private": true` with version `3.3.8-development` and `"type": "module"`, so the JS host is an ES module rather than a CommonJS package.

One detail worth flagging for anyone reproducing this locally: on Linux the test flags add `-fsanitize=address -g`, and on Darwin the Makefile reaches for ICU at `/opt/homebrew/opt/icu4c`, appending `-licuuc` for the string test cases. So a macOS checkout expects a Homebrew ICU installation.

What the generated output looks like, and who has to maintain it

The output promise and the maintenance cost are the same fact seen from two sides.

Because the output is human-readable source with target naming conventions and documentation comments carried across, the result can be committed to a repository and reviewed like any other code. That is unusual and valuable for a library that has to exist in ten languages, because it means a bug fix in the `.fu` source is a diff you can read in each target.

It also means you own ten codebases. Each generated file will be read, edited or patched by the people who use that language, and the moment someone edits generated output by hand, the next transpile overwrites it. The README does not describe a mechanism for that case.

And because the output is source, nothing is prebuilt for your users. A C library still needs a compiler on the consumer's machine, a Python package still needs a build or a pure-Python layout, a JavaScript library needs a package and a supported Node range, and a Swift or C# component has to compile inside the consuming project. The project removes the duplication in authoring; it does not remove the work in distribution.

For a numeric or string component that is genuinely identical across languages, that trade is worth making. For anything where each ecosystem has an idiomatic way to express the same thing, a transpiled component will look foreign to local maintainers.

Where the practical limits are, and who should not use it

Two limits are visible from the README and repository layout without guessing.

The first is scope. Fusion is for libraries, and the example is a static method returning a string. Nothing in the README describes application packaging, a runtime, a module system or FFI beyond the OpenCL C target. If you want to write a service in Fusion and ship it as a binary, there is no evidence here that this is the tool.

The second is the GPL-3.0 licence. A transpiler that emits source changes who owns the output, and GPL-3.0 on the compiler raises the question of whether the generated files are affected. That is a legal question with a real answer in a qualified opinion, not something to guess at, and it should be settled before a Fusion library is vendored into a proprietary codebase. The licence file is `COPYING` at the repository root.

Beyond that, the ordinary risk applies: a transpiler sits between you and the target language's toolchain, so an upstream language change shows up as a generated-code problem rather than as a compiler message you can read. The project does keep up with releases, with `fut-3.3.8` on 2026-09-21, `fut-3.3.7` on 2026-08-18 and `fut-3.3.6` on 2026-07-14, and the repository is not archived with the last push on 2026-10-14.

Getting started: the playground, the docs directory, and the test corpus

There is no install command in the README. The paths it offers are documentation, a browser playground and the repository itself.

The Fusion Playground at https://fusion-lang.org/playground runs in the browser, with the project homepage at https://fusion-lang.org and further instructions in `doc/getting-started.md`. The repository also ships `hello.fu` at the root, which is the smallest complete program to point the compiler at, and `test/` for the test corpus the Makefile drives.

That last part is the honest answer to "how do I evaluate this". The evaluation is not installing something, it is compiling `hello.fu` with the `fut` binary and reading what comes out for each of the ten targets. For each language the Makefile already encodes what "passing" means: `-Wall -Werror` for C and for C++ with `-std=c++20`, mypy for Python, `javac` for Java, `dmd` for D, `swiftc` with address sanitisation on non-Windows hosts for Swift, and Roslyn with nullable enabled for C#.

If your evaluation criteria include "the generated code passes the target language's strictest common flags", that is exactly what this repository is already measuring, and the tooling names to look for are `make`, `dmd`, `swiftc`, `javac`, `mypy` and a .NET SDK on PATH.

Editorial conclusion

Fusion fits a team maintaining the same numeric or string utility across several languages at once, especially where generated code must read like hand-written code in each target, and where shipping a binary per platform is unacceptable. It does not fit a project with one target language, or one that needs a library distributed through the native package manager of each ecosystem, because the generated artefact is source you have to build, test and maintain downstream. Verify first that `fut -o hello.c,cpp,cs,d,java,js,py,swift,ts,cl hello.fu` produces output you would be willing to review, and that the generated code passes the target language's own tooling, since the compiler makes no claim about that.

Frequently asked questions

Official sources

1. fusionlanguage/fut on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases