.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!)
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.
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.
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!)
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.
A good SSD is a big improvement, especially when compiling.
> 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.
Git works fine in VS. Use Git Extensions.
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?
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.
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.
Not having a debugger is like living in the stone age. Personally, the the ability to inspect application state at runtime is non-negotiable.
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.
So your code never has bugs?
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.
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.
Might be on your part of the globe. On my little world, we have enough Windows only clients to keep us busy.
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.
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
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.
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.
At least around here it seems anyone can be a Windows dev/admin while becoming a *nix admin often takes some dedication.
And to this day the amount of busywork that Windows admins and devs find acceptable still amuses me and not in a good way.
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.
Different strokes for different folks.
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
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.
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.
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.
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.
Me, I use it because I know it, and because it works for me. I see no reason to jump ship.
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.
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.
What a self-centered statement. "MY projects don't need ACID or relational enforcement. Therefore, SQL is useless."
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
Thats not even remotely true. How does Helios works then, which is also owin component?
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.
http://stackoverflow.com/questions/21308585/when-should-i-us...
Or http://www.dotnetcurry.com/showarticle.aspx?ID=915
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.
- 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.
[1] http://www.asp.net/vnext/overview/aspnet-vnext/getting-start...
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?
Good technologists will use a heterogeneous toolkit no matter what ecosystem they're working in.
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.
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.
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.
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.
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.
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...
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.
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.
Actually most of the Linux guys I know, can only manage a specific distribution.
They aren't even aware how commercial UNIXes work or how POSIX is not as standard as they think it is.
The fact is, that it is just impossible to know everything across multiple systems.
I think that's the central question in this post. And for me, "because you have to in .NET" is not the answer.
I have no problems not using TFS, not creating database-centric applications, not using ReSharper.
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.
