For the most part, Microsoft CLR users already don't care. Have you heard of IKVM? They're already yo-ho-ho-ing code like Zookeeper libraries and other stuff at a prodigous rate. And given that the CLR has versioning that lets it update its binary engine without deprecating the entire universe that came before, they're doing it with a language with features at least 5 years ahead of what the Java working groups are even considering.

Given the open sourcing and license of the .NET core libraries, CoreCLR and compiler... Quite frankly the community would be better served if Google used the CLR. Microsoft actually doesn't need a lot of buy-in. They're already leading one of the top 5 most deployed binary platforms in the world. What they want is developers to recognize their platform is actually the technically superior and most open option.

I think most Android developers would just be happy if Android wasn't locked to JDK6. A real christmas miracle would be if they could stop using Gradle and its outrageously long build times.

There is nothing more inhetmrently wrong with "WYSIWYG" editors than there is with C++. Judicious, appropriate use is implied. I think the industry over-relies on unmanaged code, appealing to "performance" as a crutch for bad designs and algorithm selections. The results speak for themselves.

See: I'm saying that if you're splitting it, you're wrong. You did it wrong at the start and now you have no choice but to keep doing it wrong.

So I guess we agree to disagree, since you can't offer anything other than bland arguments and appeals to a largely ineffective status quo.

I have no idea what your objection or argument is. Sorry.

I'm a "Director of Software Engineering for Capital One. You might have heard of us. I was brought in awhile ago through one of the many acquisitions as the company flushes its legacy tech policy and tries to pivot to be a technology company. You have enough data to find my phone number now. Feel free to give me a call if you're interested in helping me out and can write code.

As an aside, AWS/EC2 is probably not the right choice for small companies anymore. GCE and Azure are way better for little ones because their service set and management tools are way richer. Amazon's willing to play ball with super-big companies at a scale even Microsoft isn't quite ready to embrace, as evidenced by my current workloads. And if the recruiter spams in my inbox are any indication, several other banks want to follow suit.

Claim victory however you like. I think dedicated sysadmins are not necessary for the majority of situations in the world of commercial software now. If you're maintaining your own data center, things change. Most people aren't, so they don't need them.

No. Nice try fearmongering though. I'm the antithesis of an "outsourcing" mentality for software. I'm busy "un-outsourcing" as many things as I can at my current employer because the value loss is just so extreme.

But you keep trying to pretend that C++ is somehow tied to good programming.

Whatever we can't get, we write. Isn't that how everyone works? What we don't need are silly single-role ops people who have no say in the actual development of software but don't have the skills to participate in its creation or maintenance. That's makework.

Sorry, but I have little pity for people who lose their jobs in technology to improvements. Unlike many people, you have the resources to self-educate and keep abreast of the times and state of the art. You just elect not to.

If you want to say, "Operations people are the people who wake up at 3am to deal with a page" then that'd be me. But that's a pretty archaic and artificial boundary.

Engineers who design systems should be responsible for their continued operation. This has a lot of positive outcomes. Hence the term, "Devops." But I wouldn't hire an operations engineer who couldn't have at least in principle written the system they're managing, which means I don't hire most people who claim the title. Especially so in this day and age when containerization is effectively the annihilation of differences between local and remote operational environments.

Thanks for your grade school statistical analysis, anonymous coward. Why not just crawl back in the time machine and enjoy the 90s before you hear some Friends spoilers? You're farcical in this day and age, and I'd laugh at you were it not for the tragedy of how your how sharp and painful little words hurt some people who work harder than you've ever had to, just to stay in the US.

What the hell are you even talking about? If my product is unreachable, then someone can't reach it. I can propose workarounds to this (multi-datacenter solutions with replicated databases and carefully tuned distributed consensus systems). During a true catastrophy (e.g., US-EAST going down due to flooding) the most important thing I can do is make sure that the data the system manipulates retains integrity through the event, and that the system can resume operation once connectivity can be restored.

We operate under the assumption that software and networks WILL fail, not in the fear that they MIGHT. Indeed, understanding the failure modes is the majorty of my time spent when designing distributed systems.

Who said anything about not having a robust service department? Not me. I have zero interest in having your argument with you. It seems like you're quite capable of carrying on by yourself.

By the way, edit: 4 years. Sorry, simple typo I missed. Were that I were as diligent as my software.

I disqualify languages that do this to the extent C++ does. It's like programming in a minefield. Despite the fact I love the power of C++ and the elegance of Haskell, I do not expect most software shops to actually reliably ship on them.

But it's also a testament to a good system when the abstractions become central. Engineers already function at a pretty high level of abstraction for the most part. I don't think we should be too afraid of embracing that so long as the underlying methodologies are open sourced and well-understood.

That's already how it is and it's not that bad. Bad things happen, and they're corrected. This is not unusual for the human condition.

Sorry, I disagree strongly.

You don't need strong AI to actually implement monitoring, elasticity, and write software that fails in a method amenable to self-repair and in extreme cases, quick diagnosis.

I've been frontline on Pagerduty at the company I founded for 5 years. There were some rough times during the first few apple features. No longer, though. Most of our systems self-heal or are designed to tolerate and report outages and partitions gracefully. Some categories of failure do knock us offline, but they're total failures and the system knows to go into an exponential backoff mode in that case.

Sad part is, most of that code was trivial to write, universal over our entire app (we have one common shared library called "tragedy" that regulates nearly all of this). I wrote it years ago, and it has required only a handful of fixes over time.

People who say it's impossible usually don't understand what's actually hard about it, don't keep up with current research in the field, and say things like, "No one understands zookeeper" and "Multi-PAXOS is over-engineered" and "backpressure is what broken systems need." I try to help educate people on this stuff, but I have a strong financial incentive not to, so... I generally let other people do it and laugh at the useless hand-wringers talking about how we should give every engineer a piece of a broken bridge or some shit.

This part of the thread is like some kinda racist time machine. It's nearly 2016, folks. This kind of garbage is called what it is now. Conflating trained software engineers with call center support is another great example of the kind of demeaning bullshit Americans do to anyone foreign: collapsing them into a demeaning caricature. You both should feel ashamed. Doubly so because you're comically wrong and outdated.

First of all, outsourcing as a primary source for software has been on a sharp decline for years. A far greater problem is that the vast majority of services simply aren't writing code at all. They're buying 5-10 year old whitelabel software with confusing adapters to modern patterns or simply outsourcing entire products and then letting daily batch processes weld things together. A great example of this is most small banks and credit card providers in the US.

Second of all, there's no reason people from India can't make great software. Go to any laudable US Compsci program and you'll find people from that country in every grade bracket of every division, if you "require proof" that humans are humans. The business model is the problem, not someone's skin color or language. Outsourcing firms (of which there area LOT in South America now, by the way, so maybe it's time to listen to Trump's rhetoric?) aren't effective because their model is making payroll, not delivering great software to their clients. Many companies are realizing this, and converting to a contracting supply model, which makes a lot more sense in an environment where good talent is hard to find.