Ask HN: Could the back-end language influence the success of a Web startup?
17 comments
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.
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.
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.
I don't think you can attribute it to a "decline in HN", I think it's better attributed to the rise of a whole stack of languages, frameworks and software heavily optimized for web development, and the decline in hosting costs for any platform.
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.
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.
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.
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.
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.
Stackoverflow's answer:
http://stackoverflow.com/questions/341993/is-django-developm...
A technical manager's comparison:
http://kurtgrandis.com/blog/2010/02/24/python-django-vs-c-as...
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.
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.
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 care about the underlying stack, especially in any significant quantity.
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.
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.
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.
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.
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.
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.
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.
A little off-topic: Doesn't it bother you that with Node.js, a lot of the basic functionality needs to be coded (even with a framework like Express), while a framework like Django basically offers almost everything that you need? I really love the simplicity of Nodejs, but sometimes I just want to get things done instead of reading source code and trying to figure out how something works.
Thank you, and I agree!
I dont think languages differ most in prospects for success after you've reached functionally-complete-and-relatively-bug-free stage. The biggest difference is how do you get to this stage.
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 ;)
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 ;)
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.
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...
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...
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.
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.
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.
What if you hire developers to maintain the code? Doesn't the more readable syntax affect the developers' performance?
(Honest question, not trying to start a programming language flame war.)
(Honest question, not trying to start a programming language flame war.)
There are good coders, great coders, and just a bunch of awful ones. There's a difference in being able to code something that works, and something that works brilliantly, and even better at scale. That said, readability and good commenting in coding and documentation should apply in any language.
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).
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).
Doesn't the more readable syntax affect the developers' performance?
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?
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?
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
Right. Let's imagine that Facebook was written in Perl, YouTube in Ruby, and Twitter in PHP, do you think they would still be successful?
Facebook and YouTube yes. I am unsure about twitter.
Given that Facebook is written in PHP, and Twitter (I think) started out in Ruby, I'm not sure your assertion is well supported by your examples.
Keep in mind too, that the backend you launch with will not be the same as the backend you have at your multibillion dollar IPO. It _may_ still be written in the same language, but thats certainly not a given.)
Keep in mind too, that the backend you launch with will not be the same as the backend you have at your multibillion dollar IPO. It _may_ still be written in the same language, but thats certainly not a given.)
Could you please explain?
For facebook, considering how often stuff is broken.. I Think perl or php would've done a fine job.
For youtube, I think the pull is uploading / watching videos online, and it just doesn't have anything to do with the language they picked.
For Twitter, I'm not sure how it's successful in the first place, but I do feel like there was a lot of enthusiasm in the ruby community, simply because they were based on ruby. So if they picked say php, would they have had that early cache of users? I don't think so.
For youtube, I think the pull is uploading / watching videos online, and it just doesn't have anything to do with the language they picked.
For Twitter, I'm not sure how it's successful in the first place, but I do feel like there was a lot of enthusiasm in the ruby community, simply because they were based on ruby. So if they picked say php, would they have had that early cache of users? I don't think so.
So you're saying those three languages are so defective that they would have killed the startups that used them?
No, not at all. Do you think Facebook would have gone so far into implementing all the current features since the launch if the whole site was written in Perl? Same thing with YouTube and Twitter...
Um, sorry, was that intended as a clarification? You merely repeated your original question.
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:
Rapid application development
Open source distribution
Performance/scalability
Rapid application development
Open source distribution
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.
Would one version be more prone to success over another one?