# mangos, the SP messaging protocols in pure Go

> nanomsg/mangos is a pure Go implementation of the Scalability Protocols, the family of patterns behind nanomsg and NNG, with Req/Rep, Pub/Sub, Pair, Bus, Push/Pull and Surveyor/Respondent over nine transports. It interoperates with the C implementations, and its version line and Go version floor are the two constraints to check before you adopt it.

**nanomsg/mangos** — mangos is a pure Golang implementation of nanomsg's "Scalablilty Protocols"

- Repository: https://github.com/nanomsg/mangos
- Stars: 761 · Forks: 83
- Language: Go
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/nanomsg-mangos

## One protocol family, three implementations

Mangos is an implementation in pure Go of the SP messaging system, the Scalability Protocols, which are colloquially known as nanomsg. The protocols themselves come from a family with three implementations, and the README is explicit about the relationships.

NNG is the modern C implementation of the SP protocols. The original implementation is nanomsg itself. Mangos is the Go one. The README states that generally, modulo a few caveats, all of these implementations can inter-operate.

That inter-operation is the reason to care about mangos at all. If you already have services speaking nanomsg or NNG, you can add a Go service that speaks the same patterns without a translation layer, a bridge process or a protocol converter. The patterns themselves are the classics of message-oriented middleware: request and reply, publish and subscribe, a bidirectional pair, a bus, a push and pull pipeline, and a survey with respondents. On top of those, mangos also supports an experimental protocol called Star.

Who is it for? Go developers who need one of those topologies and either want to stay inside Go rather than run a C library, or need to interoperate with an existing nanomsg or NNG deployment. The licence is Apache-2.0 with the text in the LICENSE file at the root of the repository, which is permissive enough for both use inside a product and use inside a service.

The design goal is stated too, and it is the right goal for a library like this: the design is intended to make it easy to add new transports, as well as new topologies, which the project calls protocols in SP parlance.

## The v3 import path, and the inproc trap inside one process

There is a note at the top of the README that anyone upgrading has to read. The import path has changed, and references should now point to go.nanomsg.org/mangos/v3. The old v2 imports will still work for old applications, provided a sufficiently modern version of Go is used, but no further work will be done on earlier versions.

That is a generous migration path with a defined end. v2 keeps compiling, and it keeps receiving no fixes.

The compatibility note has one sharp edge, and it is worth understanding before you upgrade. Earlier versions will still inter-operate with this version, except that within the same process the inproc transport can only be used by consumers using the same version of mangos.

Inproc is the in-process transport, where sockets talk to each other inside one binary rather than over a network. The consequence is concrete: if you have a program that links both v2 and v3, the two halves cannot talk to each other over inproc. They can still talk over the network transports. So a mixed-version process keeps working as long as the cross-version traffic goes over TCP or a socket, and silently fails to connect if it goes over inproc.

This is the sort of detail that turns into an afternoon of debugging when it is not known in advance, and the README is upfront about it. If your plan is to run two versions of mangos in one process, check the inproc assumption first.

## Transports, and why unix and winpipe are separate packages

The supported transports are TCP, UDP, inproc, UNIX domain sockets, Windows named pipes, WebSocket, WebSocket over TLS, and TLS.

The way those are exposed is the detail that trips people up. On POSIX systems and on Windows systems with AF_UNIX support, you use unix://PATH for AF_UNIX sockets. On Windows you use winpipe://NAME for named pipes. The ipc:// scheme remains as a platform alias: it uses UNIX domain sockets on POSIX and named pipes on Windows, and applications using ipc:// continue to work unchanged.

So there is a legacy spelling that works everywhere and two explicit spellings that do not. To enable one you import the corresponding transport package: transport/unix or transport/winpipe for the explicit transports, transport/ipc for the platform alias, or transport/all for everything available. The README also notes that the options in transport/ipc remain compatible with the corresponding options in transport/unix and transport/winpipe, which is what lets existing code keep working after the split.

