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.

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!

Anyone else think this is strangely similar to the Deathstar? Who builds multibillion dollar device that can be destroyed a bird and some bread? Surely they might have thought to protect critical areas that can overheat? No wonder the project hasn't been off to a good start.

Not sure what countries you are flying to and from, but I've done a fair bit of air travel in my life to varying countries around the world, and I've never once had a problem bringing my own food.

Of course you can't bring your own water (that must be purchased after the security check point), but as long as you're okay with your food being pelted with x-rays (which is undoubtedly healthier than the food typically sold in most airports), you should be fine.

Of course there are restrictions on certain types of edibles, mostly fresh fruit and other things with seeds. Just pre-package a meal with your fruits in it all cut up, and they won't say anything.

Are you American by chance? I only ask because I sense a hint of that "right to bear arms" philosophy there.

I'm sorry to inform you, but you've been brainwashed. There have been many studies done by reputable groups showing a direct correlation between firearm availability and gun deaths. (Staring point: http://www.hsph.harvard.edu/research/hicrc/firearms-research/guns-and-death/index.html)

I think it's a valid extrapolation to apply such logic to nuclear weapons, since world leaders are pretty much like children (but with infinite money, power, and weapons).

Simply put the more of these we have, the more chance we have of using them. And no I am not happy the US has a ton of them, but it's a lot better to have as few countries as possible with the ability to destroy the planet, rather than the other way around.

Untrue. As someone who has (in the past 3 years) both tried to find a job with a Bachelor's degree and then with a Master's degree, I have personal first hand experience on this.

First of all a job will never teach you what you learn in a Master's program and vice versa. The experience of focusing on one problem and becoming a world expert on it is hugely different that working in a commercial setting. Unless your job is working in R&D and doing academic research, the two things are pretty polar.

Which brings me to my next point. In computer science _especially_ not only will a Master's degree open up doors that would have never been there if you simply had a Bachelor's but the pay will be higher.

This is a world where every one has an undergrad degree, and it's also a world in an economic recession. The best way to differentiate yourself from your peers is to spend the two years, and prove you that you can focus on one thing and become super knowledgeable. You'll have your undergrad degree to show you can learn a breadth of topics, and the Master's will be something that sets you apart from the other applicants.

I do agree that spending the time on a PhD is a complete waste, unless you want to go the pure academics route (and become a professor, etc). The pay over a Master's degree is negligible, and it may actually close some doors since the perception is there that you'll want a lot more money.

That being said I also agree that experience matters more than anything. Spend every summer working in your field. Take advantage of co-op and internship programs. Work part time doing anything related to the job you eventually want to get.

And absolutely yes, if you want a Master's degree, get one. It will help significantly, and it will also get you more money.

Should I suck it up and learn to do all my programming in C++/Java/(insert other well-supported, popular language here) and unlearn ten years of philosophy, or is there hope for the multi-language development process?"

What you should do is suck it up and learn a modern build tool like CMake (which you even mentioned in your question).

I have successfully and painlessly used CMake as a build tool for multi-language projects. It's actually quite trivial -- you don't even need to do that much. For example, one source dir might use C++, another C, another D, etc, etc. It's no problem! CMake does all the hard work for you.

The whole question is actually moot to me. Multi-language development is alive and well and has been going on for a long time. It's not even a problem that really needs solving anymore.

I work for IBM, and we have a bunch of PS3's, ping pong, pool tables, shuffle board, fooseball, etc., that people can play whenever they want.

No it doesn't hurt productivity, in fact quite the opposite. Sometimes you just need to decompress, go do a few laps around a track, shoot a few balls, or get in some socializing with co-workers over a friendly game of ping pong.

The motto at IBM is that management trusts their employees. As long employees get their work done who cares what people are doing or when they're doing it!

You can just as easily slack off at your desk as you can in front of a game console. What people notice is results, and happy people produce better results.

I don't think you need to give every developer a console, and I think that would ruin a perfectly good opportunity to create more social interaction. Put all the games in common areas where people can gather.

I've solved more problems while chatting with colleagues on a break than I could begin to count.