Hacker News new | comments | show | ask | jobs | submit login
Poll: For your startup, do you use Django, Rails, PHP or Other?
63 points by jw2013 1181 days ago | hide | past | web | 84 comments | favorite
Just ran into this poll (https://news.ycombinator.com/item?id=750142) that was made 5 years ago. And I am very interested to see if anything has been changed.
Python / Django, etc.
192 points
Ruby / Rails, etc.
190 points
PHP / Symfony, etc.
129 points
Other / .NET, Spring, Play, Compojure, Dynamo, etc.
109 points
Node.js / Hapi, etc.
105 points

We have Ruby, Python, Go, C, Node, Perl, Backbone and maybe a few others I'm not remembering right now.

When you're building distributed systems, you pick the right tool for the job.

Edit: And Assembly: http://youtu.be/zrSvoQz1GOs?t=15m44s I'd actually recommend the entire talk.

Are you guys building a business or just trying to have fun?

We're doing all right: www.fastly.com/customers

Still, why so many different? Must be really messy.

It definitely can be, since it's an infrastructural distributed system, but it's all unix when you break it down.

You can't just throw out a platitude like "it's all unix when you break it down." That doesn't actually make any sense.

When you use a bunch of different languages the primary difficulty you run into is interop. Some languages work well together by default and interop is easy, but this is almost never the case. Generally you're stuck making the decision between easy interop (RESTful APIs or your favorite RPC framework) and fast interop (JNI, swig, etc.).

So how do you guys actually deal with interop, other than to limit the need for it?

Go / Postgres / React & Fluxxor

Edit: forgot to mention go-tigertonic. :)

I just looked at Fluxxor and AngularJS. They use the exact same TodoList example in their quickstart guides. Turns out that AngularJS is simpler and easier to understand.

As someone who uses Angular.js every single day on some very large front-end apps, yeah, Angular seems simpler to understand, until your app gets large; Those small examples don't really show the benefit of the Flux architecture, as when it's that small something like Angular or other MVC frameworks with their magic and libraries really shine.

Heck, Angular is still excellent for large apps as well, as long as there is discipline in your development technique. The issue arises when you have a large team with varying skill levels, all working on the same front-end, with things stuck in the $scope when they shouldn't be, over-use and abuse of $watch, and a stack of other gotchas that make debugging an absolute nightmare, as tracing the execution flow is nigh on impossible.

That's where Flux is trying to do things differently. By having one way of passing data between the various components (and plugged directly into React, which also is built around a "componentized" architecture) you know exactly where to look when things go wrong, you give up a bit of dynamism and magic for explicitness, which in my experience is not a bad thing. That's my two cents anyway!

Node.js / Express / Postgres / React & Fluxxor

Really enjoying the Flux design pattern + declarative nature of React. I've been applying the Flux pattern to other applications (iOS) with great successful. The goal of one-way data flow and a single touch point for application events is a radical tool for complexity reduction.

Are you using any ORM for PostgreSQL in Node? Haven't found anything as good as ActiveRecord yet...

Check out bookshelf and knex

I'm trying to use Go+React and had not heard about Fluxxor. How do those (Golang and Fluxxor which is based on Node) fit together in your system?

Are you using a Node or Go frontend?

We're using Fluxxor on the client, not the server. It uses node for installation infrastructure, but after you bundle it up it's just another JS library to import with require.js (or whatever; it's agnostic about such things).

Scala / Play (and Spray) / Postgres

Starting to use Angular, experimenting with Akka / Spray

Java (Jersey, Jackson, Guice) on Google App Engine.

No iOS or Android? I would have thought the biggest change in the last five years (since you last conducted the survey) would have been the massive increase in startups working in mobile.

In this situation, iOS or Android would be more of a front end -- you'd still (usually) need one of the stacks in the poll. Using iOS or Android doesn't nullify this poll any more than using Angular or jQuery does.

We use R and Shiny server pro for our back-end. It's hosted on AWS EB with our static site on S3. We love it - the data scientists can write and push features directly, and everything (including our API's) are easily maintainable in R. I've been shouting the praise of R and it's usefulness as a production ready language for a long time.

Contact me with questions about data science, start ups, or R - if you have a data backed start up, R + Shiny is the way to go.

Last time I checked out shiny (about 8-12 months ago) it was still useless beyond the most trivial examples. Building an actual website that would be public facing seemed like a horrid idea at the time. Have they really come that far in such a short time?

Personally if I wanted to use R I could just interface with it from another language (Python, .Net, Java etc.) I haven't played enough with R recently to make an informed opinion on the current quality of its network libs and framework stack however it seems like an interesting gamble (that's paying off for you all?) given where the focus of the R community has been (statistical programming rather than general use) and statements on the front page of "No web development skills are required."

Shiny has a full time team working startup hours on it - it's out of beta and has enterprise support (Shiny server pro). It's come a long way to put it mildly; and we've never had a problem using it in production.

We could interface R with another language if we needed to... but we're a data-science company, and unlike many other co's or startups out there, we hire data-scientists who write features and applications directly. R makes this possible.

We have an Android App as part of our services - we use RServe as the API interface so we can call R functions from the App.

To your other point - web development skills are most definitely required, as are good engineering practices, and a stable stack. Shiny is just like any other framework; it takes a range of skills to create an application people want to use and pay for.

Perl. CGI::Application + FastCGI.

