It needs to be mentioned, if not for comments here then at least the comments on his own blog, that the author was not someone who simply dabbled in .NET and is trying to bash it for the sake of bashing something. The author, Johnathan Oliver (no, not that one), is an absolute authority on distributed architecture and created what became one of the biggest open-source projects in .NET (<a href="https://github.com/NEventStore/NEventStore" rel="nofollow">https://github.com/NEventStore/NEventStore</a> - originally joliver/eventstore).<p>His work had a significant impact on my adoption of CQRS and Event Sourcing, patterns that are becoming very popular in Java, Scala, .NET, and to my surprise, Node. I've been happily programming in python for the last year and happy to see CQRS is starting to get more recognition in the community. I'm going to do what I can to help build its momentum, but it certainly doesn't have the same adoption compared to the .NET community.<p>So, when someone who has done so much work in the framework starts to question it, I will certainly give their opinion some thought instead of firing a retort:<p>> <i>It's OK to rant but at least get your facts straight. The rest of your rant looks quite foolish as well. For example, firing up a Windows VM is rather fast if you try it in Azure.</i>
Some really good criticisms, but I do wonder how long ago this developer left .NET.<p>.NET is now heavily async based. WPF may have started it years ago, but async has been a keyword in the language for quite awhile! (I haven't used a proper lock in ages. Event queues are where it is at! Or pick your favorite paradigm, heck the framework comes with thread pools built in that it'll juggle for you!)<p>In regards to .csproj and .sln files, they serve the same purpose as make files. .csproj files (and .*proj files in general) are incredibly powerful, you do not even need to use Visual Studio with them. They interact with MSBuild to do some insanely extensible things.<p>That said, merging .sln files is horrible, the bloody file format has an element that is a count of project element nodes in that same solution file, if two people try to check in a new project to a solution at the same time, the project count field gets corrupted and life gets seriously un-fun. :( The SLN file has a number of other issues as well, ugh! But .csproj files are pretty nifty, no worse than any other makefile replacement.<p>As for Visual Studio, I run it just fine on my Ultrabook! Huge project, it works well. Not perfect, but good enough. VS2013 fixed some very blatent threading bugs that VS2012 had in its UI (oops!) and things are generally snappier now.<p>Oh and VS support for git has been around for awhile. :) TFS also has really good git support, it has been improving with every version and it is now at a really good place.<p>All in all though, some very good points of criticism! No programming language ecosystem is perfect! (Disclaimer: I m mostly use .NET for client apps, I haven't done server .NET stuff since 2.0!)
I agree with the author on one point in particular: Choose the right technology for the task. The author doesn't state what his task is but he does drop a few hints that does indicate that .NET/Windows is the wrong technology for his task.<p>I think the authors view of Unix guys is a bit misplaced. I guess I could be a Unix guy -- I work with many different operating systems, programming languages, tools, etc. But in addition to all that, I also more recently have worked in Windows with C# and SQL server. One doesn't have to choose one side or the other -- you can choose the best tool for the task and have that include .NET if appropriate.<p>A lot of the "The Bad" is true of any platform; not specifically that list but in that every platform has pros and cons. If you choose Java, you'll have a different list. If you choose Ruby, you'll have another list. Depending on your task, you might be bitten pretty badly by whatever is on the bad list. Conversely, you might save a lot of time and headache from what is on a platform's Good list. And .NET is extremely efficient for some tasks.<p>It's actually really hard to know multiple operating systems, windows managers, desktop managers, file systems, package managers, etc. It's really a waste of brain space but a necessary evil. You can still only be an expert in a subset and muddle your way through the rest. Once you've learned a technology and everything about it then the next time you need to do a job you're likely to pick that technology even if it's not objectively the best choice for the task. So Java begets Java, Ruby begets Ruby and Windows begets Windows.
> Not having a debugger is actually a liberating experience because it forces you to code in a different way.<p>Not having a debugger is like living in the stone age. Personally, the the ability to inspect application state at runtime is non-negotiable.
> traditional Windows devs are typically only good at Windows and get lost very quickly outside of their comfort zones, <i>which is not true for Linux devs</i><p>Strongly disagree. I've watched scores of Linux-only developers try to do things on windows machines, stumble over small things, and then proceed to blame windows instead of realizing they simply lack experience.
"Computing is SO much bigger than just Windows."
"In other words, Windows begets Windows."<p>That's so true! I always roll my eyes when I hear someone says "everything could be done under the MS dome with this and that... blah blah". Yeah, surely it will work, but that does not means there is no better, cheaper (free!) and more advanced solution in the Tech universe.
I wonder how long did the author was using .NET since "bad" points were very weak.<p>Also, it seems that author isn't really interested in what's happening and what MS already done to improve .NET. Like integrating Git with MS, async, open-sourcing C# source code, moving away from IIS to OWIN, K runtime, SqlDb as file.<p>And also, if you don't like that Visual Studio is heavy you are free to use Vim with custom run parameters that will compile your code. However part of why C# is so good actually <i>is</i> Visual Studio.<p>As for "Windows devs are typically only good at Windows and get lost very quickly outside of their comfort zones". This is just plain wrong. It depends on person. You are not your IDE, you are not your programming language, you are not your OS.
> Why do we develop this way? Why aren't we considering the behavior of the application more than how it's stored? All of my projects now utilize a JSON-based key/value store.<p>What a self-centered statement. "MY projects don't need ACID or relational enforcement. Therefore, SQL is useless."
I am technology agnostic developer, a mercenary jumping across technology stacks, from project to project, according to customer wishes.<p>Actually most of the Linux guys I know, can only manage a specific distribution.<p>They aren't even aware how commercial UNIXes work or how POSIX is not as standard as they think it is.<p>The fact is, that it is just impossible to know everything across multiple systems.
.Net developer here.<p>I think VS is really awesome and a + for .Net . The support for Mono and cross platform has grown and Microsoft has shown interests by partnering with the team behind Mono..<p>IIS is getting decaprecated (= The OWIN project).<p>LocalDB doesn't require you to create a new database and you really have a json file as database . You can just use it, it's called Biggy and it's on GitHub ( <a href="https://github.com/robconery/biggy" rel="nofollow">https://github.com/robconery/biggy</a> ). (a file based document store). - i used it and it works. - It's actually more then a file based db, but check it out if you're interested.<p>Git support is build-in (already a long time) and TFS seemed to work for me ( i use Visual Studio Online).<p>Using Windows, well. I think this is "currently" a no-brainer. But Mono will be more important, so it should become usable on Linux also... (normally). Btw. I use Linux tools on my Windows machine all the time, stuff like Cygwin,ImageMagick, Go, Ruby are installed by default on my development pc.... It doesn't mean i can't work in Linux (i also have a Pi which requires me to work in it). Currently, i just prefer Windows
"Why do we develop this way?"<p>I think that's the central question in this post. And for me, "because you have to in .NET" is not the answer.<p>I have no problems not using TFS, not creating database-centric applications, not using ReSharper.
I agree with most of the critisisms, but Microsoft is also seeing those problems and is actively fixing them in ASP.NET vNext[1]:<p>- It's really crossplatform and open<p>- It does away with the IIS / System.Web dependency<p>- It has clean json based project files that can reference project dependencies locally and also on nuget and github<p>- It unifies the ASP.NET MVC and Web API frameworks and other good things like SignalR<p>Which only leaves the traditional mindset of .NET developers (SQL Server and Entity framework as the default data technology) as problems. In the right environment those remaining problems can be worked around.<p>[1] <a href="http://www.asp.net/vnext/overview/aspnet-vnext/getting-started-with-aspnet-vnext-and-visual-studio" rel="nofollow">http://www.asp.net/vnext/overview/aspnet-vnext/getting-start...</a>
> I consider .NET to be an ecosystem including all tools, projects, platforms, organizations, and groups of developers.<p>Well, that explains the otherwise baffling statement "I left .Net because ... git is so much better than TFS"<p>That is an opinion that I also hold, but isn't relevant.<p>If the conclusion is that "but .Net comes with a mindset of using all and only the MS tools" then yeah, avoid narrow-minded people. Again, is that relevant?
The problem is that while c# is useful for large programs when it comes to doing small stuff like validating and connecting data sources Node or Python are superior tools, but the engineer is shackled, management wants to see every tool written in c# even if c# is ill suited for the task and its possible to use the standard .Net build tools (Visual Studio) to build and test Node scripts for Windows servers.<p>When I want to run small tasks I want a scripting language. I don't need a full blown type system, I'm importing from strings, what I need is a Nodejs ten liner, not having to build out a DAL just to run what in the Linux world is going to be a shell or python sys admin script.
For what it's worth, .NET had those same issues 10 years ago when I left it (for java, then in 2008/9 for javascript/html5). From an educational software perspective, the lack of an equivalent to java applets (I know, they suck, but back then there wasn't a better alternative), and a lack of cross-platform browser support was a problem. And without Microsoft support or assurances, the Mono project, while they did incredible work, divided the Linux world because of a fear of Microsoft's patent lawyers.
While I agree with some of these points the biggest one for me is client adoption.<p>All clients assume everything is run in Linux. I don't even know why this mindset is so popular.<p>When we develop something and the client wants to host it I can guarantee (more or less) that the platform is Linux and they want to know why the software we have written doesn't work on Linux.<p>I know there is Mono but I always use IIS to run our software as that's what I am used to and that is the platform is is <i>meant</i> to work on.<p>I do love .NET, I've used it since it was launched. I do want to have a change though. I just don't know what language to dip into next.<p>I'll never leave .NET though as it's where I really started programming (after VBA...). I've just discovered Umbraco too which I've just fallen in love with.<p>Recommendations on languages I can try would be appreciated. I don't like this minefield we are in at the minute, I never know what is going to stick around and what is a fad.
It reads like his primary complaint is being forced to use "one true way", and the entire article and his decision are some sort of rebellion against this monstrous oppression, which he never describes in any kind of detail for us to understand what it is. I've been ising .NET for several years now, and the only complaint I can relate to is VS being a fat pig.<p>Many of his complaints about not being able to use other databases, lack of non-locking paradigm (async/await, parallel LINQ), are simply ignorant. And then he talks about windows devs being close-minded...
Good article. A lot of the criticisms are ones that I often hit as well. I would probably dispute the asynchrony/performance one, though. C# async is very efficient -- a lot more efficient than many other eventing frameworks in many other languages. In addition, I don't really think that locks are specifically put ahead of lock-free things like InterlockedExchange when dealing with multithreaded code -- it's just that writing lock-free datastructures is so damn complicated (seriously, read the literature, it's really hard to get right), that for the everyday programmer a lock is the way to go. Moreover, there's not really a connection between async/eventing and locking; they're somewhat orthogonal. In large applications I would probably see a healthy dose of both. Async doesn't help with CPU-bound computation and threads aren't really the best way to deal with concurrent IO-bound computation.<p>Otherwise, I strongly agree with the points about Mono. Speaking personally, I would love if more of the .NET platform were extended for use on Linux, as I think the Windows CLR GC is still pretty far ahead of the Mono implementation.
Serious question: If you're building web products from scratch and can choose your environment why would you use .NET (other than "because I know it")?<p>I've personally never used it because I'm opposed to closed-source single platform languages / frameworks and would like to understand the mindset of those who use it.
I think there is migration away from .NET underway, as Windows loses market share to other OSes. Desktop apps are becoming more rare. Web apps are being written in open-source platforms. A lot of the companies still using .NET are large fortune 500 ones, maintaining existing systems. Remember Cobol? I'm almost at the point where I consider .NET legacy. Perhaps, not yet, but maybe in 5 years. Does this mean the well is dry for .NET developers? Not at all. Large companies will pay small fortunes to find people to maintain their legacy systems. Either way, I think it's important for developers to become proficient in multiple programming languages.
When I first got started in web development, my brother-in-law managed a large Microsoft shop and got me started with all the software I needed to get going for a huge project I managed to wrangle using .NET when it was at version 1.5(?). We worked on that for something like six months until, one day, all of a sudden everything was version 2.0(?) and it all fell apart!<p>We quickly called my brother-in-law in and he couldn't figure what was going wrong either. After a few weeks, we had to throw in the towel and, on his suggestion, switched to Linux and then FreeBSD. Three months later, everything was humming along and we're still doing everything with FreeBSD.<p>Later, I don't recall the details, but there was some major change between versions that was what screwed us up. I know some Microsoft people will know what I'm talking in that .NET version 1.5 to 2.5 range but it hit us hard.