Correct, it only spawns goroutines. It will still eat as much CPU as possible, but will be much easier to get "a word in edgewise" since it's only one process. Part of why fork bombs are nasty is that the OS scheduler can't tell the processes shouldn't be scheduled as easily as it will tell that a single CPU-bound process should be scheduled out forcibly when its timeslice is up (or whatever exact thing the scheduler is doing).

Also, when the OOM-killer gets around to killing your Go program, it'll take the whole thing down in the single OS process, rather than a fork bomb where you have to get all the processes.

Writing a true Go forkbomb is actually a bit harder, because as with many such runtimes designed from top-to-bottom around the idea of having a lot of threads, "fork" is not readily available. It's generally not meaningful to fork a highly multi-threaded program. The closest you could get would be to repeatedly execute /proc/self/exe over and over, which will come close, but probably still somewhat slower.