Erlang with the Nitrogen Web Framework (http://nitrogenproject.com)

Also, a future project I've been kicking around will likely be done with Erlang and ChicagoBoss (http://chicagoboss.org) - not because Nitrogen is lacking, just in the name of mastering another framework with a different focus.

We are using java. our crawlers are heavily threaded and we wanted somethi g that was both efficient and ran on app engine if needed.

Ruby + Grape / Polymer + CoffeeScript on the frontend with MySQL, MongoDB and Carbon as databases, using RabbitMQ to hook it all up. Right tool for the job with some legacy. There's an old school Rails project and some Python as well.

We use docker to make provisioning on Linux development machines less painful, vagrant/Capistrano + chef for the ops.

Scala / Play / Postgres

Go / Postgres / Angular

I'm surprised this isn't more popular: Python/web.py

Java / Guice / PostgreSQL and.... a custom framework!

.NET , because that's what I have lots of experience with.

Perl / Mojolicious

At work I've been working primarily with Ruby on Rails, but for personal projects and my fledgling startup, I'm using Django with Ember.js in the frontend.

Haskell / Scotty

Care to give anymore details? Tips on using this approach? Problems? Advantages? What do you think of mflow?

Well, I mostly do client side templating, so most of my functions end up being (ToJSON a) => ScottyT a, which simplifies matters. Problems: not thrilled with the error handling, I prefer using Either rather than the out of band exception stuff Scotty seems to use. However, it's Haskell, so I can almost always write a small function to do what I want. For example, param is :: (Read a) => String -> ScottyT a, and throws an exception if the param does not exist. It is trivial for me to write a function paramM :: (Read a) => String -> ScottyT (Maybe a), so the original problem is not significant.

Never used mflow, looks interesting, but I wouldn't use it.

Started with Rails & Node, moved much of Node to Go, introduced Angular and deprecating Rails where we can and moving the remaining Node to Go.

  Postgres, Cassandra
  Python (some backend services), Java (Jersey, MyBatis, Guice, + a lot of custom stuff)

We mainly use Grails for webapps. Most of our code is Groovy with a smattering of Java here and there, + some Javascript in the front-end.

For my own startup i used RoR, for freelancing clients i use Ruby/RoR, Node.js/Express/Sails, PHP/CodeIgniter.

Any thoughts on how mature Sails' ORM support is compared to RoR?

Last time i built an app on sails was March, and i couldn't compare it to RoR, ActiveRecord is far more superior IMHO.

Scala / Play / Postgres / Angular

Which ORM do you use to talk to posgres from scala? Slick / Anorm


Use PHP Laravel Angular at work. Rails for personal projects. If I were to start a new project Node + Angular I expect

Python + Django for the bulk of things. But also Perl and C++. Some tools are more suitable for tasks than others.

PHP with Laravel, node.js and angular.

PHP/nginx + MySQL, and a fully custom-built framework on top of PHP.

Custom-built framework: Why?

Cost of migration to anything considered "hipster" these days.

Groovy/Grails here.

C++/Qt + FastCGI

Interesting to see, what sort of applications?

ERP and multimedia streaming applications

Python / Tornado

Java Spring / Angular / Postgres/ Storm

Haskell / Yesod

Care to go into more detail? How are you handling storage, deployment, frontend. How useful are Shakespearean templates?

Well, I've a couple projects on Yesod, with some variation, but I'll focus on the one that has users outside my family.

Storage is Postgres; deployment is some overly specific (and slightly too manual) scripts I put together before Keter was mature (and haven't touched since); front end is mostly flat HTML generated from Hamlet (or markdown, through pandoc), gussied up with some JS where appropriate, but definitely more of a progressive-enhancement approach than a single page app.

With regards to Shakespearean templates, the languages for JS and CSS (Julius and Cassius/Lucius) are - in practice - of only mild use on their own. Hamlet is a bigger win - and, in particular, the ability to package up all three into a single widget to be embedded in arbitrary Hamlet, is great. And all the type safety is a nice bonus. One thing it does need is more exhaustive documentation - I don't think there's anywhere that actually specifies the "embed tag attributes from this list" or "generate a URL with parameters" sigils, save the source and mailing list. What documentation does exist is pretty solid, mind you, there's just some omissions.

Thanks for the reply. I've done a cursory run through of the "book", and wondered how close it was to an actual use of the framework in development.



glad to see i'm not the only one using PHP. reading HN sometimes give you the impression that PHP is only used by dinosaurs

Java Rest backend FTW! (No Spring!)

Does Flask go under other?

Flask is Python so it would fall under 'etc' on Python / Django, etc.

Sinatra as well as rails

Meteor / Meteorite

node.js / postgres / vue.js

Moving some of the API stuff to Go

Python / Django

Node, Mongo, Angular

Python / Flask



Scala / finatra / Backbone / postgres

Old stuff:


New development:


Any thoughts on Django vs Pyramid?

Django is just old-fashioned, frankly. It's stuck somewhere around 2005 or so. Pyramid allows you to use current best-of-breed in the Python ecosystem (SQLAlchemy, etc)



we use pyramid

Nice to see some Django. I had to move away from it and towards flask and rails since it was basically abandonware for years. I'm glad they are moving forward and that the project is hosted on GitHub now.

"since it was basically abandonware" FUD much? The project has been actively developed since public release.

Yes sir, while you were out the Django core devs have been killing it. Many thanks to those kind folks.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact