Kaiju – General purpose 3D/2D game engine in Go and Vulkan with built in editor

Project impression & “vibe coded” debate

• Some readers see the emoji-heavy README and bold claims as “vibe coded” or engagement-bait.
• Others argue the grammar errors and style strongly suggest a human author, not an LLM, and note that emojis in text predate LLMs.
• There’s disagreement over whether emoji-filled technical docs were common before LLMs.

Platform & technical choices (Go, Vulkan, macOS, FFI)

• Mac support is seen as harder because the engine doesn’t appear to use SDL; integrating with macOS windowing/input and MoltenVK in Go is nontrivial due to Objective‑C/Swift bindings.
• Several commenters question Go as a game-engine base: cgo/FFI overhead for Vulkan calls, segmented stacks, goroutines, and async preemption are viewed as poor fits for tight real-time loops.
• One person notes you can theoretically limit C calls to once per frame, but it’s unclear how this engine actually behaves.

Garbage collection, memory management, and performance

• Long subthread on GC: some claim GC languages are a “non-starter” for engines; others point out Unity, Unreal, and many Godot usage patterns already rely on GC or reference counting.
• Clarifications: Godot’s GDScript uses ref counting; C# uses a traditional GC; Unreal’s UObject/Actor layer is GC’d though low-level rendering is not.
• Multiple people stress that GC pauses, not raw FPS, are the real problem; empty-scene FPS says little about frame pacing.
• Reference counting is noted as a form of GC and can also cause bursty deallocation.
• Go’s GC is reported to be relatively smooth, but channels/goroutines can be too heavy for low-latency workloads.

Engine vs game: validation and goals

• Strong consensus that GitHub is full of engines because it’s easier and more fun for programmers than making complete, fun games.
• Several argue an engine only becomes “real” once it ships a game; defined goals and constraints are what drive serious performance and architecture work.
• Others defend hobby engines as valid learning tools and solid portfolio projects, even if they never ship a game.
• There’s debate whether engine authors should make games (dogfooding) versus focusing purely on tools.

Marketing, demos, and “9x faster than Unity”

• Many dislike the “9x faster than Unity” claim, especially for an empty scene; they call it misleading or “snake oil” without a realistic benchmark.
• Commenters want stress tests involving entities, physics, materials, batching, and editor tooling, not cube-in-a-black-room comparisons.
• Lack of clear game demos or GIFs is seen as a major weakness; people expect engines to lead with examples proving they can ship at least one finished game.
• Some note that a lean, young engine will naturally show less overhead than a mature tool like Unity, but that doesn’t speak to usability or features.

Ecosystem, tools, and competing engines

• Fast compile times in Go are seen as a genuine plus for the editor experience.
• Several people emphasize that language choice is less important than tooling, ecosystem, and ease of use; Unity and Unreal win largely on features, editors, and assets.
• There are side discussions comparing Unreal, Unity, and Godot in feature richness vs practicality, and on the importance of good built-in editors (referencing Warcraft/Starcraft/NWN).