cimgui-go: a Go binding for Dear ImGui, generated rather than hand written

The bindings are generated, and the generator is in the tree

cimgui-go aims to generate a Go wrapper for Dear ImGui, and it comes with several default backends implemented. The name of the project is the mechanism as much as the result, since the whole approach is auto generation rather than hand maintained bindings.

The pipeline is described in three steps at the end of the README. You use cimgui's lua generator to generate function and struct definitions as json. You generate proper Go code from that definition, via a manually crafted Go program in cmd/codegen. And you use the backend implementation from imgui.

The Makefile shows how that is driven:

setup:
	cd cmd/codegen; \
		go build -o ../../codegen .

The setup target builds the generator itself, and the generate macro takes a list of parameters: an output path, an include path for the header file, the paths to the definitions, structs and enums and typedefs json files, additional arguments to the codegen call such as the -r option, an optional preset file, an optional custom package name and an optional custom directory for the source. The imgui target then calls generate with the cimgui header and the cimgui_templates json files, and a separate target does the same for the impl packages.

The contribution rules are strict about the generated files, and reasonably so. You will NEVER want to modify auto-generated files manually, with sufficient comments placed on top of each file, and pull requests violating that rule will not pass the automatic checks and will not be merged.

That is the right rule for a generated binding, because a hand edit in a generated file is a bug waiting for the next regeneration. The project is MIT licensed, the primary language is C++, the default branch is main, and the last push was on 2026-10-15, with v1.6.1 released on 2026-10-07 after v1.6.0 in August and v1.5.0 in May 2026.

Five backends, and the warning not to mix them

The backends are the part you choose from, and they are all in backend/ sub-packages. GLFW is listed as GLFW 3.3 with OpenGL, SDL2 as SDL 2 with OpenGL, Ebitengine, DRM/EGL on Linux only, and RayLib.

The important note is a warning: various solutions use different C libraries that can conflict with each other, and it is recommended not to import, for example, the GLFW and SDL backends at the same time, as it may result in a linker crash. That is a real hazard in a project that ships pre-compiled static libraries for several C toolkits in the lib/ directory, and it is a mistake you make once and then remember.

The DRM/EGL backend is the unusual one and gets two notes of its own. It is intended for embedded Linux and kiosk setups that render directly through DRM and KMS without X11 or Wayland, and it currently focuses on rendering and texture upload, with desktop-style window management, drag-and-drop and input event wiring not implemented yet. To build it you install libdrm-dev, libgbm-dev, libegl1-mesa-dev and libgles2-mesa-dev, then run go run ./examples/drm-egl.

The GLFW backend has its own caveat because of Wayland. Because glfw v3.4 defaults to Wayland when possible, and Wayland does not support some of the imgui features, there is a glfwbackend.ForceX11() call, and you make it before creating a glfwbackend.GLFWBakend instance.

The examples directory covers each of them, and the README's instruction for trying them is to cd in and go run ., which is the fastest way to see which backend fits your project.

Where Go and C disagree, in three specific places

The naming convention section is short and mechanical. For functions, the Im, ImGui or ig prefix is trimmed, the Get prefix is also removed with some exceptions, and if the function comes from imgui_internal.h an Internal prefix is added.

Then there is the part where the binding hits a language boundary it cannot cross, and the README is candid about it.

You may notice some function signatures that might make no sense, for example Text with a fmt string against TextUnformatted with a text string. This is because in the original code there are some varargs arguments, void Text(const char* fmt, ...), and unfortunately in the current state of CGO there is no way to pass varargs to C functions, so these functions are generated without varargs.

The second boundary is the pointer versus slice problem. In C there is no way to distinguish between a pointer and a slice, and the project had to bring that inconvenience to Go as well. The code defaults to pointers, and you can convert a slice to a pointer with &(slice[0]). The utils package carries the helpers for it, with utils.SliceToPtr and utils.PtrToSlice, and the latter takes a size, with a warning to be careful with the size because it may cause a segmentation fault if used incorrectly.

