

What language is the majority of startups using today? - rob

Based on what I can see, it looks like more and more people are switching to Python and Ruby from PHP.<p>What's your startup using and your reason for choosing said language?
======
nostrademons
Python + JavaScript + Flash.

The server-side choice between Python and Ruby is completely arbitrary; I
suspect either one could do the job equally well. I was swayed by the somewhat
greater availability of libraries for Python, plus I thought it'd be easier to
get Python programmers if we got big enough to hire, plus it's somewhat more
likely that an acquirer will use Python than Ruby.

PHP or Perl could also have done the job equally well, but I figure that if
I'm gonna code my ass off for a year or two, it might as well be in a language
that I enjoy. I've written some decent-sized PHP projects before, I'm
reasonably fluent in the language, and I just don't want to deal with its
gotchas.

On the client side, your choices are much more limited. Basically, if you want
to do any sort of rich embeddable widget, it has to be Flash. That's the only
technology available on nearly every browser that isn't blocked by 3rd party
websites for security reasons. If you want to do rich interfaces on your own
site that don't run in a box, it has to be JavaScript.

~~~
bootload
_"... Python + JavaScript + Flash. ..."_

Nostra... what's the front/back ratio? I remember reading Ryan from Wufoo's
_"Web App Autopsy"_ ~ ( <http://particletree.com/features/web-app-autopsy/> )
was quoting 60% front-end to 40% back-end code ratios.

~~~
nostrademons
Hard to tell what the finished product will have, because we're nowhere near
done. The site that's currently up at www.diffle.com is 707 lines of HTML, 733
CSS, 6283 Python (including all server administration tools), and 81
JavaScript. (These figures include comments and tests, which are fairly
extensive in the Python and basically omitted on the frontend.) However,
that's a very Web 1.0 site, with AJAX used in only a couple places where it
really improves usability.

The 8 or so prototypes we've done for the more dynamic aspects total about
1000 lines of JavaScript and 3107 lines of ActionScript, but this is
misleading. Since they're prototypes, they often copy straight from each other
and don't bother to factor out common functionality.

I'm expecting it'll be something like 60/40 front/back by the time we're done,
with nearly all of the post-launch code going on the front. But much of the
JavaScript and ActionScript may be generated by Python scripts running on the
backend. Kinda hard to say what's front-end and what back-end then.

------
thingsilearned
We spent considerable time testing Django, Plone (not really a framework),
PHP, and Cake PHP. We ended up going with django (Python). Really quick to
learn. There's some documentation lacking once you get really deep and start
doing some crazy stuff, but its more than made up for by a very helpful IRC
community. We love it!

------
adrianh
Django and Python. Because they're just that good.

But, really, use what you're good at. If you're working on a startup, do you
really want to spend valuable time getting up to speed with a programming
language that you don't know and are only learning because random people on
the Internet told you they were using it?

~~~
nostrademons
"If you're working on a startup, do you really want to spend valuable time
getting up to speed with a programming language that you don't know"

I did that.

It probably hurt the startup a bit - we'd be moving much faster if I didn't
have to learn the technologies as I went along. Thing is - the web
technologies I really know well consist of PHP and JSF, and I know them well
enough to know that I do _not_ want to be programming in them if I can help
it.

I figure that any startup will be taking up a good chunk of your time, and you
might as well make it at least semi-enjoyable. I'd much rather put in the up-
front effort to learn Python and have a tool that can grow with me than curse
PHP's naming conventions or lack thereof for the umpteenth time.

------
johnrob
Rolled my own framework with mod_python. I am sick of reading docs to figure
something out. Also, the bugs in my framework code are easy to fix compared to
those found in the 'real' code. I don't think the cost of a home grown
framework is high if you spend more than a few months on something.

------
german
We speak Spanish and English. Also Python/Turbogears and Javascript.

------
epi0Bauqu
Perl. Reason: I can build scalable things in it really quickly. For people
deciding between different languages, I think the main selling points for Perl
are a) most of the code is already written for you (see
<http://search.cpan.org/>) and b) it scales really well (see
<http://perl.apache.org/>).

------
henning
Here is what I have learned from 2 years of questing for the One True
Language:

there is no one true language and you should focus on accomplishing specific
goals and getting stuff shipped instead.

------
adamdoupe
I'm currently researching Python with Django as the web framework. Coming from
a decent size website in RoR, Django is looking quite promising. I'd love to
hear what people's experiences are using Django.

------
joshwa
<http://news.ycombinator.com/item?id=10748>

~~~
jimbokun
There seem to be more references to Lisps (Common Lisp + Scheme) in that
thread than this one.

Has anyone previously using a Lisp for your startup since abandoned it? What
were the reasons?

------
niels
I used webpy for my last site, but recently changed development to django.
Django is really easy to learn, and provides a full stack of components that
integrates really well together. I used AJS javascript library, but has
changed to JQuery this time. Mostly because of JQuery's numerous plugins.

~~~
steve
I'm using webpy for a few sites and it seems great to me. Are there many
reasons for the switch? Or did you just want to try something new/better
supported?

I'm thinking of taking a look at django just because guido tells me to, but I
don't see any strong reason to switch.

~~~
nostrademons
I've found that I had to gradually replace large parts of web.py as my webapp
evolved. For instance:

I had to drop the built-in DB library once I needed to connect to multiple
databases. Global DB connections = bad. I suspect that if I'd kept using it, I
would've had problems with transactions too.

I had to replace some of the request dispatching when I wanted to add code
that triggers on every request (eg. logging, transactions, custom session
management, "who's online?", traffic analytics).

I had to drop the Cheetah integration to add internationalization support -
Cheetah supports the _ function, but only in precompiled templates.

I had to drop Cheetah entirely as the templates got a little more complicated
and I wanted to factor some bits out. Web.py patches the Cheetah #include
directive to do what you'd expect: include a file at compile-time (which is
the same as runtime under web.py). With precompiled templates, however, it
includes it at runtime, which means the included file can't have any #defs.
Big pain.

