Python vs C#/.NET -- what are the key differences to consider for using one to develop a large web application?

My organization currently delivers a web application primarily based on a SQL Server 2005/2008 back end, a framework of Java models/controllers, and ColdFusion-based views. We have decided to transition to a newer framework and after internal explorations and mini projects have narrowed the choice down to between Python and C#/.NET.

Let me start off by saying that I realize either technology will work great, and am looking for the key differentiators (and associated pros and cons) These languages have a lot in common, and a lot not--I'm looking for your take on their key differences.

Example tradeoff/differentiator I am looking for:

While it seems you can accomplish more with less code and be more creative with Python, since .NET is more structured it may be easier to take over understanding and modifying code somebody else wrote.

Some extra information that may be useful:

Our engineering team is about 20 large and we work in small teams of 5-7 of which we rotate people in and out frequently. We work on code that somebody else wrote as much as we write new code.

With python we would go the Django route, and with .NET we would go with MVC2. Our servers are windows servers running IIS.

Some things we like about Col开发者_开发百科dFusion include that its very easy to work with queries and that we can "hot-deploy" fixes to our webservers without having to reboot them or interrupt anybody on them.

I've read some of the other X vs Y threads involving these two languages and found them very helpful, but would like to put Python head-to-head against .Net directly.

".NET" is not a language. Perhaps it's Python vs. C# or Python/Django vs C#/ASP.NET (or pick whatever "webwork" you want; there are many, many different solutions for both Python and ".NET" and picking Django or MVC2 of the bat might severely limiting better viable options). As a counter to the Python vs. ".NET": There is IronPython (Python "in .NET")

I would consider: Developer comfort with a language and, if they are equal in Python and ".NET", then I would consider turnaround times for development and choose the language/"webwork" that minimized this (again, it need not be previous constraints).

While unit/integration-testing is a must for any [sizable] project, I find that a statically typed language (C#/F#) can greatly reduce the number of "stupid bugs" relating to types.

Open up the playing field :-)

Edit for comment:

Then you're just comparing languages.

In which case, C# is a very boring imperative statically typed language with Single-Inheritance/Interface Class-Based OO (but a few more neat tricks than Java, which is just downright stone-age). This is the same basic type of OO as Python has and excluding the static/dynamic bit, both languages are strongly typed (the mechanics are different, but the end result is quite similar in the language spectrum). Actually, python has MI, but that seems less accepted in python as the use of the 'lambda' keyword and since python is dynamically typed there is no compile-time support for determining interface/type contracts (there are, however, some modules that try to provide this).

If you can learn/know Python, then you can learn/known C#. It's not a paradigm shift. Some keywords here, braces there, need to say what type you mean there, a different base library... different environment (you have to fight some to get to a REPL, but it's doable in VS.) How developers like/learn/use it is another story. While I did call C# imperative before, it's nice to see the addition of some "functional-like" features such as LINQ/IEnumerable extensions and closures-without-delegates, even if the basic C# syntax is very procedural -- once again, pretty much like python (for-expressions, nested functions, statement/expression divide).

While the new 'dynamic' does blur the line (there is very rarely a good use for it -- in about all the same places one might have had to fall back to reflection in prior C# versions -- this isn't true, but the point is it's generally "the wrong way", except in the few cases when it just happens to be "the best/only way"), 'var' does not. That is, the type of a 'var' variable is known at compile-time and has nothing to do with dynamic typing; it is all type inference. Some language like F#/SML and Haskell have much, much more powerful type inference removing the need for "all those ugly type declarations" (although explicitly annotating allowed types or set of types can make intent more clear) while preserving static typing.

Personally, everything else aside, I would use a statically typed language. I'm not saying C# (and I'm definitely not saying Java!), but statically typed languages can push type errors to the top and require up-front explicit contracts (this is a big, big win for me). While you do miss out on some neat dynamic tricks, there is almost always a better way to perform the same action in the target language -- you just have to think in terms of that language and use a screwdriver for a screw and a hammer for a nail. E.g. don't expect to bring Python code relying on the (ab)use of local() or global() into C# as-is.

On the "down-side", most statically typed languages (C# here) require an explicit compile-first (but this isn't so bad as it makes pretty assemblies) and tools like the "REPL" aren't taken as first-class citizens (it is a first-class citizen in F#/VS2010). Also, if you have an essential library for Python/C# (and it isn't available in the other language), that may be a deciding factor as to why to choose one language over the other.

I wrote a very comprehensive answer on Quora about this: How does Python compare to C#?

TL;DR

• The answer is huge, but (hopefully) quite comprehensive. I programmed on C# / .NET for almost 10 years, so I know it really well. And I program on Python at Quora for ~ 7 months now, so I hope I know it pretty well.

• Python is winner in: ease of learning, cross platform development, availability of open source libraries

• C# is winner in: standard library, language features, development process and tools, performance, language evolution speed

• Roughly even: syntax (Python is better in readability, C# has more consistent syntax), adoption.

I would also suggest we must compare runtimes and not limit to language features before making such moves. Python runs via interpreter CPython where C# runs on CLR in their default implementations.

Multitasking is very important in any large scale project; .NET can easily handle this via threads... and also it can take benefits of worker processes in IIS (ASP.NET). CPython doesn't offer true threading capabilities because of GIL...a lock that every thread has to acquire before executing any code, for true multitasking you have to use multiple processes.

When we host ASP.NET application on IIS on single worker process, ASP.NET can still take advantage of threading to serve multiple web requests simultaneously on different cores where CPython depends on multiple work processes to achieve parallel computing on different cores.

All of this leads to a big question, how we are going to host Python/Django app on windows. We all know forking process on windows is much more costly than Linux. So ideally to host Python/Django app; best environment would be Linux rather than windows.

If you choose Python, the right environment to developed and host Python would be Linux...and if you are like me coming from windows, choosing Python would introduce new learning curve of Linux as well...although is not very hard these days...

The main problem in industry is the dynamic nature of python. Because you have some kind of safety with a static typed language.

But now we have modern IDEs like PyCharm. They integrate pylint and pep8 "code-checking" and "styleguide-check" when you type in your code. That eliminates the most stupid errors. So you have almost have the same safety in python now.

The other thing is, if you need "static type checking" do it by yourself when you need it. That's the pragmatic nature of python.

The GIL is a problem, but you can use gevent or ZMQ to do a kind of threading. But work in progress on PyPy STM.

Python runs almost everywhere and you have the choice of different, mostly compatible, runtimes (12 on Wikipedia) Wikipedia python interpreter list