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.
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?
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!
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.
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).
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.
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.
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.
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.
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.
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.
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)
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.
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.