It's not a bad framework to start out with, but you _will_ end up needing to
ditch nearly all of it by the time you've handled everything a typical webapp
needs. If I were to do it over again, I'd probably start with Pylons. I'd
consider Django, but I'm not sure you can swap out Django components the way
you can with Pylons.

~~~
Keios
I use Python-Pylons/JS and Schevo for the backend. I have some experience with
Django. Pylons is much better for serious programming - Django is better if
you want to make a run of th e mill app like a blog. Using Pylons is like
working with Lego bricks - stuff is swappable easily - not so with Django.

~~~
steve
Yes, that's what I need and pretty much what webpy feels like to me.

If I were to switch to anything else, I'd probably try plyons first.

------
rzwitserloot
No question. PHP. However, this doesn't mean you should follow suit. In
particular, PHP works best as a vanilla choice, something to get set up with
quickly. The moment you start using e.g. Cake, the point of PHP is no longer
and you should look elsewhere.

There's no useful answer in any case, just hints and use cases. It depends
entirely on what you're building.

Heavy single-purpose web app like gmail? No question - GWT.

Light multi-purpose web app with lots of pages but where some ajax here and
there wouldn't go amiss: rails looks good.

etcetera.

~~~
vlad
I disagree. I believe the opposite: GWT is a bad choice, mainly because GWT
has to be compiled every time. It's much better to use a framework, including
ones for PHP, since PHP is faster than Ruby and most popular frameworks have
memcached support, and a great community.

Also, most frameworks are evolving FAR quicker than GWT is.

Thirdly, GWT will still require server-side coding. You might as well use a
framework with an Ajax library or just plain html output, and then add-in GWT
or Adobe Flex later, if at all.

Fourth, GWT does not have anywhere near the community or IRC users that most
frameworks do.

But, mainly, GWT is a bad idea because it loses the advantage that web
frameworks give to web startups over desktop development. That's because using
GWT can be even slower than using traditional desktop development tools like
Visual Studio because you not only have to compile, but also upload the files
to get a real idea of what you're doing.

Why not just use a console with a web framework, or something with both in one
like Seaside? As soon as you save the file, the change exists.