The dependency list explains the shape of the Windows support. go.mod requires github.com/Microsoft/go-winio, github.com/gorilla/websocket, github.com/gdamore/optopia and golang.org/x/sys, and declares go 1.26.0. The websocket library is what backs the WebSocket transports, and the winio dependency is the Windows named pipe implementation.

None of these transports are imported by default, which is a deliberate and good design for a library: you pay only for the transports you use, and the import that enables a transport is also the switch that turns it on.

## Interoperability is verified, with two named exceptions

The README makes a specific claim about interoperability, and it is worth parsing rather than paraphrasing. Basic interoperability with nanomsg and NNG has been verified, and you can do so yourself with nanocat and macat, for all protocols and transports that NNG and nanomsg support.

Two exceptions are named. The ZeroTier transport and the PAIRv1 protocol are only supported in NNG at this time. So if your existing deployment uses either of those, a Go service built on mangos cannot join that part of the mesh.

The name mangos is also visible in the tree. There is a macat/ directory at the top level, which is the Go side of the macat command referenced for verification, and the repository also carries a perf/ directory and an internal/ directory.

The same self-verification story applies to the protocol layer. The README says the project supports internal self tests, which can be run in the idiomatic Go way, and notes that most of the tests are in a test subdirectory:

```
    $ go test go.nanomsg.org/mangos/v3/...
```

And there are internal benchmarks available:

```
    $ go test -bench=. go.nanomsg.org/mangos/v3/test
```

Running the benchmarks is a reasonable thing to do before you commit to this library for a latency-sensitive path, since they are in the repository and you can see what they measure. That is a better basis for a decision than any general claim about Go messaging performance.

## The Go support matrix, and a floor set by one dependency

The compatibility section is unusually precise, and it is the part most likely to affect your build pipeline.

Mangos should run on any reasonable platform, but the project officially follows the same support matrix as Go, meaning only the most recent release of Go and the release preceding it are guaranteed support. Having said that, the project will generally attempt not to break earlier versions of Go intentionally. So there is a guaranteed window of two Go releases and a best-effort courtesy outside it.

Then there is the hard floor. Go 1.26 or later is required by the Windows named-pipe transport dependency, and go.mod declares go 1.26.0 as its language version. That is a consequence of a single dependency, which is worth knowing before you plan a fleet upgrade: if you are still on an older Go, the Windows named pipe transport is the thing that pushes you forward, and everything else about the library would have been happy on an earlier toolchain.

The macat and examples directories are also Go module aware, since the whole tree is one module, go.nanomsg.org/mangos/v3, with a go.sum beside it.

One more structural note. The protocol and transport code is split into subpackages, protocol/ and transport/, and the top level holds the socket, dialer, listener, pipe, message, options and error surface as individual files, device.go, dialer.go, doc.go, errors.go, listener.go, message.go, options.go, pipe.go, protocol.go, socket.go and transport.go. There is also an errors/ subpackage. That layout is what makes the stated goal of adding a transport or a protocol a matter of working inside one directory.

## Examples, support, and a release line that stopped in 2022

The examples are part of the documentation strategy here. Some examples are posted in the directories under examples/, and they are rewrites in Go of Tim Dysinger's Getting Started with Nanomsg. The directories are named by topology: bus, context, pair, pipeline, pubsub, raw, reqrep, survey and websocket. Running go doc in the example directories yields information about how to run each example program, which is a pleasant touch, since the examples double as runnable documentation rather than as a separate tutorial that drifts out of date.

The context example is worth noting on its own, because it is the idiomatic Go answer to the problem of cancelling a blocked receive, and it is there in the example set rather than only in the API docs.

On the human side, the README points to a Discord server, and commercial support for mangos is offered by Staysail Systems, Inc. That last point tells you something about the project's shape: there is a company behind the maintenance of a widely used Go library, which is a different situation from a hobby project with a single maintainer.

