> The code you write with Go just seems to be correct. I cant really put my finger on it, but somehow once the code compiled (and it compiles QUICKLY), you just get the feeling that itll work (not just run without error, but even logically be correct). I know, that sounds very wishy-washy, but its true.

This statement needs to be qualified.

Switching from an interpreted to a static language will catch a certain class of bugs upfront. I've rewritten some small programs from C to Go, and the same logic bugs are present in both.

In this sense, switching to Go is no different than switching to Java/C in terms of the bugs it will catch. There's nothing in Go that sets it apart from other static languages in this respect (unlike Haskell).

> Its very similar to Python in terms of verbosity (or lack thereof) and it treats functions as first-class objects, so functional programming is easy to reason about.

Where is map, reduce/fold, filter, scan? Go doesn't support functional programming primitives due to lack of generics.

I may not have written enough Go programs, but I find Go marginally less verbose than C thus far (ignoring concurrency). Channels and goroutines and are its most interesting features.

For me it is mainly a C successor that catches up with what the Pascal family of languages has been offering since the mid-80's, in terms of compilation speed, modules, concurrency and safety.

I know Go has been touted as a C successor since inception, but most new users seem to be coming from interpreted languages. Like this blogger, they attribute a lot static language advantages as unique to Go.

I don't see a lot of C/C++ developers switching, probably because they have sunk costs with their respective languages and Go doesn't offer very much by comparison.

I would definitely use Go where it seems appropriate, but I don't see it replacing C as a systems language.[0] Sometimes when I write something in Go, I look back and wonder why didn't I just do it in C. However, Go is great in a distributed systems / networking environment where most new code seems to be written.[1]

In the words of a friend, "You can pry raw memory access from my cold, dead fingers."

[0] systems == OS, drivers, etc.

[1] Motivations summarized in the abstract: http://talks.golang.org/2012/splash.article#TOC_1.

This is one of the areas where I actually take Go's defence.

Have a look at Native Oberon and AOS, both desktop operating systems developed at Zurich's technical university.

They are done in GC enabled systems programming languages and were used both as desktop systems by the teachers, as well as to teach operating systems classes.

Quite nice desktop environments using strong typed languages, but offering a Smalltalk like user experience.

http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd...

https://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf

http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager

The problem with any systems programming language is that it is only used as such, if an OS vendor makes it the only way to do OS programming. Like Microsoft does with C++ or Apple with Objective-C.

I worked on GNOME for a summer, and can see Go being a viable option for DE's. GNOME has added a lot of libraries to bring object support to C, but Haskell has proven gc language is fast enough for a WM (xmonad).

Go might need to improve its gc to prevent the occasional stutter, but it would otherwise be sufficient.

However my original statement defined systems as kernel code, since HN tends to have many opinions on the topic.

> The problem with any systems programming language is that it is only used as such, if an OS vendor makes it the only way to do OS programming. Like Microsoft does with C++ or Apple with Objective-C.

I see plenty of new C code still be written outside of systems, the problem is lack of exposure. HN community is fairly web focused but HPC, scientific computing, graphics, engines are still predominantly done in C/C++.

Desktop applications are not very demanding. You can write them in scripting languages like Python or JavaScript, both has been done in Gnome. The libraries/toolkits are more demanding.

> Haskell has proven gc language is fast enough for a WM (xmonad).

https://github.com/BurntSushi/wingo

> However my original statement defined systems as kernel code

Rob Pike (one of the Go creators) seems to define it differently:

"We designed it to be a systems level language because the problems we do at Google are systems level, right? Web servers and database systems, and storage systems and those are systems. Not operating systems, I don't know that Go would be a good operating system language but I am not sure it wouldn't be, what was interesting was because of the approach we took in the design of the language, somewhat to our surprise it turned out to be a really nice general purpose language." http://www.infoq.com/interviews/pike-google-go