~~~
edgeztv
There are a few misconceptions about GWT in the above comment:

"most frameworks are evolving FAR quicker than GWT is."

GWT is only a year old and has had 4 major releases. It just went open-source
recently, so it's too early to tell how fast it will evolve.

"GWT does not have anywhere near the community or IRC users that most
frameworks do."

GWT community is huge - there are over 600 posts a week on its Google Group.
I'm not aware of an IRC channel for it though.

"using GWT can be even slower than using traditional desktop development tools
like Visual Studio because you not only have to compile, but also upload the
files to get a real idea of what you're doing."

No, you only need to upload files when you're actually doing a release.

~~~
vlad
You used the word misconceptions, but I don't think I was wrong about anything
I said if you read what I wrote carefully.

I'm not sure where you disagree since you are defensive about GWT, when I
never said it was bad, just that using a web framework is a much better idea,
especially at first.

How can you predict how many users GWT might have in the future when Adobe
Flex and Apollo are around the corner?

On the other hand, the server-side coding won't change from PHP, Python, or
Ruby for most startups over the next year, however, and their web frameworks
are much easier to use and integrate than GWT.

I like GWT, but I think it requires at least one or two additional orders of
magnitude of time to get something going. Plus, you'd still have to write
server-side code to handle the ajax calls, so you may as well need to start
with a web framework anyway!

And remember, you don't have to compile all the time with web frameworks.

Finally, the "major" releases you mention have been very minor. For example,
One of the VERY few releases GWT has had in the past 8 months involved Google
changing their source to be open source, without making any improvements that
I can remember.

If you started with a toolset, you should stay with it. But if you're starting
a new project, use a web framework.

What would be great is if this prediction comes true:

[http://getahead.org/blog/joe/2007/05/11/googles_next_open_so...](http://getahead.org/blog/joe/2007/05/11/googles_next_open_source_project.html)

~~~
edgeztv
Adobe Flex a very different approach to the rich client model. GWT will be on
the same side as Prototype, Dojo, etc. if there is a showdown with Flex. Flex
is not an alternative to GWT but rather an alternative to AJAX. I suspect both
sides will continue to coexist peacefully.

Keep in mind that GWT is not a full web framework. So it's pointless to argue
which is better, web framework or GWT, just like apples and oranges. You can
use GWT with whichever back end framework (e.g. Rails) you want if you choose
to go that route. Like I said earlier, GWT is an alternative to JS frameworks
like Prototype, not server frameworks like Rails. What GWT does allow you to
do is not use a web framework at all since its server-side calls are very easy
to implement. But if you require a DB, etc, you can still use Rails and GWT.

------
Zak
Common Lisp, but my project is a poor representation of "the majority of
startups" because it's not a web app or a social networking tool. It also
doesn't qualify as a startup yet, but that's the goal.

------
davidw
English. It's pretty popular even in Europe, because it bridges borders.

In terms of programming languages, Ruby all the way, with some Java (j2me) and
Hecl thrown in.

------
samson
Can someone please tell me why everyone is so anti-php these days. I'm been
working on my web project this summer in php, and it seems like every self
proclaimed web 2.0 site is choosing either python or ruby.

I feel like I'm on the wrong side of the road, and php is web 1.0. I wonder
though, do users care what language the site is made in? And has usuability
and quality of a site become determined by programming language?

~~~
adamdoupe
To answer your question, the only thing users care about is what your site
does and if it does it well. The only people who care are the other people who
are developing websites as well.

Basically I see the PHP backlash coming out of many painful personal
experiences that hit the limitations/drawbacks of PHP. I've maintained a large
social networking site written by someone else and I can tell you it was a
stinking pile of spaghetti.

I think the power comes from using a framework like RoR of Django that
abstracts aways common parts of web development. Plus I see it as a way to
keep from reinventing the wheel which leads to simpler code. And we all love
simple code.

Anyway, just my thoughts on the matter.

~~~
garbowza
Good point, adamdoupe. I've created a large project in straight PHP and it was
a mess. Now I work with CakePHP, a framework similar to Rails, and it's 100...
no, 1000... times cleaner and more scalable!

------
staunch
Perl with Catalyst, DBIx::Class, and Template Toolkit. All the actual every-
day code is really simple because all three are designed for extensibility. I
just write little plugins that abstract away the repetitive stuff. I also
write lots of long-lived systems daemons. They do all the asynchronous tasks
in a super efficient way. Not enough people use this technique in my
experience.

~~~
randallsquared
I just use cron for asynchronous tasks, because it's less complex to write for
(just write the script to do the task once, after all), and any unix will
already have cron running for other things.

~~~
staunch
Yeah cron works for lots of stuff. Some things need to happen asynchronous but
more quickly than is convenient to do with cron. Not enough people use cron
jobs though either.

------
theremora
I am not a developer but here is what Tabblo's founder has to say about
Django. Tabblo was acquired by HP 9 months after
launch.[http://theonda.org/articles/2007/07/02/now-with-django-
power...](http://theonda.org/articles/2007/07/02/now-with-django-powered-
goodness)

------
dshah
We're using C#/ASP.NET (which though rare across startups, has worked out well
for us so far).

