I don't see a reason to build a Windows-only game. That's why I don't. =) I have an OpenGL/OpenGL ES stack that deploys comfortably to Windows, OS X; eventually I'll expand it to iOS (easy), Android (somewhat tricky), and probably Linux (easy).
I said the exact same thing as you are before getting back into native development. "Why should I manage memory myself? Ew!" It was one of the biggest reasons I avoided C++, and I say that knowing C (albeit having left it unused for about six or seven years). Eventually I bit the bullet and jumped back in, and to my utter surprise found it completely easy. C++ is boilerplatey on its best day, but most of the hard problems are solved problems. Like, if you want to treat it like Java or C# (which I've spent much, much more time with), fling boost::shared_ptrs around. If you don't, spend a couple seconds thinking about what you're doing. It really is a non-factor once you get into the swing of things, and while I'm a pretty competent programmer I only started writing real C++ about three months ago and I no longer spend any significant time thinking about it.
C++ gives you sufficient advantages in terms of portability and performance that, if you're writing a game from scratch, you probably want to be using it. If you don't want to be writing C++, you probably want to be using Unity or another engine that bakes in the hard parts (with a corresponding loss of flexibility).
This is very interesting and encouraging - thanks for posting this.
I've come to the same conclusion and as primarily a C# guy for the past 10 years, I've been hesitant to go the C++ route. If you haven't blogged about your experience, you might want to consider it, I know a few people that are looking for a better way to go building simple games (2d mostly) and Unity seems like overkill. Using C++ with something like Cocos2d seems like a much better way to go. I know LUA also supports Cocos2d but I guess I'd rather go with C++ since the syntax seems more my style (versus Lua's more Basic kind of syntax).
Anyway, thanks, if you've blogged about your experience please link to it, I know I and a few other would be really interested in hearing more about your experience.
Cocos2D is Objective-C. Cocos2DX is C++, but I'm a little skeptical of it. I would not be worried about C++, honestly - I'm finding it really much less heinous than I was expecting. I mentioned memory management fears before--to my surprise, I am really comforted knowing when my dtors are going to fire.
I have a blog (http://edcanhack.com) but I am very bad about it. This seems like it'd be a good post, though - I'll come up with something tonight.
I don't think you can talk about Microsoft so monolithically. I would agree that XNA was to keep people Microsoft-focused, but the XNA team has been disbanded since around the release of Windows Phone 7 or maybe a little after--I wouldn't be surprised if its demise is political.
I said the exact same thing as you are before getting back into native development. "Why should I manage memory myself? Ew!" It was one of the biggest reasons I avoided C++, and I say that knowing C (albeit having left it unused for about six or seven years). Eventually I bit the bullet and jumped back in, and to my utter surprise found it completely easy. C++ is boilerplatey on its best day, but most of the hard problems are solved problems. Like, if you want to treat it like Java or C# (which I've spent much, much more time with), fling boost::shared_ptrs around. If you don't, spend a couple seconds thinking about what you're doing. It really is a non-factor once you get into the swing of things, and while I'm a pretty competent programmer I only started writing real C++ about three months ago and I no longer spend any significant time thinking about it.
C++ gives you sufficient advantages in terms of portability and performance that, if you're writing a game from scratch, you probably want to be using it. If you don't want to be writing C++, you probably want to be using Unity or another engine that bakes in the hard parts (with a corresponding loss of flexibility).