This is the second in a series of articles looking at the merits of Python vs. C# for startups. The first article is here (though it is not necessary to read the prior article to get value out of this one).
Let’s jump right into a series of arguments (and counter-arguments) for both sides. Note that some of these arguments are not your “standard fare” programming debates. I’m actually looking at the choice from the perspective of real startups (mine and others). This is not an academic exercise for me. Though it’s unlikely I’m going to make a platform “switch” (because of a vested interest already), this issue continues to come up with startups that I’m advising. Also, this list is by no means an exhaustive treatment of the issues at hand. Just the ones I found particularly interesting or relevant.
Python vs. C#: Understanding The Tradeoffs
- Open Source Is Good: Python has the advantage for being open source. If the same language had been offered by some closed company (without the resources of Microsoft), my decision would already be made. I’m a strong believer that successful languages and platforms require an ecosystem for long-term viability. And, long-term viability is important for software product companies because the value being created often won’t be realized until year 3-5. Ecosystems require either a very large player with resources and conviction to see it through (like Microsoft), or a passionate community that is motivated to keep the technology supported and evolve it. C# has the former, Python has the latter. If I had to choose based solely on this criteria, I’d pick Python.
- Dynamic vs. Static Languages: This topic has been debated to death in the blogosphere so I’m not going to repeat it here. Suffice it to say that Python is a more dynamic language than C# (and C# is more dynamic than something like C++). From a pure language design perspective, it doesn’t really matter to me that much whether a language is dynamic or static. I’m more interested in the implications of that tradeoff (see below). Having worked in dynamic languages before (though nowhere near the power and expressiveness of Python), I can see the appeal. In my limited experience, I have found that some of the dynamic languages require a “higher grade” developer to construct robust, scalable and sustainable applications. It can be done, but it’s easier to shoot yourself in the foot because things are so easy and fast.
- The Cost Of Compiling: C#, being a static language generally has a build/compile step. Some people hate this, others don’t. In my opinion, though the build process certainly adds a small micro-step to the development process (and impacts productivity), I kind of like being able to let the compiler do it’s thing. This catches a large body of stupid syntax mistakes. Many argue that one should have a litany of unit tests anyways, and that these unit tests are much better at catching actual errors in the code than a compiler. This is true, it is important to have unit tests and they will catch more errors than a compiler. But, what the compiler gives me (by way of testing) is essentially “free” (or near free). Simply by working within the constraints of the language, the compiler tells me things that are actually useful. I don’t have to develop unit tests to get there. Don’t get me wrong, I love unit tests (I really do), but having a compiler find some stupid stuff is a helpful thing.
- Building Binaries: Call me old school, but I have been writing software long enough to appreciate the ability to “package” my code in a form that is inconvenient for the casual user to tinker with and reverse-engineer. Yes, I do realize that in .Net, it takes a good obfuscator to accomplish this, but that’s OK. As a builder of commercial software, the “naked code” platforms like Python bother me a bit because I essentially have my naked code somewhat exposed. As a software company, this source code is a core asset and something I’ve made considerable investment in. Even as a hosted software company, I may elect to take parts of my platform and have it run elsewhere. The ability to build binaries lets me distribute my IP with some protection. Not to say I may not need to provide source anyway, but at least I have a choice. If I had to choose between the two, I prefer being able to build binaries instead of having to distribute naked source code.
- Performance: For most of the companies I’m involved in, performance is not that the dominant criteria. Though C# may have a slight edge in this respect, this is not an important consideration for the kinds of applications I’m talking about (consumer and business applications on the web). What C# may provide in performance, it takes away in the cost of infrastructure software (since it can’t run on open source). Said differently, C# may take less server resources for the same volume of concurrent users, but you’re paying for Windows on those servers so in many cases, it likely comes out to a wash. Not something I lose sleep over.
- Does Mainstream = Mediocrity? This is one of the most troubling aspects of the topic. I have read claims that one of the reasons to pick Python over C# (which is more “mainstream”) is that it provides competitive advantage. By picking something like C# (which is mainstream), I’m lining up with the masses and doing the same thing as everyone else. I’d like to push back on this a bit. Simply picking the popular choice does not necessarily cause mediocrity (though the danger is certainly there). Further arguments suggest that if I were to pick Python, I’d be able to attract a better class of programmer to the company. Maybe. I would argue that the best programmers are those that can understand the merits and tradeoffs of technical choices and can appreciate that there is no clear answer here. If they’re going to pick a startup simply because it happened to choose Python (and that’s their pet language), I would question the judgment and/or experience of the programmer. From a startup’s perspective, value is created from a combination of exceptional technical skills (i.e. “the better programmer) and some business instincts and customer intuition. Some of this also has to do with the type of startup. If I were doing really, really complicated things (like security/encryption, artificial intelligence, etc.) than the better technical skills win out. But, I’m building software for people, so the other stuff is important. As for the mediocrity argument, I’m not yet convinced that simply the act of choosing a mainstream language means you’re going to find mediocre people to work on the team or that you’re going to create mediocre solutions. I just don’t see evidence of that.
- Programmer Productivity: I have heard strong (and convincing) arguments that Python is a more productive environment for programmers. This results from a combination of the dynamic nature of the language, the elegance of the syntax and the availability of a large set of libraries of pre-written code that can be reused relatively easily. I also believe that the sheer volume of code to solve a similar problem is lower in Python and C# (primarily because of syntax decoration and boilerplate code required in C#). Can’t argue that. Programmers are likely more productive in Python, all things being equal. The learning curve is also not quite as steep (as compared to C#). On the flip side, I worry a little about larger and longer projects and whether or not languages like C# lend themselves better to team-based development, and projects that are large and span multiple years. Though I can’t (and won’t) make the argument that C# is better for bigger, longer projects I think the potential for this to be true is certainly out there. But, if programmer productivity were the sole decision criteria, I’d pick Python.
- Popularity and Precedence: One of the key factors I look at when making decisions like this is searching for precedence. Faced with similar decisions and similar needs, what have other (smart) people done? I also weigh startups that have succeeded higher (in terms of looking for precedence). My informal reading on this topic indicates that a lot of the successful startups (successful in the sense that they built products that worked, were bought by companies or have meaningful revenues) pick Java, C++, C# and PHP. RubyOnRails shows up a lot in conversations with new startups, but not enough time has passed to really know what the outcome of that choice will be yet. I just don’t see that many “household names” (in startup world) being built on Python. This worries me. The language has been around long enough to have gained traction and is clearly immensely popular in many context – but just not in the context I care about most: Startup software companies building a commercial product that hope to be acquired or go public some day. Based on what I have seen, if I were picking solely on this criteria (and this is a subjective assessment), I would pick C#. (Note: If you’re reading this and know of a startup that has used Python successfully, feel free to leave a comment).
- Valuation Impact: As unfortunate as it is, the choice of development platform/language can and does impact the valuation of a startup. The reason is that potential acquirers care about this stuff. As well they should. Not because there are right or wrong answers, but because the choices you make affect the “integration” cost for them. If they are a big Java shop and you’re written everything in Python (or C# for that matter), and they are buying you for your IP, they’ll factor the cost of this assimilation into the purchase price. If the cost/risk is high enough, it may actually prevent you from getting an acquisition offer in the first place. On a related note, if you’ve build everything in C# and the acquirer hates (or competes fiercely) with Microsoft, chances are, this will impact your odds of being acquired. This is where it becomes a bit of a numbers game. If I were playing the odds, I’d pick a more mainstream language as the odds of it negatively impacting valuation are lower. Of course, it’s also important to remember that the biggest impact on valuation is whether or not you have created a useful product that makes money. For purposes of this discussion, I’m assuming that an equally gifted development team would be just as likely to create a working product in C# as they would in Python.
I’m going to cut this off here as there’s a lot to think about and talk about. In the next installment in the series, we’ll look at surrounding components (like web frameworks and third-party libraries) and how they might influence the decision making. As always, if you have thoughts or ideas on any of the above, please comment. The purpose of this exercise is not to defend one side or the other, but to take enough of a stand as to spark some discussion.
I also plan to synthesize some of the exceptional comments I’ve already been getting on the topic into a fourth (and final) article on the topic. Hopefully you’ll have found this series helpful.