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 (https://github.com/NEventStore/NEventStore - originally joliver/eventstore).
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.
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:
> 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.
Some really good criticisms, but I do wonder how long ago this developer left .NET.
.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!)
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.
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.
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.
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.
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 recently had to spend a lot of time with csproj files. They look and behave rather a lot like Ant/Maven. This is not a point in their favor.
Ant/Maven was loved and then subsequently hated by a lot of java developers. XML is an extremely verbose syntax to have to deal with.
But the real killer is one of lockin. Yes you can use msbuild to do things with them but the syntax is really designed not for a developer to read/edit them but for an IDE to serialize state to. Just because there is a command line runner doesn't mean the format is developer friendly. As long as you stay in VS you won't really notice. As soon as you leave though its no longer comfortable. csproj files are one thing I wish .Net had taken a different path from java in.
> I recently had to spend a lot of time with csproj files. They look and behave rather a lot like Ant/Maven. This is not a point in their favor.
Perhaps not, but it's glorious compared to, say, .xcodeproj.
Combined with .props files (same format as .csproj), managing .vcxproj s (also the same format as .csproj), to manage a build matrix of ~5 platforms x ~7 build configurations x ~20 projects via a few hundred .props files hasn't been that bad.
> XML is an extremely verbose syntax to have to deal with.
Easy to parse, though, if you want to automate keeping it in sync with other formats.
> As long as you stay in VS you won't really notice. As soon as you leave though its no longer comfortable.
The longer I use them the more often I drop down to simply firing up a text editor to edit my .props files. Configuring through the IDE is a great way to add a whole bunch of state which you may or may not have meant to set, and can get quite unwieldy... whereas I can see everything at a glance that a single .props file configures by simply opening it up.
At this point I have our .vcxproj file lists almost entirely decoupled from the .props build settings. Fewer merges, and each .props file is quite easy to digest at a glance.
I've redone the build system at work completely half a year ago, as some .vcxproj files have gone through a few upgrade processes since VC++ 6 projects. Needless to say there was a lot of cruft in there. You can do a lot of nice things by offloading configuration into property sheets and including them as needed and this more or less cut down the project files to a list of dependencies and a list of files. It also doesn't help to have add-ins that insert custom build rules for every file where each change to some configuration property changes about 50 points in the project file.
I think it comes down to: Auto-generated build files are always horrible to read; write them yourself once you know what you're doing. It's probably a bit worse with MSBuild projects as Visual Studio uses them as its native project format, whereas no one else tries that with Makefiles (for good reason, I guess).
JSON vs. XML is largely irrelevant IMO. What is needed is something with as little extra crap as possible so that it is possible for a developer and/or diff tool figure out what is going on with the file.
The only real relevant part is that this means no comments. So if you DO decide to do something neat in your build files, you can't note anything about it. Or easily remove pieces for testing.
But it's JSON which is so hip instead of XML which is so bloated. /s
Not really. When your build files are designed to be serialized IDE state no matter what the format you have limited your build system to what your IDE creators decided to express. This is not always what you need and that mismatch will only get more and more out of sync the longer your project lasts.
The current state is that the project files are MSBuild projects and Visual Studio itself supports only a subset of functionality (but leaves advanced things more or less alone). So the build system itself is quite a bit more capable of just what Visual Studio supports within the files and in many cases you can mix that quite freely.
MSBuild files are actually far more powerful than what you just see from within Visual Studio! There is a bunch of cool stuff you can do with them (such as conditionals) that you do not have access to from within the VS IDE.
The .NET MicroFramework actually is an example of a project that uses MSBuild files for all sorts of crazy stuff, like supporting tons of different compilers (including GCC!).
Funny enough, it actually is possible to make VS support other compilers as well! (I've seen it done, honest!)
Editing them is no more painful than editing any other form of XML. (Err, not sure which way that is arguing!)
Agreed - I see VS2013 running very well in a VM even.
For me, VS is the strongest pull of the .Net platform after C# the language. It doesn't take me long in another IDE/language to sigh and wish for something to work as well as VS.
However, I am one of the few that would never use resharper. There are no refactoring features in the world that make a good trade for laggy typing.
I run Win7 + VS2013 development environments in VMWare Fusion on my 17" MBP (4 core 2.4GHz i7, 16GB RAM and SSD). Running two at the same time is just a bit too slow for comfort, but one runs perfectly fine.
A good SSD is a big improvement, especially when compiling.
Hmm... Unless your computer is very old or poorly configured, there's no reason for ReSharper to cause laggy typing. Maybe you should give it another shot?
I'm from a Linux/FreeBSD background. I'm currently doing work on a Windows platform.
> 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.
Git in visual studio does not work well. I'm using the built-in stuff in VS2013. If you want to do anything except the standard stuff (add, commit, pull, push without fancy options), it's horrible. There's no UI support for anything, and no CLI. I find myself resorting to msysgit a lot, and it has it's own problems. And the other devs laugh at me for it ("You're running bash, on Windows? Huehuehue"), only to experience the same problems as I do.
The .NET "async" model is not good for I/O bound problems, which is what I work on. Want I/O multiplexing? Well, you can have IOCP, but most people end up with one thread per connection anyway because I/O multiplexing is not an option in most parts of the library eco-system. Want to make an HTTP request? Have it done in a worker thread, because your HTTP library is blocking. I know things are changing, and I know there's other ways to go about this, but the author's claim that the concurrency model offered by .NET is inferior to others is a very valid one. I've done work in Java previously and it's basically the same problem. I've also experienced problems with lock contention, corner-case deadlocks, &c. Now these are problems related to the codebase, not the language itself, but threads as a concurrency primitive tends to cause programmers to make mistakes more often than other concurrency models in my experience.
And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln.
Perhaps you know less about the build system than you think. SLN is NOT XML, it's some strange line-based format, that essentially lists projects. From there the whateverproj files are XML and valid MSBuild files.
> Git works fine in VS. Use Git Extensions.
I don't know, but I think Git Extensions is superseded by the built-in Git support in VS2013. And it's very limiting if you want to do anything except the basic add, commit, pull, push stuff.
Superseded? How so? It's a third party plugin, just keep using it. The VS native stuff from MS is very immature but "ok" for simple TFS-like workflows.
> Git in visual studio does not work well. I'm using the built-in stuff in VS2013. ... I find myself resorting to msysgit a lot
You can use the git cli if you like, you can use TortoiseGit or GitExtensions. They all interoperate really well. That's the strong point of a popular open-source system. I never saw the reason why the source control system has to be integrated into the IDE before it's usable. They all operate on files and file systems, not on compilers. Why is it hard to do the commit in a different window to the coding?
> want to make an HTTP request? Have it done in a worker thread, because your HTTP library is blocking.
I'm having great results with .Net 4.5 and "var response = await httpClient.GetAsync(url)" The HttpClient and async/await came out in August last year. Is that kind of code what you mean when you say "Have it done in a worker thread, because your HTTP library is blocking" or are you using a prior version?
> And no, make files and .sln files are just not the same. They're both a part of the build system, but that's about it. I'm not even going to argue a point here, because it just fills me with rage to think about that god-forsaken fragile, XML setup that is .sln.
SLN files are not really part of the MSBuild system at all, nor are they XML. They seem to exist solely for the IDE's benefit!
Indeed I've used plenty of projects that use MSBuild but no SLN files.
I wrote that article at the end of January 2014. Technically I'm still using .NET because I've got a mountain of code that still runs on Windows. Bit by bit, I'm killing it off in favor of other languages.
.NET has always had a relatively easy asynchronous model. The async/await keywords made it a whole lot easier but BeginXXX/EndXXX were not that bad, although if you are truly IO bound burning a few extra CPU cycles is not that important.
> 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.
VS and VS+ReSharper are two different beasts. ReSharper can bring a VS instance to a crawl even on a powerful machine if you don't tweak it for better performance.
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.
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.
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.
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.
> 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.
This is incredibly true! I'd argue that even on a given platform, that one only ends up knowing a portion of it!
Heck a part of it is just stuff learned through osmosis. If I'm on Windows I know I can use tools from Sysinternals[0], such as Process Monitor, to save myself hours of time. Put me on *nix and I do not know how to do equivalent system level traces. But I've met many highly experienced cross platform developers who also don't know about Process Monitor, oops!
These platforms have decades of history behind them, a specialist in just one will always know more than a specialist in multiple!
So much of the criticism I keep on hearing on... anything programming-related comes from people that have experience of basically ONE platform, which they tried to use for everything -- and obviously failed at times. Changing platform does solve some issues but creates new ones.
In time, once people experience a few platforms and they become able to distinguish when it is appropriate to use each tool, the true advantages and shortcomings of each.
Unfortunately many are stuck working in "one-trick shops", monocultures, and end up being inexperienced in the grander landscape of possibilities and completely loose the plot.
As the author of the blog post in question, I couldn't agree with your comment more. By getting outside of ourselves we are able to utilize those experiences to understand what tools even exist and when each becomes necessary.
I used to always use the VS debugger when I used C# in school (my research lab used C#). Now, I use Python and C for work, and I never use a step debugger. For some reason I just don't miss it, and using print statements is just fine.
This is especially true in multithreaded code. I do a lot of Qt programming, and everything tends to be executed in an auxiliary thread.
I will say that I like step debuggers that come along with a REPL. This is probably the one and only thing I like about Matlab.
Lastly, I program in Haskell for fun (enough at least to write a small unit conversion library [1]). Because of laziness, I find the step debugger impossible to use. I definitely rely on print statements in Haskell.
At home I develop with C# and use the debugger all the time. However, I'm a PHP dev at work and we can't connect to our dev server with debuggers. We have all sorts of various tools we built for getting around it, like dumping objects to email and so forth. Although I kinda miss a step debugger at work I've got enough tools to deal with it, even if it's a bit slower sometimes. In other cases it's kinda freeing in a strange way.
Some developers need forcing I guess. I personally like many options: debugging, strong typing, static analysis, automated refactoring, unit tests, integration tests, tracing, logging, design-by-contract etc.
reliance on debuggers is a wierd strange concept. Debuggers are utterly incapable in multithreaded environments. Just write damn unit tests and simulations!
Depends on the debugger, really. One thing the Visual Studio team's been doing lately that I appreciate is working on improving their multithreaded debugging story. Nice visualizations for keeping track of parallel call stacks and whatnot. The actual step debugger itself still leaves much to be desired - the UI doesn't give you a lot of help with keeping track of when a context switch happens, for example - but even there it's not utterly incapable.
When was the last time that a unit test caught a race condition ? When was the last time a unit test caught a contract violation (one subsystem doesn't agree with another about the semantics of a piece of data) ? When was the last time a unit test caught the use of an O(n^large number) algorithm in a production system ?
Unit tests verify if the programmer's understanding of the code matches reality.
That's all. Not saying it's useless, but a) it's at best a start of proper testing, b) insisting on coverage is beyond useless.
What is needed is a test if the programmer's understanding of the problem is up to par. Since that's impossible, let's go with the programmer's understanding of the whole program : system and loadtests.
Unit tests, while useful for TDD for "fiddly" code, are useless to guarantee correctness of an application. System tests are better. Proper type system abstractions are best.
Funny you mention that, as the author of the blog post in question, I'm basically inside of a green-phosphor command line most of the time. I've got my cursor set to block and it doesn't blink.
Coming from C#, when I originally started using a language that didn't have a debugger I thought I would miss it. But I found that I'm more deliberate about my code because the debugger isn't there for me to fall back on.
Any production piece of software is going to need debugged at some point. Sure, a step-through debugger like the one in VS isn't the only way to debug, but it sure as hell is one of the more intuitive ways.
Being able to expand objects and see their state etc. is extremely powerful and shouldn't be shrugged off as a nice-to-have.
> traditional Windows devs are typically only good at Windows and get lost very quickly outside of their comfort zones, which is not true for Linux devs
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.
Are you sure about that? Is it that since Windows compromises 90% of desktop its reasonable to assume that a lot of people have put in 1000s of hours of using, developing, and administering it.
As a counterexample. My Linux servers, when presented with 4 NICs and multiple VLANs, doesn't know what to do with them. I had to edit the iptable. Something that I still haven't needed to do to any of our Windows server.
A big part of one of my previous jobs was setting up Windows and Linux servers and linux workstations. The severs invariably had 4 nics.
I never, ever had to adjust iptables on any if them. Setting them up is mostly a breeze except for application specific stuff ($$$ stuff, not open source).
I don't know what distro and hardware you used though.
i agree. windows devs are lazy in their majority do not like to think outside the box and often when we say "there is a project on github that can help you" guys just respond you will use an open source solution for this project?
I do not understand why they can not analyze a few lines of code and insert them into your projects to optimize your ideas.
Lastly I'm working on a MS Windows team and the time squeeze, I always turn to something in windows would be impossible to do with only 1 line. Example: parse a PDF with pdftotext, read the contents and drive to another file already positioned with the help of Perl, Python or even a simple grep.
I do not know the MS ecosystem deeply and am still getting used. Particularly consider VS a great tool. The problem with using a Git server is very serious and gets to be frustrating but nothing that you can not do otherwise.
The MS has lately shown to follow a path of opening many of their tools following an open source model and I see it as a sign to encourage the use of various technologies (open source or not) to solve a problem. Situation which MS devs are not accustomed
"Computing is SO much bigger than just Windows."
"In other words, Windows begets Windows."
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.
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.
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 is Visual Studio.
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.
"Windows devs are typically only good at Windows and get lost very quickly outside of their comfort zones"
this is actually an oxymoron. Assuming we are talking about a one-trick pony, yeah, I can see how that is possible, but it's clearly a straw-man argument.
The problem is the mindset that all .NET developers are .NET developers only. This is completely false -- all good developers I know are comfortable on a number of platforms.
> 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.
What a self-centered statement. "MY projects don't need ACID or relational enforcement. Therefore, SQL is useless."
As the original poster, I have found that relational databases have become our favorite hammer. The point of my post however is that things like the modern NoSQL movement did not originate in Redmond. Open source drove NoSQL to the forefront. If it were up to Oracle and Microsoft, we'd be using RDBMS forever.
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..
IIS is getting decaprecated (= The OWIN project).
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 ( https://github.com/robconery/biggy ). (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.
Git support is build-in (already a long time) and TFS seemed to work for me ( i use Visual Studio Online).
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
Perhaps decaprecated is a strong word, using IIS becomes optional thanks to OWIN would be better.
OWIN replaces the hosting part of IIS, so while you will always be able to run Asp.Net websites on IIS, IIS isn't a requirement anymore. (OWIN = Open Web Interface for .NET)
See the following link for a more thorough answer.
Project Katana is a collection of projects for supporting OWIN (http://owin.org) with various Microsoft components. So yes, that obviously uses IIS. But IIS can be replaced by Apache or NGINX in the near future. Katana could be used as an example to implement the same thing for those webservers.
I agree with most of the critisisms, but Microsoft is also seeing those problems and is actively fixing them in ASP.NET vNext[1]:
- It's really crossplatform and open
- It does away with the IIS / System.Web dependency
- It has clean json based project files that can reference project dependencies locally and also on nuget and github
- It unifies the ASP.NET MVC and Web API frameworks and other good things like SignalR
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.
How many of these ideas would have come from within Microsoft had in not beed for the ALT.NET movement and .NET developers looking outside themselves to other communities?
> I consider .NET to be an ecosystem including all tools, projects, platforms, organizations, and groups of developers.
Well, that explains the otherwise baffling statement "I left .Net because ... git is so much better than TFS"
That is an opinion that I also hold, but isn't relevant.
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?
Yeah, I don't see this problem. Maybe I'm just an outlier, but when I was a .NET developer, I would use non-MS tools all the time. Git is better than TFS, just as nUnit is better than MSTest. TeamCity is better than TFS. Visual Studio with ReSharper is better than Visual Studio without.
Good technologists will use a heterogeneous toolkit no matter what ecosystem they're working in.
The trouble is that "the ordained path" is MS tooling all the way. I suppose there's a lot of pressure on MS to provide a prescribed method and they're satisfying a market demand, but when I worked in .NET I had to make very deliberate choices about avoiding MS tooling and keeping it pinned back into a corner of my project. If left unchecked, it would try to dominate by default.
> The trouble is that "the ordained path" is MS tooling all the way
Every .Net shop that I've walked into, "the ordained path", speaking about the coding culture, was nUnit, TeamCity, Resharper, svn (later git) etc. Maybe you worked at the wrong places.
My anecdote doesn't trump your anecdote, but the reverse is also true.
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.
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.
That is not a problem of C# or even Microsoft. The problem is that "management". Use Python and tell them it runs under .NET as well (which is true - IronPython).
Use C#'s dynamic typing to avoid "building out a DAL", or use F# or something.
It's not like .NET itself forces people into these enterprisey patterns. Although I do cringe when I see huge projects, one file per type, half containing 2 or 3 lines of actual code.
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.
All clients assume everything is run in Linux. I don't even know why this mindset is so popular.
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.
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 meant to work on.
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.
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.
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.
We are based in the UK. I don't know if it's the clients and the type of work we are filling but we seem to be migrating a lot of people from Wordpress so typically they expect everything to still run on Linux.
Our clients are normally ones who have come from a small background and are growing quite rapid, this customer is almost certainly on some type of Linux offering.
It's probably a mix of the clients we target and the geographical location.
We do a lot of integration projects with our clients, ie integrating with CRMs / ERPs and the timescales on these projects is usually about 10/12 weeks. I enjoy this project turnaround as it means I'm never stagnant on the same project for long and I get to experience new things.
I imagine the projects for a Fortune 500 is 1 or 2 years long with thousands of man hours?
I think this is what frustrates me. We've slowly started reducing the amount of Windows machines in our cluster as the licensing for SQL went from £160 a month per CPU up to £240 per CPU in the space of 2 years.
This is unacceptable.
We can't run a business trying to guess what this will be in another 12 months time.
Resource is a big issue, I recently fired up a small Linux box on Digital Ocean as a test; it's 512mb with a small CPU. The machine barely runs at any overhead when dormant. A Windows box is using 1GB before the operating system has finished loading
I know this is something I can do right now but a few things I wanted to look at was node.js and Angular.
I'm definitely in need of catching up on some new techniques, I've been so engrossed in doing paid work that I've not had time to pick up a book and get back to the fun bit of programming
Angular is basically an MVVM implementation for JS, where most things are observable by default plus all the benefits and disadvantages of dynamic weak typing and lack of OOP. Directives are a new concept I guess, scope inheritance is another concept to watch out for (don't forget to install the Chrome extension for scope inspection - Batarang; .NET Demon + Chrome LiveReload is a nice thing to try as well when going WebAPI on server side). It is probably the best MVVM JS framework so far, so a good thing to know. Microsoft guys are using it too sometimes it seems (check the sources): http://status.modern.ie.
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.
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...
vim is a breath of fresh air compared to VS, which you've mentioned is a resource hog.
A lot of the oppression comes from the mindset in various organizations that "we must use Microsoft" (because it's safe, because they provide support, etc. etc.) and thus looking outside is actively discouraged at an organizational level. While I can't say that Microsoft directly encourages this thinking, in the past they've certainly not discouraged it.
I would have loved to use async/await when they existed, but they didn't at the time. AND I needed it to run on Mono which didn't support those language capabilities yet. Things are improving dramatically, but I've moved on to greener pastures.
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.
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")?
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.
1. c# is a great language - LINQ and type inference make it as succint as python (or even more when I use extensions methods and generics!), static type system gives a lot of safety eliminating huge classes of bugs, decent performance compared to other succint languages like Python or ruby. Really hits the spot for me, and I would hate to go to a dynamically typed language now.
2. VS is a great IDE if you give it enough RAM.
3. LINQ2SQL makes for quite pleasurable, succint and type-safe database manipulation. Bulk updates suck though, but that's an ORM for you. SQL is also a good database, and when time is right I can make use of remote database mirroring, instantly boosting my fault-tolerance. I could use Postgres as well, but SQL tips the scales with LINQ2SQL.
4. Reasonably popular, compared to web dev in other succint statically typed languages say, Haskell. So I can find answers on stack overflow.
5. Nuget. Sometimes I need a commercial package, and I can often times just get it from Nuget, play with it, and then punch in serial number after paying to remove watermarks etc. It's nice to have those packages for when I need them, to be able to buy my way out of problems.
6. Backward compatibility. I heard that ruby was breaking it more than once and python did it once. .NET seems to be less prone to this.
And I really see no downsides to it. Windows is only 20% more expensive on AWS, and hosting is literally the last on my list of expenses. Performance is good enough for me - given my business model I will be able to afford a small data center before my single Windows server gets too small for my workload. VS is slow, but buying extra RAM is a small price to pay to get it up to speed.
On AWS booting Windows can easily take 10-15 minutes. On the same type of EC2 instance, it takes 30 seconds. This makes auto scaling quickly very difficult because you have to scale up in anticipation of demand rather than as it occurs.
One other problem is that Windows by itself easily takes 1+ GB of RAM whereas Linux can easily run 64MB-128MB. So while Windows may only be 20% more expensive for similar hardware (which I don't object to either), I can run cheaper hardware and have more of it available to the application instead of the OS. Our metrics show the savings to be about 60% less expensive when counting hardware and licensing costs.
The boot time is annoyance, and resource hogging is unfortunate, but I can easily buy my way out of those problems by buying bigger machines and doing it in advance. My time is more valuable, I think, and server costs are negligible next to payroll. There are business models where hardware costs dominate like, I don't know, video processing or something, but most startups are not in that boat - they need to iterate on UX as fast as possible.
A very good reason that's not "because I know it" is that there aren't many good alternatives. And before you start yelling at the monitor and before you start listing languages like PHP, Ruby, Python, and server side JavaScript try to understand that I don't mean alternatives as in "other programming languages that work on the web" but alternatives as in "other programming languages that use the same paradigms". (I hate myself for using that word but it sort of works in this context.)
But what do I mean by this? C# is a statically typed object oriented programming language with functional constructs that has a good IDE and some good web frameworks. The other alternatives that I listed are dynamically typed and use text editors for the most part. And while there's nothing fundamentally wrong with that kind of workflow you should understand that not everyone is a fan of it. I've worked with Python and PHP before and done quite a bit of JavaScript and it always feels to me like giving instructions to the computer instead of having a conversation with it. Again, this is a matter of personal preference.
Two alternatives to C# that are a bit closer in terms of thinking would be Java and Scala. Java I don't love and Scala, while I'm OK with it as a language, has given me nothing but problems although I must say that I'm not giving up on it yet. Working with Scala on Windows was sub optimal, especially when trying to get Typesafe Activator running on PowerShell, and when I worked with it on Linux I quickly realized that IDE support for Scala is not particularly great. I tried Eclipse, Netbeans, and IntelliJ IDEA Community edition and none of them were at Visual Studio levels of quality with regards to Scala and Play.
About .NET being a closed-source single platform language / framework, that's kind of true, but Roslyn and friends should make that less true in the future. And besides, even though .NET runs best on Windows servers every other component that can form your web application like databases, load balancers, caching, etc. can run on its own native OS. The idea that if you're going to use .NET then everything that you use must have been made at Microsoft is so odd nowadays that not even Microsoft supports it. For example, the basic web application templates that are built into Visual Studio incorporate third party libraries like Bootstrap and jQuery, and guidance on how to use .NET technologies with technologies like AngularJS is commonly given by Microsoft itself.
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!
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.
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.
I migrated a number of large services and desktop apps from .Net 1 to 2 and it required unremarkable effort. Some API differences that were well documented. The notion it required you to throw away all your code and change OS is simply absurd.
There wasn't a 1.5, so you're probably thinking 1.1 or 2.0. As far as I know it's been pretty good with backwards compatibility though. I used to do a lot of.net coding, and the only time I've seen compatibility issues upgrading was with beta versions (and even then, I only saw a small handful).
One really big advantage I saw of running .NET was that the upgrade path from 1.0 -> 1.1 -> 2.0 -> 3.0/3.5 ->4.0, etc., was quite painless. Other than having to purchase a new copy of VS each upgrade, the tech side was really easy. This is unlike the Python 2.x to 3 migration which continues to hurt.
I don't remember the version numbers, and I had gotten it wrong once before when I posted about it, but compatibility was the issue now that you mentioned it. But I guess Microsoft told people that didn't happen and I must be a liar and hence all the downvotes.
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.
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:
> 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.