------
jayded
See Red vs. Blue if you're deciding on Ruby/Rails vs. Python/Django

<http://jng.imagine27.com/articles/2007/07/12/red-vs-blue>

------
damir
Does it really matter? Use whatever makes YOU most productive, because at the
end of the day the only thing that matter is a simple answer, yes or no. The
question is always the same: Is it done?

~~~
mynameishere
I'm using Java, too.

------
SwellJoe
During WFP07 it looked something like this on the backend:

45% Ruby (mostly RoR, but one might not have been using Rails) 30% PHP 15%
Java 10% Perl

Almost all of the groups were heavily using JavaScript, as well. In fact, some
of them were predominantly JavaScript with quite lightweight back-ends (Zenter
and Weebly come to mind). Heysan were predominantly Flash at the time, but I
believe they have a lot more PHP back-end code now.

I don't believe there were any Python projects.

------
temporary
The language that best solves the problem and that scales.

------
rami
CakePHP + Scriptaculous. CakePHP was easy to learn, however the documentation
is not complete, you'll have to read the code for advanced features.

------
nickb
Python (with Django) and RoR.

~~~
adamdoupe
If you had to choose one, which would you pick?

~~~
nickb
We went with Python + Django. It was an excellent choice for us! We don't have
any performance & scaling issues so far (and we have a pretty big site
already) and programmer productivity has been nothing short of amazing.

In the end, pick whatever you feel more comfortable with and whatever the
market you have company in supports. If it's easy to find RoR folks around
where you live, use that... if it's easier to find Python people, maybe you
should use Python instead. They're both excellent languages and a huge
improvement over Java/C++/C#.

------
zurla
RoR is great for making a prototype, but just wait until you try to find other
good rails hackers. they're scarce.

~~~
davidw
Finding good hackers is difficult in any case. If you manage to get one, they
can learn Rails quickly. Unless you have a very urgent, short term need,
you're taking the wrong approach if you're searching first and foremost for a
rails guy rather than just someone who's good and willing to work with rails.

------
brlewis
<http://brl.codesimply.net/>

Reason: I'm doing a database-driven web application, and I designed this
language exactly for that purpose.

------
arhar
We use Ruby on Rails with a lot of JavaScript for Ajax-y thingies. So far
there's only 2 of us, but looks like here in NYC there's more than a few RoR
devs.

~~~
cellis
everyone is going to shoot me for this, but we are building our project in C#
(debug time + .NET library),C++ (faster sockets), actionscript (not flex) and
ajax

~~~
randallsquared
If you can do reasonably rapid development with that, more power to you. :) At
least the result should be fast.

------
wensing
Python (pylons) + JavaScript + Flash, and loving it!

I used to use PHP, but once I tasted Python I couldn't go back.

------
tim
Python and Django for web stuff, C++ for desktop stuff (games, 3D
applications)

------
ivankirigin
python + django

------
vikram
lisp + javascript

------
cosmok
LAMP bundle.

------
robin_bb
Haskell.

------
twism
Java

------
entelarust
php

