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.
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?
Edit: forgot to mention go-tigertonic. :)
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 a Node or Go frontend?
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!
Starting to use Angular, experimenting with Akka / Spray
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.
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."
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.
We use docker to make provisioning on Linux development machines less painful, vagrant/Capistrano + chef for the ops.
Never used mflow, looks interesting, but I wouldn't use it.
nginx
Postgres, Cassandra
RabbitMQ,
Python (some backend services), Java (Jersey, MyBatis, Guice, + a lot of custom stuff)
AngularStorage 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.
Moving some of the API stuff to Go
Python/Django
New development:
Python/Pyramid