Ask HN: Could the back-end language influence the success of a Web startup?

This is one of pg's theses about startups -- one that he bet heavily on when he became an investor. And the first essay that had a significant audience.<p><a href="http://www.paulgraham.com/avg.html" rel="nofollow">http://www.paulgraham.com/avg.html</a><p>I'm surprised that conventional wisdom has flipped at HN. Is C++ now considered just as good a language for web startups as Python or Ruby? Really?<p>This feels quite eerie. I've felt the "decline of HN" posts were a bit overblown but this really shows, at a minimum, how the community has little to do with its origins any more.

If your assumption were true I'd guess it wouldn't make any difference. The problem with your question is the assumption that the two versions would be the same - unless one was a copy of the other or both were copies of a third. The original language or framework has a lot to do with how you look at a problem. A painting done with watercolors will look very different from done with oils, even if the artist and scene are the same. Someone might counter this argument by pointing out Heather Jansch's driftwood sculptures of horses, which are remarkably made of bronze - but most of the time the choice of tools and materials has a lot to do with the result.

I'm a big fan of rapid prototyping in Perl - not because I think it's a more appropriate solution, but because it's the language _I'm_ most productive in while in "make it up as I go along" mode (and the language I enjoy random hacking in most). If I'm not going to write a spec before I start coding, I'll get to proof-of-concept stage very quickly using Perl. So long as you remember to _always_ throw the first one away and plan to rewrite it, getting something working _fast_ is a great advantage - even if only to allow you to fail fast - I'd rather give up on a weekends worth of Perl hacking that revealed no-one else cares about the problem I'm trying to solve, than a weeks worth of careful design spec and carefully considered system architecture and code structure.<p>So long as you admit to yourself when you've got a quick-n-dirty hacked together dog and pony show, I think the "best" _initial_ back-end language is the one that you can get a MVP up and running and generating customer feedback most quickly. Even if you _know_ you need a multi-cloud-auto-scaling no-sql-memory-cached auto-sharding super-service to support your 10,000 simultaneous users, you don't need to build all of that until you've got demonstratable traction... You _certainly_ will be better off with a single-threaded-maxed-out-at-8-users prototype, and getting real customer feedback early.<p>Once you've proved the problem is worth solving, _then_ do your massive-scale system architecture, and choose the ongoing backend based on that.

Stackoverflow's answer: <a href="http://stackoverflow.com/questions/341993/is-django-development-faster-than-asp-net-for-small-medium-size-apps" rel="nofollow">http://stackoverflow.com/questions/341993/is-django-developm...</a> A technical manager's comparison: <a href="http://kurtgrandis.com/blog/2010/02/24/python-django-vs-c-asp-net-productivity-showdown/" rel="nofollow">http://kurtgrandis.com/blog/2010/02/24/python-django-vs-c-as...</a><p>Python/Django wins! I've also heard anecdotal evidence of a .Net killing a person's startups because of the difficulty of development.<p>I was trained in Python/Django and am now working in ASP.NET/C#. I've opened my mind to it, and can get stuff done, but I always feel like it would be faster &#38; more elegant to do it in django.

The one more prone to success is the one that has a better person or team leading it to success, regardless of what it's built on. I can't even imagine a scenario where users actually <i>care</i> about the underlying stack, especially in any significant quantity.<p>With web apps the languages are all doing much the same thing anyway - they're taking data from a database and shoveling it on to pages. They're all going to suck and hurt at massive scale, they're all going to be worse at <i>something</i> than some other language, it's going to be hard to find <i>awesome</i> people for anything, and harder still to find awesome people who have previous experience solving the problems you face, most of which probably won't even be platform/technology related.

If every other aspect of the applications (including the teams behind them) are identical, then the language/framework which is the most suited to developing new ideas and features is the one that will be most successful. For example, if you were using (to pick an extreme case) Lisp and COBOL, the Lisp version would have the advantage because new features could be implemented in a DSL suited specifically to the task, while the COBOL application would take a lot of work to extend.<p>In real life, of course, the differences aren't this large and are usually overshadowed by some other differences (eg, competence of the team, overall architecture of the application, marketing.. etc) and the language difference advantage may be negligible in comparison.

