Hacker News Reader

Comment by pankajdoharey | Hacker News Reader

As we transition to a more multicore, multi threaded environment Ruby cannot perform well. And thus by induction Rails. An interesting way forward is functional programming, because of its composable nature can perform really well in such environments. I dont see where Rails ideal niche exists going forward, is it in Large Apps that need really scalable apps that exist on multicore environments? Does it lie in small SPA like apps for which it has virtually no support? or Does it lie in the middle where you just throw more hardware at the problem before rewriting the whole app? In the last one yr i have seen more enterprise apps being activated in Nodejs than in Rails. Why does the enterprise Like Nodejs while Rails is on its downward spiral? i suspect it has to do with Nodejs being Beginner friendly. I left the Rails ecosystem 3 yrs back never looked back, and i dont see why i would ever go back.

View on HN

Enterprise moves over to Node mainly because of hype, sometimes performance. Node is very library based, there is no framework that can compete with Rails there. In the wild Node web projects often lack a coherent structure because there is no agreed upon way to do things. Rails is perfect for e.g. inhouse websites in the enterprise.

It may not be just hype, Javascript is fashioned like C, most normal devs feel comfortable around C like languages. Infact a good testament to this is the growth of Typescript which makes both C# and Java crowd feel at home.

I'm not sure I agree with this, you can always achieve parallelism with multiple processes and IPC, and can do so fairly efficiently if communication is light.

Rails' biggest problem is that it isn't JavaScript, and thus code is not portable between client and server.

I have rarely seen the mystical pattern of "sharing Javascript code between client and server" actually work in a scalable and maintainable way outside of having a shared "enums" file.

Things like lodash, moment, validation logic, and http libraries are the big benefit of this. It is generally less of business focused code and more of utility type code that is easy to share. I do this on a daily basis, and have been for years.

If that were so true why would people rewrite apps in Go or use a JVM Language? Process based parellelism is memory intensive and you a=have no control, the best one can do is hope that the scheduler of the OS will take care of everything. Also code portability is not the issue, it is about what gets you started quickly scale well for a long time and dont ask for rewrites. Rails doesnt fit the bill, you cannot get started fast, It doesnt scale well unless you throw more hardware, MVC breaks with slightly complicated apps.

Ruby IS a JVM language today via JRuby. You get JIT, thread parallelism, and all the usual compacting GC goodness etc.

The GIL in CRuby means you need one process per core but that's also true of NodeJS.

Processes and threads aren't as different as you think. Linux pthreads are "just" processes which are allowed to write into the same memory. PostgreSQL remains process based to the day, although it does give them a little pain.

Out of curiousity, where have you found it useful for code to be portable between client and server?

I've been using Node.js/React together for a while, and I haven't found code reuse across client and server to be as important as I initially thought. The only code that I've tended to share is validation and a handful of utilities, which are a tiny proportion of the total, and even for those the business rules aren't always the same.

I've made a few multiplayer games where players need to keep a game state synchronized with the server. I used redux for state and game logic, and it's been really nice to be able to share the reducers between server and client. This made it so all I had to do to keep all clients in sync was share actions across clients as they happened.

I've also found it useful to have TypeScript on client and server to be able to share types between them.

Also, when using React, Node on your server makes server-side rendering a lot easier.

Personally not so much in model code, but in typescript interfaces/DTO which are used by both routing-controllers on the server side (additionally generating swagger api docs along the way) and by mobx on the frontend.

Rails is optimal for the web-tier which is traditionally scaled by being stateless, so you have one process per core (or thread if you are using JRuby) and you are done. It's ironic you list Node as the path forward since it is also single-threaded. Obviously it is more efficient on the baseline with async IO, but it still requires the same number of processes to saturate multiple cores, and you can also trivially eat into the IO overhead in ruby with green threads via Puma.

Reply on news.ycombinator.com