RFC: Library Names for the GoGPU Ecosystem

[kolkov]

As we approach v1.0 (target: December 2026), it's time to give our libraries proper, memorable names — not just technical abbreviations.

Current names like gg, g3d, ui are functional but forgettable. Compare:

• Flutter vs "google_mobile_ui"
• Vello vs "linebender_2d_gpu"

Good names make the ecosystem discoverable, create brand identity, and make it easier to talk about the project.

What We're Naming

Whether Go import paths should also change is an open question — see "Import Paths" section below.

Library	Current Name	Purpose	LOC
gg	"gg"	2D graphics engine (5 rasterizers, GPU SDF, ClearType)	~287K
g3d	"g3d"	3D rendering engine (PBR, scene graph)	~13K
ui	"ui"	GUI toolkit (24 widgets, 4 themes, Layer Tree compositor)	~207K
wgpu	"wgpu"	WebGPU implementation (Vulkan/DX12/Metal/GLES/Software)	~229K
naga	"naga"	Shader compiler (WGSL → SPIR-V/MSL/GLSL/HLSL/DXIL)	~291K
gogpu	"gogpu"	App framework, windowing, platform integration (not to be confused with GoGPU — the organization)	~83K

One Idea: Carbon Allotropes

Carbon has fascinating physical forms that map to our graphics stack:

Allotrope	Structure	Library	Why it fits
Graphene	2D — single atom layer	gg (2D graphics)	The thinnest possible 2D material. Our 2D engine.
Diamond	3D — crystalline lattice	g3d (3D rendering)	The quintessential 3D structure. Brilliance, precision.

Both are pure carbon, different dimensions — just like our 2D and 3D libraries are built on the same GPU stack.

This is just one direction. We're open to completely different themes.

What Makes a Good Library Name?

1. Memorable — one word, easy to pronounce across languages
2. Meaningful — hints at what the library does (even loosely)
3. Unique — searchable, no collision with major projects
4. Cohesive — names feel like they belong together
5. Short — ideally 2-3 syllables

Open Questions

We'd love your input on any of these:

• gg → Graphene? Does this name resonate for a 2D graphics library?
• g3d → Diamond? Or something else for 3D? (Crystal? Prism? Facet?)
• ui → ??? This is the hardest one. The GUI toolkit needs a distinctive name. Ideas?
• wgpu — keep the name? It mirrors Rust wgpu which helps discoverability, but it's generic
• naga — name inherited from the Rust project we ported from. Keep it, or give it our own identity?
• gogpu (the library) — currently shares its name with GoGPU (the organization). Give the app framework its own distinct name to avoid confusion?
• GoGPU (the organization) — the ecosystem has grown beyond GPU: audio engine, system tray, multi-process composition, GUI toolkit, text editor. Does "GoGPU" still fit as an umbrella, or has the project outgrown its name?
• Theme vs individual — should all names follow one theme, or can each be independent?

Import Paths — Keep or Rename?

One big question: should the Go import paths change too, or just the marketing names?

Option A: Marketing names only (safe)

import "github.com/gogpu/gg" // stays the same, but we call it "Graphene"

Option B: Full rename (bold)

import "github.com/gogpu/graphene" // new path, new identity

Option B is a breaking change, but we're pre-v1.0 — this is the last chance to do it cleanly. After v1.0, import paths are frozen by Go's compatibility promise.

Go supports module directive renames and Deprecated comments to guide migration. What do you think — is the rename worth it before v1.0?

Organization Structure

We currently have two GitHub organizations:

Org	Libraries	Purpose
gogpu	wgpu, gg, g3d, ui, naga, gogpu, systray, audio, compose, ...	Pure Go ecosystem (zero CGO)
go-webgpu	webgpu, goffi	Rust FFI bindings + Pure Go FFI library

This split made sense early on — keeping Rust/CGO dependencies out of the main org. But as the ecosystem has matured, we're reconsidering:

goffi (go-webgpu/goffi) is a general-purpose Pure Go FFI library (88-114ns overhead). It's not GPU-specific at all — any Go project can use it for calling C libraries without CGO. Does it deserve its own standalone organization, like purego is independent from ebitengine?

webgpu (go-webgpu/webgpu) is one of our three WebGPU backends (activated via -tags rust). It's fully part of the GoGPU ecosystem. Build tags already isolate Rust dependencies — org separation isn't necessary for purity. Should it move to the gogpu org?

One possible structure:

gogpu org (ecosystem)
  ├── wgpu, gg, g3d, ui, naga, gogpu, ...
  └── webgpu         ← move here (it's our backend)

goffi org (standalone)
  └── goffi           ← independent (general-purpose FFI)

Migration Considerations

Repo transfers between orgs are not free — there are real costs to weigh:

Factor	Impact
Stars & forks	goffi has 69 stars, 6 forks. webgpu has 48 stars, 4 forks. These stay with the repo on transfer, but old org URLs need redirects
Go module proxy	Cached module paths (go-webgpu/goffi) live forever in proxy.golang.org. New path = new module, old imports break without redirect
Backlinks	Blog posts, Stack Overflow, Reddit, HN threads all link to current URLs
GitHub redirects	GitHub auto-redirects old URLs after transfer, but third-party tools may not follow
Contributor history	Preserved on transfer, but notification subscriptions may reset

These costs are real but manageable — especially pre-v1.0 when user base is smaller. The question is whether the long-term clarity is worth the short-term disruption.

What do you think?

Share Your Ideas

Reply with:

• Your name suggestions (for any library)
• Whether you prefer a unified theme or independent names
• Any names we should avoid (collisions, negative connotations in other languages)

Every suggestion is welcome — even wild ones. The best name might come from an unexpected direction.

[OkieGo]

Goutter(Flutter)
Gooth(smooth)
Goar(soar)
Gouty
Gover