# Neva: a statically typed dataflow language that compiles to Go

> Neva replaces step by step control flow with a graph of nodes passing messages, and everything in that graph runs in parallel by default. Here is what the repository documents, how to get the CLI installed, and where the approach costs you.

**nevalang/neva** — Dataflow programming language where you write a program as a message-passing graph and everything runs in parallel by default. It has strong static types, compiles to machine code, interoperates with Go, and supports visual programming with a node editor. Extremely LLM-friendly too.

- Repository: https://github.com/nevalang/neva
- Website: https://nevalang.org
- Stars: 1,082 · Forks: 40
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nevalang-neva

## What Neva actually replaces

Neva is a statically typed, compiled dataflow programming language. The README states the shift plainly: instead of writing step by step instructions, you create networks of nodes that exchange messages through ports. That is the whole pitch, and it is a real paradigm difference rather than a syntax preference.

In a control flow language you decide the order. In Neva the order is a consequence of how ports are wired. The README's list of motivations is unusually candid about why the author built it: control flow is well established while dataflow is underrepresented, existing visual tools lack the expressiveness of traditional languages, and many languages treat concurrency as an advanced feature rather than the default.

The audience follows from that. This is for people who already accept Go's goroutines and channels as a reasonable runtime model and want a language where that model is the surface syntax instead of a library. It is also aimed at anyone who wants to program visually without giving up static types, though the README marks the visual editor as WIP, so that half is not something to plan around yet.

## How a Neva program becomes a binary

The README's architecture diagram shows a three stage pipeline inside the compiler: parser, then analyzer, then backend. The backend emits Go source. That Go source is described as clean and dependency-free, and it uses goroutines and channels for message passing. The Go compiler then produces the final artifact, and the diagram lists both machine code and wasm as targets.

So Neva is not a runtime you embed. It is a source to source compiler that delegates scheduling, garbage collection and code generation to the Go toolchain. The go.mod file confirms the dependency direction: the repository depends on go-git, antlr4-go/antlr for the grammar, urfave/cli for the command line, and testify for tests. None of that ships in your compiled program, which is the point of the dependency-free claim.

The parser is generated from an ANTLR grammar. The Makefile has an antlr target that runs antlr4 -Dlanguage=Go -no-visitor -package parsing ./neva.g4 -o generated from inside internal/compiler/parser. That tells you the grammar file is the source of truth for the syntax, not the documentation.

A minimal program in the README imports fmt and runtime, defines Main with a start input and a stop output, and wires a string literal into println:data. If printing fails, println:err goes to panic. The failure path is a port, not an exception.

## Installing the Neva CLI and running Hello, World

The Makefile documents the install path. The install target runs go install ./cmd/neva, and the comment above it says this builds the CLI for the host OS and puts it on your PATH. Since the module is github.com/nevalang/neva, you need a Go toolchain new enough for the go 1.27 directive in go.mod.

```bash
go install ./cmd/neva
```

Run that from a clone of the repository. Once it finishes, the neva binary is in your GOPATH bin directory, which should already be on PATH if you have installed Go tools before.

The README gives this Hello, World program. It imports fmt and runtime, declares Main with one input and one output, and connects three nodes.

```neva
import {
  fmt
  runtime
}

def Main(start any) (stop any) {
	println fmt.Println
	panic runtime.Panic
	---
	:start -> 'Hello, World!' -> println:data
	println:res -> :stop
	println:err -> panic
}
```

Read the connections as data flow. The start port of Main feeds the string literal, which feeds the data port of println. The res port of println feeds stop. The err port feeds panic. Nothing in that block says which of those happens first, because the wiring is the order.

For a second program, the repository ships an examples directory. The Makefile's neva-fmt target shows the formatter invocation, which is also the fastest way to check that your local copy of the CLI works:

```bash
go run ./cmd/neva fmt -w
```

The fmt subcommand takes -w to write changes and -check to verify without writing. The Makefile uses -check in CI, so formatted source is an enforced convention rather than a suggestion.

## Go interop is the pragmatic part

The feature list puts Go interop alongside the compiler and the runtime: call Go code from Neva and vice versa, described as enabling gradual adoption and reuse of the ecosystem. That is the most useful claim in the README for anyone evaluating this seriously.

Gradual adoption is the right framing. You do not rewrite a service in Neva. You write the concurrent, message-shaped part as a graph and call into existing Go packages for everything else. The compiler already depends on Go's standard library for its own operation, and the generated code is Go, so the boundary is not a foreign function interface with marshalling overhead. It is the same language at the output.

The flip side is that the interop boundary is where the documentation is thinnest in what the README shows. There is no example in the README of a Neva program calling a Go function or a Go program embedding a compiled Neva component. The examples directory listing includes interfaces and advanced_error_handling, which suggests the language has the machinery, but you will be reading those files rather than the README to learn the calling convention.

## Where Neva is the wrong tool

Dataflow is a poor fit for anything that is genuinely a sequence. Reading a config file, validating it, then opening a connection is a control flow problem, and expressing it as a graph adds ports and wiring without removing the ordering constraint.