The third boundary is callbacks, and it is the one that would bite hardest. As of June 2025, Go 1.24 does not support passing anonymous functions to C via CGO. The workaround is pre-generating a large amount of global functions and a pool, with details in issue 224. The consequence is stated plainly: you may run out of pre-generated pool and experience a crash.

So a callback-heavy application has a hard ceiling on how many distinct closures it can register, and the limit is not obvious from the API. That is the cost of the current state of CGO, not of the design, and it is the single most important thing to know before choosing this binding.

The package layout tells you where to look

The module overview table is the map, and each entry has a clear job.

The imgui, implot, imnodes and similar packages are the actual Dear ImGui and plugin bindings, used to display widgets and other UI stuff. The impl packages are responsible for imgui to backend interactions, and the README says to use them if you want to implement your own backend, not if you are using one of the shipped ones. The backend package is the abstraction layer for the various backends such as glfw, sdl and ebiten, and the backend/* packages are the specific implementations that use system libraries to render ImGui, implementing backend.Bckend as the README spells it.

Then the supporting pieces. cwrappers holds the C wrappers for Dear ImGui and the team, and also contains the C++ source. lib holds the pre-compiled set of libraries used to link with cimgui-go, with static libraries for ImGui, GLFW, SDL2 and other dependencies. thirdparty has the third party headers like GLFW and SDL2, used by the backends. utils has some utility functions used by cimgui-go, and also the Vector implementation. The examples package is a handful of examples showing how to use cimgui-go, and cmd/codegen is the code generator that generates the Go bindings.

The templates directory is not a package and holds the files used during generation, which is consistent with the rule that the generated output is not to be edited by hand.

The top level listing also shows the plugin packages sitting alongside the core, with implot, imnodes, immarkdown, imguizmo and an ImGuiColorTextEdit directory, so the binding covers more than the base widgets. There is a docs/ directory, an internal/ directory, and the go.mod requires only three direct dependencies, the raylib, ebiten and DRM/EGL Go bindings, which is a small surface for something that ends up linking a lot of C.

The function coverage is good but not complete. Most of the functions are generated, except memory related things such as the memory allocator and storage management, and if a function is missing the README asks you to report an issue.

Distribution is the one place the project is behind

There is a known issue that is worth knowing about before you commit to this for a Linux deployment, and it is stated plainly in a note near the top of the README.

Newer versions of cimgui-go do not compile on some older Linux distributions, for example Debian. The cause is that the shared libraries are compiled with the GitHub Actions version of Ubuntu, and that build is not compatible with older versions of glibc. The note links the table of standard GitHub hosted runners for public repositories so you can check the exact Ubuntu version, and the tracking issue is number 157.

That is a real constraint rather than a transient bug, because glibc compatibility is decided at build time by the distribution you compile on. Building the shared libraries yourself on your target distribution would fix it, at the cost of a custom build of the project, which is a different thing from consuming the published module.

The supported platform list in the README is macOS on arm64 and x86, Windows on x64, Arch Linux with Gnome or KDE, and Fedora Workstation 36 and later, with the note that ideally other Linux GUI environments should work as well. The word ideally is doing some work there, and the glibc issue above is the reason.

For the setup, the README says there are several dependencies you might need to install on your Linux machine and points at the install notes of the giu project, which is the same author's higher level library built on this one.

Editorial conclusion

Adopt cimgui-go if you want an immediate mode GUI in a Go program and you value the generated bindings and the five shipped backends over hand written bindings. Do not adopt it if you need variadic C functions, anonymous Go callbacks, or a build that runs on an old Linux distribution, since all three are documented limitations. Before you start, pick one backend and stay with it, because the README warns that mixing GLFW and SDL can cause a linker crash, and note that the shared libraries are built on the GitHub Actions Ubuntu image, so glibc compatibility is a factor on older systems.

Frequently asked questions

Official sources

1. AllenDang/cimgui-go on GitHub
2. Issues
3. License: MIT
4. README
5. Releases