I recently ditched my iPhone for a Nexus S; which was purely because I was so fed up with my old carrier that I was willing to "downgrade" my phone to switch companies.

I was shocked to find that Android is just a better system. Sure there are things that iPhone wins on, but overall Android takes the cake.

Consumers don't give a **** if it's open, or about the business strategy. Android is winning because it's better.

Maybe you haven't tried 2.3... it's leaps and bounds ahead of 2.1.

Going to http://www.startpage.com/ redirects you to the https version.

As an interesting aside, this is from the FAQ page:

On July 14th 2008 Ixquick received the first European Privacy Seal from European Data Protection Supervisor Mr. Peter Hustinx. The Seal officially confirms the privacy promises we make to our users. It makes Ixquick the first and only EU-approved search engine. Both EU Commissioner Viviane Reding and Dr.Thilo Weichert, German Privacy Commissioner complemented Ixquick on its privacy achievements. You can find the press release here.

So... the EU wants privacy, but also wants to monitor everything you do? What a strange place.

- It has been in development for almost 5 years, the team is completely different than Champions
- Character animation looks pretty good to me, but what a minor thing to complain about. It'll get better over time too. I could personally care less if it uses ASCII graphics, as long as the gameplay is solid
- Klingon faction is currently mostly PVP -- they want to add more content later. Big deal! In fact, some players will like this.
- There's a lot more going on than just tank / healer / etc. You can equip modules in any way you want to give your ship a versatile configuration. Seam with team members for away missions. It may not be the most revolutionary game around but, it does do something different. I for one look forward to trying out the strategic space combat.
- It's only microtransaction in the same way that WoW is. You can buy items that don't really affect the gameplay.
- Initial reviews and impressions are much more positive than with Cryptic's previous offerings.
.
Who knows, maybe it will suck, maybe it won't. We don't know yet.

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.

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.

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.

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.