Regarding LINQ. If I had time I'd go deeper, but the level of effort required to tune for performance compared to just writing your own custom data access layer appears to be about on par at best and still leaves you with potential performance pitfalls. If you understand data access layers and DBs, you should have no trouble writing a reasonably decent performing one with a fraction of the effort to get LINQ running equivalently. It'll have the additional advantage of having clear divisions of responsibility, and might actually be maintainable by the mere mortals that follow as well.

You tell me... ;) .NET 3.5/4.0/4.5 directory implies the CLR.

untrue.

Thanks for proving my points. That's exactly right, and exactly what was a horrible nightmare to deal with. Those few, edge case incompatibilities were what hit me each time. And, the 3.5->4.0 wasn't as minor as you make out. Even the 4.0->4.5 isn't 100% smooth, nor would it be, given the shenanigans MS did there.

Your rant is interesting. I would argue C++ still allows you to shoot yourself in the foot just as badly as C. C# requires you go in unsafe mode, or pinvoke (still unsafe). Java truly prevents many of these things, until you start playing a little too heavily with dependency injection, reflection, or you abstract one too many layers with generics. Of course, none of those will have the same shotgun meets foot effect you can achieve with C/C++ unless you use JNI.

The .NET 3.5->4.0->4.5 upgrades were absolutely horrible if you were doing anything with escalating permissions or anything else that tied to system resources. If you had 100% self-contained code that only used basic resources exposed by core APIs, I guess you'd be safe. (That's also true of just about any other language/ecosystem)

Java generics mostly are syntactic sugar. They allow for less boilerplate code, but if you don't understand what's happening under the covers, it makes no difference. Spring is the devils path to hell. Try debugging a Spring initiate's code sometime. The exorcist will have nothing on your head spinning. ORMs are pretty much all sucky bad. RDBMs just don't mesh with ORMs, as they're orthogonal. Any idea you have that they're not is mistaken or because you're at the LCD point.

Regarding uptime, I code with Java, Xcode, and Android Studio currently, and my uptime is measure in months. I also use git. (who would use svn? It's irrevocably broken by design unless it's 1 user per source tree) What you're describing is a nightmare trifecta of bad tools, bad process, and bad developers. Any 1 of the three will be an unpleasant experience, but all three? You have my sympathies.

While I normally don't respond to deeply biased trolling morons (most ACs), you've made some incredibly bad assertions. While I won't disagree with the desktop workload statement as almost any normal desktop workstation workload can be handled by a phone these days, the extra capability in the desktop merely increases the available headspace and has 0 effect on the tasks at hand. MS systems (desktop or otherwise) running MS SQL are inherently worse at anything SQL. Well, at least if you want to scale for business purposes. They may be on par for a single SQL query, or a personal DB, and perhaps even a little better in the last case as a replacement for Excel. In this case I speak from multiple personal experiences. MS SQL is wholly unsuitable as a DB for anything requiring load.

Heck, you're aware of course that windows has horrible context shifting costs? That alone dooms it in high performance high concurrency scenarios of the types running in servers? You can start reading here. It's really fascinating how MS worked so hard at cutting corners to create something that ran single threaded semi well at the cost of running the types of loads servers run really badly that it should come as no shock at all that *nix servers, which made the opposite architectural decision, run server type loads far more efficiently than windows ever will.

AD is a laughable POS. In fact, it is so terrible, I can barely even describe it. I recall when AD came out, and Exchange was hamstrung to that turd. Something that used to take 5 minutes wound up taking 6 hours. The only difference? AD. It hasn't gotten better.

SCCM (formerly SMS) sucks rocks too, it just sucks a little less than most other GUI packages out there. That's not an endorsement. You can put as much lipstick as you like on that turd, it won't change the stink. The best system I ever saw in this space was a variation of *nix long ago. Anywhere you went, the desktop, as it was, was there. In fact, this was far enough back that "desktop" wasn't even part of the lexicon. It was merely known as your home directory. But no matter what machine you were on, it was like you were "home". SGI's GUI version was also pretty darn decent, at least where I was at the time. Too bad it cost an arm and a leg even in today's dollars. The mid-level graphics card alone was $25K.

Is cdrudge alive?

I've used all those, and more. VS/C# has gone downhill from it's earlier VS incarnations, the documentation has gotten progressively worse with each .NET release to the point they're nearly worthless and made me pine for even average javadocs or man pages (if that doesn't tell you all you need to know, nothing else will) XCode is quirky but usable, it lacks some polish.. Eclipse is fine, MyEclipse or any of the other customized versions... yick. IntelliJ I can use but don't prefer, Android Studio, let's say I wish they'd revert that one. I put it with all the customized Eclipse versions in rankings. I'd probably still rather use any of them than VS with C# though.

People still develop for windows? Why? (yeah, I better duck, my karma is taking a beating today:)

Windows servers in the millions, there's a reason for that. Last time I had real numbers to compare 2 large scale equivalent systems: UNIX: <100 servers, Windows: about 2400 servers. Same basic workload, different codebases and languages (Java / COBOL for *nix, C/C++ MS SQL for Windows). Oh, and the windows system was much less capable.

Seriously though, Windows servers are in decline, and have been for a while. They're a screaming security risk, perform poorly - *nix of any reasonably modern flavor smokes windows on the same hardware, unless, of course, you're attempting to run a windows program under an emulator or API framework under *nix.

It was already in decline. Another 6 months with the "opened" up .NET for other platforms won't help a bit. You know why? Because Mono was already out there. It's not an expanded market, only attempting to eat the other fish in the "new" pond.

Considering that MS tried writing portions of Windows Vista in it and failed, um... yes as far as C# is concerned?

I am certain both you and benjymouse, if you are LINQ proponents, don't have a clue how to write high performance data access layers. I have had to undo that wonderful ORM/LINQ crap clueless morons like both of you (assumed by your comments) created because "it is awesome". Awesomely bad. LINQ straight-jackets you, as does every ORM library out there. It's just like a drug dealer, that first hit is free... That doesn't mean that you shouldn't use them as they have their place. But overall, be aware of their short-comings and make sure to wrap the access layer such that it can be wholesale replaced if need be.

I agree, it was an awesome comment, I'd have modded it Funny if I could have.

Yep, a simple lookup engine and 2 forms. There's a shining example. I've seen more complex software written in a bar.

LINQ is the PHP for those who can't design proper data architecture and access layers. As for C# being better than Java, if it was, I'd still be writing in it. I'd rather write C++ or even use that MFC Hungarian infested C abomination first.

There's a reason C# isn't used for writing windows. Hint: It's not because it's "great".