skip to content

detached 47cbd8a

docs(readme): explain why NeferTTY is written in Go

commit: 47cbd8a1b91e836d7f73ff35ae58f594a85591e9
author: brice · 27d ago · 2026-09-25 13:06 UTC
parent: dadad45
signature: GPG VerifiedCD88F9E564E0102646FB6077A1A07C7C7C3E349D · arch-gpg Verified for the committer email

1 file · +13 -0

M README.md +13 -0


@@ -111,3 +111,16 @@ Use `--input path` (or `--input -` for stdin) to inject a headless script. Each
111	111		`type text`, `key Super+Return` (also Shift, Ctrl, Alt or a bare key), `sleep 1s`, `move x y` (absolute output coordinates), `click [left\|right\|middle]`,
112	112		`down button`, or `up button`. Cursor rendering is not implemented yet; pointer
113	113		focus after layout changes is updated on the next move.
	114	+
	115	+	## Why not Rust?
	116	+
	117	+	Most Wayland compositors today are written in Rust or C. NeferTTY is written in Go, by choice:
	118	+
	119	+	- Simple and readable. Go is small and explicit. Goroutines and channels fit a compositor where each part (input, outputs, clients) owns its own state.
	120	+	- Fast builds, easy tooling. A full build takes seconds; tests, the race detector, profiling and formatting come with the language.
	121	+	- No cgo. NeferTTY builds with `CGO_ENABLED=0`: libwayland, Vulkan and libinput are loaded at runtime through [purego](https://github.com/ebitengine/purego).
	122	+	- Fast enough. With care for allocations and the garbage collector, the hot paths (input, rendering, buffer handling) perform close to native code.
	123	+
	124	+	As a software engineer, my passion is bringing more tools to the Go ecosystem. NeferTTY grew its own libraries along the way: purego-libwayland, purego-vulkan and wlturbo, to be published for others to reuse. Building them is part of the fun.
	125	+
	126	+	What Go does not give us is Rust's borrow checker: memory and concurrency mistakes are not caught at compile time. NeferTTY makes up for it with strict ownership (one goroutine owns each piece of state), the race detector on every test run, and protocol tests against real Wayland clients.


@@ -111,3 +111,16 @@ Use `--input path` (or `--input -` for stdin) to inject a headless script. Each
111		`type text`, `key Super+Return` (also Shift, Ctrl, Alt or a bare key), `sleep 1s`, `move x y` (absolute output coordinates), `click [left\|right\|middle]`,	111		`type text`, `key Super+Return` (also Shift, Ctrl, Alt or a bare key), `sleep 1s`, `move x y` (absolute output coordinates), `click [left\|right\|middle]`,
112		`down button`, or `up button`. Cursor rendering is not implemented yet; pointer	112		`down button`, or `up button`. Cursor rendering is not implemented yet; pointer
113		focus after layout changes is updated on the next move.	113		focus after layout changes is updated on the next move.
			114	+
			115	+	## Why not Rust?
			116	+
			117	+	Most Wayland compositors today are written in Rust or C. NeferTTY is written in Go, by choice:
			118	+
			119	+	- Simple and readable. Go is small and explicit. Goroutines and channels fit a compositor where each part (input, outputs, clients) owns its own state.
			120	+	- Fast builds, easy tooling. A full build takes seconds; tests, the race detector, profiling and formatting come with the language.
			121	+	- No cgo. NeferTTY builds with `CGO_ENABLED=0`: libwayland, Vulkan and libinput are loaded at runtime through [purego](https://github.com/ebitengine/purego).
			122	+	- Fast enough. With care for allocations and the garbage collector, the hot paths (input, rendering, buffer handling) perform close to native code.
			123	+
			124	+	As a software engineer, my passion is bringing more tools to the Go ecosystem. NeferTTY grew its own libraries along the way: purego-libwayland, purego-vulkan and wlturbo, to be published for others to reuse. Building them is part of the fun.
			125	+
			126	+	What Go does not give us is Rust's borrow checker: memory and concurrency mistakes are not caught at compile time. NeferTTY makes up for it with strict ownership (one goroutine owns each piece of state), the race detector on every test run, and protocol tests against real Wayland clients.