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.
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?
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.
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.
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)
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).
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!
95 comments
[ 3.3 ms ] story [ 197 ms ] threadWhen 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?
Never used mflow, looks interesting, but I wouldn't use it.
Python/Django
New development:
Python/Pyramid
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!
Moving some of the API stuff to Go