That is like asking if the brand of spark plugs will effect the sales figures of an automobile. There are so many other factors more important than the backend programming language that it doesn't bear measuring. To name a few: marketing, financing, leadership, team...

The major thing that will influence the success of your Web startup is if you have fun making it.<p>So you need to choose a language that is fun using, that will let you prototype things quickly and that you feel comfortable with. This language for me is JavaScript and so far all the other alternatives have been just a pain to deal with. Node.js is just fun and simple as it should.<p>So if at the end you have a code-base that is not fun to work with, it will probably be hard for you to fix bugs and add features.<p>Stick with a language you love and it will influence the success of your startup.

I dont think languages differ most in prospects for success <i>after</i> you've reached functionally-complete-and-relatively-bug-free stage. The biggest difference is how do you get to this stage.<p>For a medium-to-big sized web application it would take you years to implement it in asm ;)<p>A language with a good web 'community' and great framework can be quite a big boost in getting your 1st version out to the users.<p>Also, many times, the choice is not so much between the tech but rather between the teams (i.e. when looking for outside help with development) in which case the tech matters less the people's ability to predictably hit the target on time and budget (talk to prior customers).<p>When doing internal development, if your team knows any web language well then thats what they should be using. On the other hand if the one they know is something like cold fusion I'd say - switch ;)<p>If you do switch, keep to the open source stack, linux, apache/nginx, mysql. Again, there are quite a few people advising postgre over mysql, but I'd say it depends on how your team knows them both. if you are new to db, then you might as well start with postgre, but if you already know mysql, stay with what you know.<p>Bottom line, stay with what you know unless what you know reeeally suck for web dev, in which case switch. I'd recommend Ruby on Rails, or if you allergic to Ruby - Djungo ;)

Which version took longer to write? Which version has fewer SLOC (I'm using SLOC here as a proxy for code complexity)? Weigh those two factors, then choose the winning language accordingly.<p>I'm oversimplifying, but I believe the point is an extremely important one. We've all heard the startup lore that David-sized startups beat industry Goliaths by being much more nimble than the lumbering giants they're competing against. If you're a software startup, your engineering tools are your sling and stone: if your tools are good and you can wield them with expert precision, you'll be able to iterate more quickly, make your users happier, and outpace the competition sooner.<p>Yishan Wong has written an excellent essay about the importance of tools:<p><a href="http://www.algeri-wong.com/yishan/engineering-management-tools-are-top-priority.html" rel="nofollow">http://www.algeri-wong.com/yishan/engineering-management-too...</a>

The short answer is no. The only exception I can even think of in extremely rare cases where you program something in a language some company would not want to use and may potentially not acquire you for (which for most web languages it's not an issue), it should not dictate how successful your application is in terms of users, revenues, growth, and/or overall outcome of the company itself. You may run into scaling issues, maintenance problems, ease of training and transitioning new employees to code base or language as need, etc... but for most things, it wouldn't make much of a difference.<p>On the other hand, if you're asking flow of code, nuances of particular languages, available libraries, ease of hiring people, etc... to help grow what you're building, then it goes back to the age old language war debate.

The one that was not written in BrainFuck would be significantly easier to add features to.

I think it influences success, but predicting that influence... is not easy

I would argue this has more to do with the developers familiarity of the language which would dictate speed of the initial build and speed of iterations.

A ideal language for startups requires three attributes:<p>Rapid application development<p>Open source distribution<p>Performance/scalability

Probably not, but one scenario which might make a difference is if the language used is disclosed to users. Fans of that language might hold up that site as an example of "See what this language can do?!", which might attract other fans of the language to the site who might otherwise not visit. See Twitter in the early days as an example (both good and bad) of Ruby/Rails, which brought a technical crowd to the site, who are great early adopters.

It depends on scalability, easiness to modify and adjust to changing web.