Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Ruby on Rails Could Be Much Better (2008)

dreamhost.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: How Ruby on Rails Could Be Much Better (2008)

#21

Post by ollysb »

syspec wrote: post #16
dfischer wrote: post #13

Earlier quoted context omitted.

Elixir is the solution to this with similar ergonomics.

I've been experimenting with it, and it definitely has the feeling of working in rails / ruby. My only gripe is that the tooling is not as mature as rails. I use rubymine and the debugger has truly spoiled me. I tried to get the debugger going with a third party plugin for Intelli-j but it would crash when inspecting variables. Any tips?

I think most elixir dev's have a CLI based workflow where IEx.pry works very well.

Re: How Ruby on Rails Could Be Much Better (2008)

#22

Post by joelbluminator »

spyckie2 wrote: post #18
joelbluminator wrote: post #11

I think the next main challenges for Rails are improving the view layer (see upcoming ViewComponent for example) and better integrating with modern javascript (WebPacker feels half baked for gem writers). To me these issues (which both have to do more with the view layer) are where Rails is very much lacking.

I agree that the view layer has not been Rail's strength. It's largely handlebars era inspired and has never really changed. In some ways I think rails never really needed to change because the view layer worked without issues. I always felt the solutions in the modern html/javascript world were messy and half baked, with many unforeseen tradeoffs and complexity for the benefits you get (this summarizes my experience…

I'm fine with rendering html on the server without a SPA. But Rails view helpers need more love I think, watch Github's ViewComponent talk to see what I mean.

Re: How Ruby on Rails Could Be Much Better (2008)

#23

Post by dx034 »

nateberkopec wrote: post #5

To me, the only point on this list that hasn't improved much is "Ruby on Rails needs to more or less work in ANY environment". Ruby's install/user story for Windows is still Not Great, and Ruby version wrangling on any operating system is a question that you still get 100 answers to ("use asdf/rvm/rbenv/chruby blah blah blah"). For the rest: 1) It's certainly Fast Enough now. More important webperf issues are happeni…

> Who cares if your backend takes 500ms to respond when it takes 5 _seconds_ to compile the JS on the client.

Frontend should never need 5 seconds and a 500ms delay on the backend seriously impacts usability. Backend performance still matters, it saves cost (fewer servers), makes scalability easier and has a massive impact on usability.

Re: How Ruby on Rails Could Be Much Better (2008)

#24

Post by welearnednothng »

speedgoose wrote: post #12

I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.

This is not correct. When Ruby is doing I/O such as this is the only time it’s not blocking. This is due to Ruby, not specific to Rails.

Here are a few references: https://github.com/puma/puma/issues/1003 https://thoughtbot.com/blog/untangling-ruby-threads

Re: How Ruby on Rails Could Be Much Better (2008)

#25

Post by speedgoose »

welearnednothng wrote: post #24
speedgoose wrote: post #12

I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.

This is not correct. When Ruby is doing I/O such as this is the only time it’s not blocking. This is due to Ruby, not specific to Rails. Here are a few references: https://github.com/puma/puma/issues/1003 https://thoughtbot.com/blog/untangling-ruby-threads

I have to admit that I have not used puma for development.

Edit: your links show that indeed its blocking and you need to spawn many threads/instances, which use memory.

Re: How Ruby on Rails Could Be Much Better (2008)

#26

Post by joelbluminator »

speedgoose wrote: post #12

I think Ruby on Rails should be more asynchronous. Doing a http request or a sql query blocks everything until it finishes. The solution is to spawn many instances, but it uses a lot of memory and a slow http service may block all rails instances very quickly.

I don't think that's true - the Ruby VM switches threads when blocked on IO like http or db. This happens regardless of what Rails is doing. Maybe you're talking about suboptimal usage of cores...afaik it's indeed being worked on in the Ruby community and it's not something Rails can solve.

Re: How Ruby on Rails Could Be Much Better (2008)

#27

Post by ryan-allen »

nateberkopec wrote: post #5

To me, the only point on this list that hasn't improved much is "Ruby on Rails needs to more or less work in ANY environment". Ruby's install/user story for Windows is still Not Great, and Ruby version wrangling on any operating system is a question that you still get 100 answers to ("use asdf/rvm/rbenv/chruby blah blah blah"). For the rest: 1) It's certainly Fast Enough now. More important webperf issues are happeni…

Ruby would work great with WSL on Windows these days, I'm assuming.

Re: How Ruby on Rails Could Be Much Better (2008)

#28

Post by fphilipe »

syspec wrote: post #17
burlesona wrote: post #6

Earlier quoted context omitted.

The answer is rbenv :) The ruby language has also sped up a lot since 2008, which has helped Rails. I catch your point about the slowness being in the client these days, but 500ms would be an exceptionally unusually slow response from the rails application in any of the production rails apps I’ve run.

I'm still using RVM, is RBENV the recommended approach now? What are the key differences for a user?

I've switch from rbenv to chruby[1] years ago. Seems simpler and doesn't have the rehash command that is (was?) required with rbenv. All it does it adjust your PATH.

1: https://github.com/postmodern/chruby

Re: How Ruby on Rails Could Be Much Better (2008)

#29

Post by cutler »

nateberkopec wrote: post #5

To me, the only point on this list that hasn't improved much is "Ruby on Rails needs to more or less work in ANY environment". Ruby's install/user story for Windows is still Not Great, and Ruby version wrangling on any operating system is a question that you still get 100 answers to ("use asdf/rvm/rbenv/chruby blah blah blah"). For the rest: 1) It's certainly Fast Enough now. More important webperf issues are happeni…

4GB ram is even cheaper at Hetzner.com. No, I'm not an affiliate.

Re: How Ruby on Rails Could Be Much Better (2008)

#30

Post by mmahemoff »

syspec wrote: post #14
joshmn wrote: post #9

Worth noting about the shared hosting argument: Dallas (author) is a co-founder of DreamHost. DreamHost, at the time, was very invested in selling "unlimited everything" shared hosting plans.

As a Dreamhost user since 2003 or so, their shared hosting claims to let you run rails but I never had any luck running rails on their platform. I'm sure it's better now though I suppose

Think I ran a basic Rails app via passenger on it around 2010, but it was a hassle setting up and I don't think it got any easier. And running Node is completely off limits on DH shared hosting.
Post reply on HN