Gccgo in GCC 4.7.1

Most programs don't have garbage collection latency issues. Look at Android or Windows Phone - all the user-level apps are written in garbage-collected language and they work just fine.

Look at web - all the interaction is written in JavaScript and Gmail works just fine.

At this point in the discussion people usually bring "real time" applications. Approximately no-one writes those applications.

Go is an alternative to C++ in the sense that many (but not all) programs that you had to write in C++ you can now write in Go.

The biggest hurdle I've had is that the standard library can make it difficult to avoid allocation: for example, I want to re-initialize a "bytes.Reader" or "bytes.Buffer", but I can't just pass a new slice and reset the data structure fields, from what I know. As a result, I've had to do the somewhat unpleasant task of pulling in standard library files and then tweaking them, or writing new abstractions to do some low level stuff entirely -- perhaps unavoidable, it is probably better to have a nice interface for general cases from a standard library perspective.

It is worse when you realize that a standard library function calls "make" in a place where it'll be in your inner loop: you really wish you could pass the memory to scribble into instead.

Another surprisingly expensive thing is the dynamic dispatch on interfaces. This is easy to avoid if one just writes a specialized version of a function accepting all the concrete types in the common case, though. Beyond that, memory copying, something I've found that the bytes.Buffer and bytes.Reader make hard to avoid while still capturing their useful semantics.

All in all: more pleasant than C for most projects, and very nearly as fast when like this generally, so even if you end up having to write a good chunk of stuff yourself you are no worse off than if you had chosen C to begin with.

A very notable caveat: you can't handle in any way (afaik) failed requests for virtual memory, which is rather a killer for some kind of programs. This one makes me a bit annoyed, but I can see why it's difficult to address. That doesn't make me feel much better, though.

To give a sense of what I'm doing: I'm parsing very small messages (minimum: 5 bytes, and often quite small, a common pathological case would be a handful more bytes) and passing them on with no interesting processing, and trying to get this to be fast in the trivial case. This is the Postgres wire protocol. So far, Postgres is still beating the crap out of me, which is annoying considering it actually has to do some work, and I'm just inspecting one byte and one 4-byte word of the message and then passing it on. At this point, with two copies the program is ~20% runtime.memmove, so the next high pole is to eliminate one of the copies.

Go is more of a replacement for Python, Ruby, etc. The level of abstraction is very similar. The design of interfaces provides duck-typing. Obviously, Go is not exactly equivalent, but I find that Go is, in many ways, more similar to dynamic languages than it is to either C or C++.

Go runs on RHEL 5.2 and above (released in May 2008, and there have been 7 further point releases since). If you REALLY want to run it on 5.1 and have gcc then you can build your own Go tool chain in about 2 minutes.

Your whole post is FUD. You don't know anything about Go yet offer a negative assessment. Why bother?

That sounds about right. From the Go FAQ: Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language.

Of course, whether the precise balance that Go comes to works for you is personal. I really like having most of the efficiency of C and much of the expressiveness of Ruby. I'm just getting started, but I haven't had this much fun learning a new language since I learned Ruby six years ago. Go is differently expressive than Ruby and introduces (to me) some powerful, interesting, and fun ideas (goroutines plus channels, for example.)

I think Ruby will still be my go-to language for everyday tasks, but Go definitely looks like it will have its place in my toolbox, likely replacing my occasional use of C++ at the very least. I also plan to use it on App Engine.

I don't think your post was FUD, but I'm guessing it was "I might have another look in about a decade or so" that might have felt dismissive to some people. That's not FUD, though, and it's fair to express your personal opinion like that.

I think that's accurate, and to me it's a great thing.

I'm currently converting many functions written in Python, to Go. I haven't coded in Python or studied it, but I can read it fine. This exercise has made me a lot more interested in Python! However, I'm confident that for my use case the runtime speed of Go will pay off, even though it's not nearly as simple to code in as Python from the looks of it. I'll use Python (or even PHP) for things where speed isn't such an issue.

So the answer to your question is: both.