News for hackers. Stuff that matters.
Re:Why I wouldn’t use Rails for a new company by davmar on Thursday September 17, 2015 @06:05PM (#10236361)
So the new framework of choice now seems to be Node according to his graphs. I'm building in Node as we speak and I'm not loving the Promise pattern to solve callback hell. Will I get over it? Have others?
Re:Why I wouldn’t use Rails for a new company by 0x0 on Thursday September 17, 2015 @06:08PM (#10236374)
There was a pretty elegant post on how Python's coroutines can replace callback hell with almost-synchronous-looking async code on HN the other day: https://news.ycombinator.com/item?id=10220712

Wonder if something similar will catch on in the node ecosystem?

Re:Why I wouldn’t use Rails for a new company by supster on Thursday September 17, 2015 @07:04PM (#10236617)
Yeah ES7 has async and await which are pretty similar to that

source: http://www.sitepoint.com/simplifying-asynchronous-coding-es7...

Re:Why I wouldn’t use Rails for a new company by lastofus on Thursday September 17, 2015 @06:23PM (#10236455)
Everyone forgets that Gevent has been around for years, and lets you write completely synchronous looking async code.
Re:Why I wouldn’t use Rails for a new company by vangale on Thursday September 17, 2015 @06:51PM (#10236575)
I think a better way of looking at it is there isn't enough "cross pollination" in big open-source frameworks and languages.
Re:Why I wouldn’t use Rails for a new company by M2Ys4U on Thursday September 17, 2015 @06:41PM (#10236530)
promises, async functions and generators will make writing async code look more sync in javascript/node.

Whether or not this is a good thing or not, I'm undecided.

Re:Why I wouldn’t use Rails for a new company by hayksaakian on Thursday September 17, 2015 @06:09PM (#10236378)
Re:Why I wouldn’t use Rails for a new company by zachrose on Thursday September 17, 2015 @06:36PM (#10236501)
You might get over it! I feel I have, and now see callbacks as suggestions of where to break my code apart. For example, callbacks nested more more than a two deep are usually a remonder that I'm really trying to describe a series of steps with a common error and success handler, and the library "async" has a method called waterfall that does exactly this. Naming those steps keeps them simple, exposes commmonalities, and often leads to reuse.

That said, the thrust of this article is that you should make your technical decisions based on the absolute most trending thing at the moment, and I think that's bogus. Plain old syncronous programming has its place.

Re:Why I wouldn’t use Rails for a new company by olouv on Thursday September 17, 2015 @06:09PM (#10236379)
Have you tried bluebird? It solved all my issues with async workflow in NodeJS, crazy-fast performance coupled with a very nice lodash-like API that makes working with data a breeze.
Re:Why I wouldn’t use Rails for a new company by davmar on Thursday September 17, 2015 @06:30PM (#10236483)
i'm using it and it's nice as you said. i'm not a node expert yet, this is my first large project. i'm sure i'll get more fluent as i go along but this programming style was an unanticipated twist in the road.
Re:Why I wouldn’t use Rails for a new company by raksoras on Thursday September 17, 2015 @06:20PM (#10236443)
Re:Why I wouldn’t use Rails for a new company by dkulchenko on Thursday September 17, 2015 @06:12PM (#10236389)
Switching from Ruby, I used the Fiber pattern (await-defer) heavily in Node via node-fibers & synchronize.js which alleviated a lot of the pain.
Re:Why I wouldn’t use Rails for a new company by danneu on Thursday September 17, 2015 @06:45PM (#10236549)
I use Koa ("Express' successor") which uses co/generators to let you write familiar sync-looking code.
Re:Why I wouldn’t use Rails for a new company by idibidiart on Thursday September 17, 2015 @06:47PM (#10236553)
Use Node 4.x with ES7 and Async/Await for replacement to Promise pattern. Use async-csp for more demanding scenarios.

Node 4.x is awesome (relative to Node 0.12)