The README is honest about the maturity of its own headline features. Hybrid programming, the text and visual editor combination, is marked WIP. The version number is the other signal: v0.41.0 shipped on 2026-08-08, after v0.40.0 on 2026-07-31 and v0.39.0 on 2026-07-06. Three minor releases in roughly five weeks is a fast cadence, and fast cadence on a language means syntax and standard library names can still move under you.

There is also a debugging cost that the README does not address. When everything runs in parallel by default, a bug that depends on message arrival order is harder to reproduce than a stack trace in sequential code. The README does not document a debugger, a step mode, or a trace facility, and no such tool appears in the top level repository entries. That absence is worth weighing before you commit a team to it.

Finally, if your concurrency needs are one background worker and a channel, Neva is a large dependency for a small problem. Go already has the primitives.

## Neva against Flow Based Programming tools

The topics list on the repository includes fbp and flow-based, so the comparison to Flow Based Programming is intended. Classical FBP, as described in the literature around it, treats the network as components connected by bounded connections, with the runtime scheduling the components and backpressure arising from the connection buffers. Neva keeps the graph, the nodes and the ports, and departs on the execution model: it compiles to Go and uses goroutines and channels, so the scheduler is the Go scheduler and the buffers are channel buffers.

That difference matters in practice. Classical FBP runtimes tend to be interpreted and language agnostic, with the network defined in a separate description format. Neva is a compiled language with its own syntax, its own static type checker, and its own analyzer stage before the backend emits Go. You get compile time errors about port types, which an interpreted FBP network generally does not give you.

Against a general purpose language with a dataflow library, the difference is the reverse. A library gives you dataflow as an option inside a language you already know. Neva gives you dataflow as the only option and asks you to learn the syntax, the formatter, the CLI and the compiler's error messages in exchange for the guarantee that nothing is sequential unless you wire it that way.

## Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-08-23. That is recent enough that the project is clearly being worked on, and the release history backs it up: three minor versions between 2026-07-06 and 2026-08-08.

For upgrade cost, the version numbers are the thing to watch. Semantic versioning below 1.0 means the maintainers reserve the right to break things in a minor release, and this project is using that room. A program written against v0.39.0 may need edits for v0.41.0. The formatter helps here: the Makefile's neva-fmt target runs go run ./cmd/neva fmt -w over tracked .neva files, and it excludes pkg/formatter/testdata and internal/compiler/parser/smoke_test because those are intentionally non-canonical fixtures. If you vendor Neva source in a larger repository, mirror those exclusions in your own formatting job or you will rewrite test fixtures.

The licence is MIT, per the LICENSE file and the badge in the README. That is permissive: it allows use, modification and redistribution, including in closed source products, provided the copyright notice and permission notice are preserved. The generated Go code is your build output, but whether it inherits any notice obligation is a question for your own legal review, not something the repository settles. The compiler itself depends on go-git, ANTLR and other libraries under their own licences, which matters if you redistribute the CLI binary rather than just programs it produces.

## Conclusion

Neva is worth a look if you already write Go, want concurrency to be the default rather than an afterthought, and are comfortable with a young language whose visual editor is still marked WIP. Skip it if you need a stable toolchain for production services today, or if your problem is naturally sequential and a goroutine and a channel would do. Before adopting it, verify two things yourself: that your Go version satisfies the go 1.27 directive in go.mod, and that the examples directory contains a program close enough to yours to copy from. The MIT licence places no conditions on how you ship the binaries, and the repository is still receiving pushes as of 2026-08-23, but the language version is at v0.41.0, so treat the syntax as moving.

## FAQ

### What is the Neva programming language?

Neva is a statically typed, compiled dataflow language. You write a program as a network of nodes that exchange messages through ports, and everything runs in parallel by default. It compiles to Go, which the Go compiler then turns into machine code or wasm.

### How do I install the Neva CLI?

The Makefile's install target runs go install ./cmd/neva, which builds the CLI for the host OS and places it on your PATH. You need a Go toolchain that satisfies the go 1.27 directive in go.mod.

### Does Neva interoperate with Go?

Yes. The README lists Go interop as a key feature and says you can call Go code from Neva and vice versa, which it frames as enabling gradual adoption and reuse of the ecosystem. The compiler itself emits dependency-free Go that uses goroutines and channels.

### Is the Neva visual editor ready to use?

The README marks hybrid programming, the combination of text and the visual node editor, as WIP. Treat the graphical side as in progress and the text syntax as the part you can rely on.

### What licence does Neva use?

MIT, per the LICENSE file and the README badge. That permits use, modification and redistribution including in closed source products, as long as the copyright and permission notices are preserved.

## Sources

- [License: MIT](https://github.com/nevalang/neva/blob/main/LICENSE)
- [nevalang/neva on GitHub](https://github.com/nevalang/neva)
- [Project website](https://nevalang.org)
- [README](https://github.com/nevalang/neva/blob/main/README.md)
- [Releases](https://github.com/nevalang/neva/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nevalang-neva