4 ms·

As we transition to a more multicore, multi threaded environment Ruby cannot perform well. And thus by induction Rails. An interesting way forward is functiona

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.

erokar 8y ago
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.
- pankajdoharey 8y ago
  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.
bodas 8y ago
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.
- haggy 8y ago
  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.
  - lghh 8y ago
    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.
- pankajdoharey 8y ago
  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.
  - jashmatthews 8y ago
    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.
- strken 8y ago
  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.
dasil003 8y ago
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.

erokar 8y ago

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.

pankajdoharey 8y ago
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.

bodas 8y ago

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.

haggy 8y ago
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.
- lghh 8y ago
  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.
pankajdoharey 8y ago
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.
- jashmatthews 8y ago
  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.
strken 8y ago
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.

dasil003 8y ago

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.