Why are goroutines much cheaper than threads in other languages?

In his talk - https://blog.golang.org/concurrency-is-not-parallelism, Rob Pike says that go routines are similar to threads but much much cheaper. Can someone explain why?

See "How goroutines work".
They are cheaper in:

• memory consumption:
  A thread starts with a large memory as opposed to a few Kb.
• Setup and teardown costs
  (That is why you have to maintain a pool of thread)
• Switching costs
  Threads are scheduled preemptively, and during a thread switch, the scheduler needs to save/restore ALL registers.
  As opposed to Go where the the runtime manages the goroutines throughout from creation to scheduling to teardown. And the number of registers to save is lower.

Plus, as mentioned in "Go’s march to low-latency GC", a GC is easier to implement when the runtime is in charge of managing goroutines:

> Since the introduction of its concurrent GC in Go 1.5, the runtime has kept track of whether a goroutine has executed since its stack was last scanned. The mark termination phase would check each goroutine to see whether it had recently run, and would rescan the few that had.
>
> In Go 1.7, the runtime maintains a separate short list of such goroutines. This removes the need to look through the entire list of goroutines while user code is paused, and greatly reduces the number of memory accesses that can trigger the kernel’s NUMA-related memory migration code.