That's not entirely true. Go 1.3 introduced pre-emptive scheduling, so now only the most trivial (useless) of infinite loops will hog the scheduler. But if you're doing real CPU-bound work you won't block other goroutines from executing.

    package main
    import "fmt"
    func main() {
      go func() {
        for ;; {}
      }()
      for ;; {
        fmt.Println("still here")
      } 
    }

    package main
    import "fmt"
    func f(v int) int {
      return v+1
    }
    func g(x int) int {
      if (x > 100) {
        return 1
      }
      return 0
    }
    func main() {
      go func() {
        for ;; {
          if g(f(111)) == 0 {
            break
          }
        }
      }()
      for ;; {
        fmt.Println("still here")
      } 
    } 

This isn't true, you only get code points when you convert to []rune, I'm not aware of any situation where you would magically get codepoints.

>If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze.

This is not true, since 1.3 all function calls can potentially yield. Also it only happened if you had as many goroutines running infinite loops as you had kernel threads.

http://play.golang.org/p/CqLnT4m4GI

How about Go's syntax and semantics seem ad-hoc, hard to remember, and inconsistent because _they are_ ad-hoc, hard to remember and inconsistent? What does your thought leader have to do with your genuine opinion?

The crux of the matter is that there are inelegant parts to the language because they are usefully inelegant, and when you're actually writing software, useful is better than elegant.

On platforms like Go and the JVM, the garbage collector acts like a GIL, which is why they'll never replace C/C++.

[citation needed] - the vast majority of Linux software is C or C++ and I can't immediately think of any with GC. It's not normally assumed, everyone does explicit deallocation, possibly ending up writing their own slab or pool allocators.