FAQ
Short answers to common questions.
Is marmot a fork of Go?
No. marmot uses Go's own type checker, SSA builder and standard library source, so it compiles the same language with the same library. It replaces the code generator, the linker step and the runtime: code goes through MLIR and LLVM, and the runtime is marmot's own.
Do I need to change my code?
No. marmot builds ordinary Go modules with go.mod, build tags, tests and //go:generate. The
known differences are cases the Go specification
leaves open.
Is it ready for production?
Not yet. It compiles real programs, including itself, and checks every test program's output
against Go, but it is young. Use it where a wrong result is cheap to notice, and keep go build
for what you ship until you have checked it on your code.
Why are the binaries so small?
The runtime is small and starts little up front, and release builds optimize the whole program
together, so code that nothing calls is removed. -O z and -s make them smaller still.
marmot size -why FUNC says why a function is in a binary.
Why are some programs slower than with Go?
Mostly allocation heavy code and defer in hot loops, which Go has tuned for years. See
Benchmarks.
Can I keep using go test, go vet and gopls?
Yes. marmot does not change your module, so the go tools keep working next to it. marmot test
and marmot check are there when you want one tool that does both.
Does it work with coding agents?
Yes. Under a coding agent marmot writes its diagnostics as JSON, with spans, source context and
fixes as edits, and marmot mcp serves build, run, test, fix and explain over the Model Context
Protocol. See Diagnostics.
Does it support cgo?
Yes, as of recently: packages that import "C" build, and C calls are direct native calls. Cross
builds of cgo packages do not work yet. See cgo.
Which platforms?
macOS on Apple Silicon and Linux on x86-64. Linux on arm64 builds; Windows is not supported.
Why the name?
A marmot is a close relative of the gopher, and it starts with M, like MLIR.