The release history is where the caution is. The listed releases are v3.4.2 on 2022-08-11, v3.4.1 on 2022-03-29, and v3.4.0, a feature release, on 2022-03-29. The last push to the repository was on 2026-10-19, and the repository is not archived. So the branch is being worked on, but no tagged release has appeared since 2022 in the list, which means a consumer pinning to a version gets a 2022 snapshot of the library. The copyright line in the README reads Copyright 2026 The Mangos Authors, so the work continues even though the version tags have not moved.

Before adopting, the sensible step is to look at what has changed on main since the v3.4.2 tag, because that is the range of behaviour you would be running in production without a release to point at.

## When mangos is the wrong choice

Three cases stand out.

The first is when you need a protocol or transport outside the SP set. ZeroTier and PAIRv1 are NNG only, and the SP patterns themselves are a specific family. If your requirement is ZeroMQ proper, with its socket types and its own extension mechanism, mangos is not a reimplementation of that, it is a reimplementation of the SP subset.

The second is when you are starting something new with no legacy constraint. Adopting mangos to avoid a C dependency is a reasonable trade if you already run nanomsg or NNG elsewhere and inter-operation matters. If you do not, you are adopting a messaging API whose main virtue is wire compatibility, and you are paying for that with the v2 and v3 split, the inproc version constraint, the Go 1.26 floor, and a release line that stopped tagging in 2022. In that situation a Go-native queue or broker, or a mainstream gRPC or message broker stack, gives you a maintained version number and a support commitment, at the cost of not speaking the SP wire protocol.

The third is Windows on an older Go toolchain, where the named pipe transport dependency sets the floor for the whole build.

None of this makes mangos a poor library. It is a capable, well structured Go implementation of a specific protocol family with a permissive licence, real test coverage in the tree and a company behind it. It is simply a library with a sharp scope, and the sharp edges are all in the compatibility notes.

## Conclusion

Adopt mangos when you want nanomsg style messaging in a Go service, want to speak the same wire protocols as existing nanomsg or NNG components, and want to add a transport or a topology of your own without leaving the language. Do not adopt it if you need a protocol or transport that only NNG implements, since ZeroTier and PAIRv1 are out of scope here, or if you are starting a new service and would rather build on ZeroMQ. Verify first that your Go version is 1.26 or later, which the Windows named-pipe transport dependency requires, and that everything you need speaks the same major version, because the inproc transport does not cross version boundaries inside one process.

## FAQ

### What is mangos and which messaging patterns does it support?

Mangos is an implementation in pure Go of the SP messaging system, the Scalability Protocols, which are colloquially known as nanomsg. It supports the Req/Rep, Pub/Sub, Pair, Bus, Push/Pull and Surveyor/Respondent patterns, plus an experimental protocol called Star.

### What import path should I use for mangos v3 and can I still use v2?

References should now point to go.nanomsg.org/mangos/v3. The old v2 imports will still work for old applications provided a sufficiently modern version of Go is used, but no further work will be done on earlier versions, and within the same process the inproc transport can only be used by consumers on the same version.

### Which transports does mangos support and how do I enable them?

Supported transports are TCP, UDP, inproc, UNIX domain sockets, Windows named pipes, WebSocket, WebSocket over TLS and TLS. Use unix://PATH for AF_UNIX sockets, winpipe://NAME for Windows named pipes, with ipc:// kept as a platform alias, and enable them by importing transport/unix, transport/winpipe, transport/ipc or transport/all.

### Can mangos interoperate with nanomsg and NNG, and how do I run its tests?

Basic interoperability has been verified for all protocols and transports that NNG and nanomsg support, except the ZeroTier transport and the PAIRv1 protocol, which are NNG only. The internal self tests run with go test go.nanomsg.org/mangos/v3/... and the internal benchmarks with go test -bench=. go.nanomsg.org/mangos/v3/test.

## Sources

- [Issues](https://github.com/nanomsg/mangos/issues)
- [License: Apache-2.0](https://github.com/nanomsg/mangos/blob/main/LICENSE)
- [nanomsg/mangos on GitHub](https://github.com/nanomsg/mangos)
- [README](https://github.com/nanomsg/mangos/blob/main/README.md)
- [Releases](https://github.com/nanomsg/mangos/releases)

---

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