As we saw recently:
they're looking for someone to work on a C# to native code compiler. Even if .net as a VM and the C# to IL compiler are far from gone (and probably never will be), it doesn't look like C# and .net are in favor at Microsoft nowadays.
Oh well, as long as Eric keeps on blogging...
I assure you that "how C# is treated" was in no way a factor; C# is treated extremely well at Microsoft. Moreover, think it through: I would not have taken a job that continues to improve the broader C# ecosystem if I thought that the .NET platform was some kind of dead end. It is vital.
As a long time fan of C# and how it evolved (started with .net beta 1), and even more so of Roslyn, I for one would be very disappointed to see C# not being considered from Microsoft as I consider it.
Good luck in your next position, I heard that Coverity for .net is using Cecil :)
Sad to see Eric go (just started working with him!) but glad that he's moving on to other great things.
The perception from the outside, or let say, my perception, is that both .net and C# along (C# being the flagship language for the platform) don't have the same place in Microsoft's strategy than they had say 4 years ago.
Eric being one more visible .net profile leaving Microsoft, I'm just saying it's interesting to wonder if that's related.
But you're absolutely right -- I'm glad I know now that I'm working on a new C# compiler for a dead language that no one uses.
Oh, and by "us" I meant HN. If you haven't noticed, I've been part of this community for quite a while.
Edit: This comment is maybe snarkier then I meant it. Add an eye roll or two and you'll get the gist.
> ...I'm not saying that we didn't land on the moon,
> I'm just saying it's interesting to wonder if it
> really happened.
> If you haven't noticed, I've been part of this
> community for quite a while.
 Though I agree that completely abandoning C# would be suicide in the enterprise market.
