Would one version be more prone to success over another one?
http://www.paulgraham.com/avg.html
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?
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.
Today you can spin up an EC2 box for pennies an hour, even with Windows, and push a new build live or publish a new site just minutes later - very different to 16 years ago.
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.
Once you've proved the problem is worth solving, _then_ do your massive-scale system architecture, and choose the ongoing backend based on that.
Python/Django wins! I've also heard anecdotal evidence of a .Net killing a person's startups because of the difficulty of development.
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 & more elegant to do it in django.
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 something than some other language, it's going to be hard to find awesome 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.
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.
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.
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.
Stick with a language you love and it will influence the success of your startup.
For a medium-to-big sized web application it would take you years to implement it in asm ;)
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.
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).
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 ;)
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.
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 ;)
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.
Yishan Wong has written an excellent essay about the importance of tools:
http://www.algeri-wong.com/yishan/engineering-management-too...
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.
(Honest question, not trying to start a programming language flame war.)
In Python for example, there's kind of a (mostly) default way of doing it. In other languages, not so much. But that doesn't mean the company culture can't push for something like this (a standard, at least to the extent in which a language permits doing so). Developers performance is more base on how they like working in a language (better to find true language agnostic developers), culture fit, personality, etc...
If you're outsourcing, that's a totally different set of traits and number of things to look for than if you're hiring in house (which I would recommend for the core team and in general anyway; hiring in house that is).
What does "readable" mean? If "readable" means "I don't like sigils" or "operator overloading confuses me" or "everyone should indent their code the same way", I suspect you won't get any interesting answers.
Have the developers any experience in this language? Have they significant experience in this language? Have they any experience with the other developers? Have they significant experience in the problem domain?
Rapid application development
Open source distribution
Performance/scalability