Wrong. I can do with C++ the same design flexibility, including "dynamic" programming ala Java (that's what C++ was before templates) or dynamic programming ala Objective-C.
You can not, with C++, add functions to classes at runtime like you can with Objective-C. You can not, with C++, change the access properties of a particular class instantiation (ie change a method from public to private) at runtime like you can with Java.
You're clearly a C++-centric programmer who fails to understand that the more tools in your belt, the better. Every language has its use. C++ is an awesome language, for specific purposes, just like Java is (for specific purposes), same with Python, and Ruby, and many other languages.
No language is without its faults either.
Go is not interpreted.
That doesn't mean anything. Neither is Java. And neither is obj-c. Yet they're both languages that can be compiled to machine code, are dynamically bound, and are capable of providing runtime reflection. It's all about how it's implemented and the runtime.
Your queue class is of no relation to Gochannels whatsoever. You're omitting the Goroutines, which you simply can not ignore. They do not equate to simple threads. Take a look at the Go channel source and you'll understand better what they're actually doing.
not enough to justify a shift to Go.
Runtime reflection, true closures (something not offered any very many other compiled languages), array slices, and a built in parallel programming paradigm certainly justify at least giving it a thought for a very select category of problems.
I'm up for considering anything if it will save time / money / hassle. If it doesn't, oh well, move on to the next tool. Whatever fits!
I should also mention that I'm no Google or Go fanboy. I'm actually a C++ compiler developer by trade so I've no beef with C++ either. In fact I love C++. I love many languages. My thesis was written in D, for example. I've also written commercial applications in Python, Ruby, Erlang, etc, etc.
For me, the jury is still out on Go. I'm not convinced the world needs YAL (yet another language), but I'm open to the idea. If they find a niche for it, great.
I agree with all your "negatives", but you clearly have a C++ centric viewpoint on Go. I think it's more valuable to look at it without bias.
While it's true that the dynamic binding has a negative performance impact, it's also true that this offers some design flexibility that you can't get in C++.
It's clear that performance isn't the key concern of Go; it seems like they're aiming more for convenience and rapid development speed.
Sometimes it's hard for C++ programmers to think beyond type safety but once you shift your mind into say Python or Ruby mode (languages even more dynamic and less type safe than Go), you can still write safe code.
But like I said I do agree with you, that your negatives are indeed negatives. I just want to point out that there are positives there too, and we should be looking at every language with an eye of "what specific problem can this tool be used to solve." rather than "how can I use tool X to solve the same problems I solved with tool Y" -- which is something C++ programmers can fall into easily since it's without a doubt one of the most flexible, powerful, and multi-paradigm languages out there.
As for your 30 LOC Gochannel... don't forget that a Goroutine is not just a thread. Multiple Goroutines are multiplexed across many threads and the Gochannel.
I should also like to point out that the C code for _just_ the platform agnostic channel code (after all the os specific threading functions have been abstracted away) in Go is 1035 lines long as of changeset 3975. Nor does this include the Goroutine code.
C++'s templates offer a lot more than just generics (which is what you're talking about when you say "type safe containers and reusable algorithms"), however Go does, in fact, provide for this with its "interfaces." The Go interface affords for both data abstraction (akin to C++'s inheritance hierarchy), and generic programming. Go provides an "Any" container, which "may be used to implement generic programming similar to templates in C++".
It's worth noting though that this is a dynamically bound language feature, which means it is checked and enforced at runtime rather than compile time -- both a positive and a negative depending on how you look at it. It provides for some more interesting programs to be written that do fun things at runtime, but on the down side it means you lose a lot of the compile time type-checking that C++ provides and can save a lot of debugging time later on. It also means that you can't do any template metaprogramming with Go -- again which can be viewed as a positive or a negative.
I also challenge you to come up with a solution that equates to Go's built in Channel's in less than 100 lines of C++. What you're actually saying is you "can implement Go's Goroutine's AND Channels in less than 100 lines of code in portable, cross platform, C++". But, let's give you the benefit of the doubt and say that you've already go some mechanism for emulating a Goroutine (which by the way allows one to "mutiplex independently executing functions onto a set of threads"). I think _just_ the thread safe code that would implement all the necessary locks and barriers for a _single_ platform would probably be more than 100 lines, and would not be portable (ie, it would be pthreads, or win32 specific).
I am open to being wrong about that, but I really do believe that you haven't spent much time investigating Go, and are therefore spreading FUD. For example your assertion that "in Go, a List class would have to use void* types, throwing type safety out of the window" is just plain wrong.
I should also point out that I am in no way a Google Go fanboy. I see it as a pseudo-interesting low-ish level language that I haven't quite been able to envision the proper use for yet. I don't really buy Google's claim that it's a system level language (I can't see myself wanting to write an OS or device driver in it). To me it seems more like a great way to rapidly build efficient client / server type applications.
The reality is you spend all your time fiddling with it and cursing at it until your head is so bloody from banging it up against a brick wall that you give up and decide to give up TV altogether.
Close. The reality is that you spend so much time banging your head up against a brick wall that you just think you're watching TV.
I know that these are funny, but just so people know, it's really not true. Setting up MythTV is really quite easy, and if you're building a box specifically to run mythtv hardware support is a complete non-issue. Get one of the better capture cards (check the support list), and everything Will Just Work.
I've been running Myth for years, and there was a time when installing it was problematic to say the least, but seriously, setting up MythTV these days is no harder than installing an app from your package manager, running through a few configuration screens, maybe signing up for a listing service. That's it!
To the systems programmer, users and applications serve only to provide a test load.