Conspiracy theories are just speculation too. One could argue that the US government has a history of all kinds of activities and thus many of the current conspiracies are in keeping with history. The essence of a conspiracy theory is speculation not grounded in evidence or probability.
I'm not sure that 'pulling rank' is necessarily constructive either. It just reminds me of those Slashdot threads where people with increasing smaller UIDs would reply with, "You must be new here," or "get off my lawn."
My comment was directed quite clearly at the insinuation that I was speaking on behalf of Microsoft, which I do not do.
I may have been snarky, but only because I see this quite a lot on HN -- that people are the company they work for. We're just members of this community like any other.
Granted, I don't follow the Microsoft development community closely, so there may be something that I'm missing out on, but I don't see it to be as 'out there' as claiming vast conspiracy theories surrounding historical events.
I also don't think that being signed up for a site for a longer duration of time inherently gives you any right to speak for the entire site, even in a conversation with one of relatively less "seniority" on the site (whatever that even means). It's nice that you clarified what you meant by "us" but that wasn't being debated and it didn't add to any points you've made.
Basically they're business models have changed where they're now positioning Azure (their new server strategy) as a multi-platform cloud strategy with support parity for .NET, node.js, Java, PHP and Python: https://www.windowsazure.com/en-us/develop/overview/
So I don't think it's a stretch to observe there has been in-fact a "Difference in strategic position" with Microsoft's attitude towards C#/.NET.
"Sole Flagship" strategies, be they for language or DB, whatever, are doomed to fail. The company has "picked a winner," reducing internal diversity and competition between approaches. Past a certain size threshold, a big company has become a number of interlinked ecosystems. Promoting standards to reduce friction of internal information sharing is the way to go. This enhances the positive effect of internal competition, instead of squashing it.
Riiight, cause standardizing on a single platform and maintaining one set of documentation and cultivating 1 shared knowledge-base is really hurting Android's use of Java and Apple's use of Obj-C.
Android and iOS are a different case. The diversity they both want, they are getting. The diversity iOS doesn't want is controlled. In a big company, the ecosystems have mostly been internal, and standardizing interoperation has traditionally been about internal efficiencies. App ecosystems aren't necessarily like that -- they are for external consumption. (Though one could make the argument that Intents are about efficiency within the Android ecosystem.)
There is no doubt that Azure is being pushed as a back-end, and front end is targeting web ui, metro, and other mobile devices. Silverlight never got market traction, so needs to be dropped.
But all that code on the Azure servers - that's all going to be .net based. Of that there is little doubt.
I think the problem here is conflating UI language usage with language usage in general. The bulk of app code is going into service layers, and they are all written on C#.
I could be wrong, but I don't think that I am.
Significant, in the fact that there's now a less clear choice of what to use when developing a Windows 8 UI or server application.
>> In my opinion: A strong cross-platform C# eco-system is simply not good for Microsoft.
In that case it's a conflict of interests, as it may not be good for Microsoft, but it's certainly good for the .NET community which lets .NET developers re-use and leverage their work on multiple platforms. Fortunately we have Xamarin filling this void, but if it wasn't for them .NET developers would be missing out on the most exciting mobile platforms to date: iOS / Android.
Not that managers don't leave for better things on a regular basis but making that the leaving-mantra sadly has reduced its credibility.
Edit: It would be "conspiracy theory" to light on one explanation and push it blindly without overwhelming evidence. But speculation in the dark is fine if it is labeled as such. Real, concrete information is better than speculation the dark. If one could count on such concrete information from Microsoft and others, one would want avoid.
That may be true, and would perhaps be applicable to this case, if Eric were a manager. He is not. He is (was) a Principal SDE. This means he writes code and likely has lots of input into high level architectural/design decisions. Any influence he had over the actions of others is likely due more to respect for his technical acumen than any kind of managerial title. I suspect the closest he would come to being a manager would be any mentoring (official or unofficial) that he did, which is likely more effective than being someones official boss :)
It's not their particular authority over others but their general importance to the company's image and the company's importance to their image which incentivizes everyone to use euphemisms in the situation of a departing of manager. It seems logical that the case of a Principle SDE would be similar.
I wouldn't read too much into that. My guess is they are looking for something easier to work with for device driver developers.
Getting support issues nailed with the .Net framework has started to become a PITA in the last year or so. It does feel like they are winding it all down.
Hey Eric while your there how about you make the CLI tool suck less. I want a simple invocation to test for the presence of failures.
Also a good read: http://www.altdevblogaday.com/2011/12/24/static-code-analysi...
I'm not a fan either.
Although we're a Ruby and JS shop, we take advantage of different services and libraries that perform different checks. In dynamic-language land it's a lot harder to do some of the things that static complication provides, but it's a heck of a lot better than nothing!
Static analysis tools are very pragmatic in a world where better languages aren't adopted very often.
Writing in C/C++ is like asking to be shot in your foot. So you get static analysis, which gives you a modicum of help.
(1) almost all compiled language systems do _some_ static analysis. For example, many compilers and linkers do dead code elimination, and Java and C# must, by spec, do static analyisis to prove that variables won't be used before set.
If you eliminate potential bugs to be found, static analysis is devalued significantly. So while static analysis may seem necessary for C++ code (very buggy, not much safety), it has less value for Java or C# code, where the easy-to-detect bugs and the remaining bugs are much more difficult to find.
As soon as you try to write living software, that is, software able to evolve over time without restarting, static analysis goes out the window. Design by contract and test suites are your friends in this case.
Until better languages are much more common static analysis can save you a lot of time tracking down obscure issues and for that alone it gets my vote. I'll be more than happy to ditch all that for a better way to develop software (not necessarily just better languages) it feels as if we're doing something terribly wrong but I can't quite put my finger on what it is.
It feels as if we're building fragility right into the process from the ground up when in fact we should be doing the opposite.
If you program in C++, you need static analysis. I'm not so sold on it for Java or C#, their is a lot less low hanging fruit in a moderately modern statically typed language.
C++ remains the market maker for the static analysis industry.
i think the future is symbolic execution, which due to a lot of factors is becoming practical