I remember setting up a Rails 2.x app on Dreamhost in 2009. At that time it was indeed more complicated than PHP (although mod_passenger made it manageable), but Rails was so productive and fun that it was well worth the extra setup effort.
How Ruby on Rails Could Be Much Better (2008)
41–50 of 63 posts
Re: How Ruby on Rails Could Be Much Better (2008)
#42Earlier 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?
[deleted]
Re: How Ruby on Rails Could Be Much Better (2008)
#43This really should be titled "How Ruby on Rails Could Be Much Better for Shared Hosting", as that's where the issue really was for Dreamhost at the time. In a shared hosting environment back then: * You didn't get root shell access. Dreamhost were (and still are) one of the good platforms in that they allowed shell access at all. Many shared hosting platforms didn't even do that, requiring you to upload files using F…
They should rebrand shared hosting as function-as-a-service AWS Lambda-alike. It's basically the same thing: startup and run this code, then return a response and exit.
Re: How Ruby on Rails Could Be Much Better (2008)
#44I remember this era like it was yesterday. Ruby on Rails in 2008 was on 2.1 or 2.2 (before it was merged with merb) and was 70 or 80% of the way there before it was mature. I think rails 3.0 is when the framework matured and stopped changing so much. There were a lot of decisions back then that were made because it fit the rails vibe, like the fast adaptation of coffee script. In some ways it was a mistake, but in ot…
It still has trouble running on Windows, unless you're using WSL2 in which case it runs like a champ.
Re: How Ruby on Rails Could Be Much Better (2008)
#45> “Zed Shaw”
Wow, that’s a person I haven’t heard from in ages.
He was a Big Flipp’n Deal back in the day (Mongrel, Spats with DHH, etc). Curious to know what he’s up to now.
Re: How Ruby on Rails Could Be Much Better (2008)
#46Earlier quoted context omitted.
Elixir is the solution to this with similar ergonomics.
The company I work for (mostly standard Web Dev) uses almost exclusively Elixir for any backend work. Only the fanboys of Elixir and functional everything are happy with it, just to be different to everyone else. The experience is terrible: Tooling (editor plugins, tests runners, IDEs (oh, there are no IDEs...), debugging) is like going back 20 years. There are no libraries for the most basic stuff you get almost by…
Really? I've been able to find everything I need in the Elixir ecosystem from auth to background jobs and one of if not the best GraphQL server implementations out there. Do you mind sharing which libraries you found missing or incomplete?
Re: How Ruby on Rails Could Be Much Better (2008)
#47> “Zed Shaw” Wow, that’s a person I haven’t heard from in ages. He was a Big Flipp’n Deal back in the day (Mongrel, Spats with DHH, etc). Curious to know what he’s up to now.
Yeah, he was amusing too with his rants and general disposition. Came up on my instagram feed, he's into art and oil painting. Don't know about his tech lately. Jumped on that DHH hype train back in the day. Actually still have a rails app running mongrel from back then.
Re: How Ruby on Rails Could Be Much Better (2008)
#48> “Zed Shaw” Wow, that’s a person I haven’t heard from in ages. He was a Big Flipp’n Deal back in the day (Mongrel, Spats with DHH, etc). Curious to know what he’s up to now.
Authoring books: https://twitter.com/lzsthw
Re: How Ruby on Rails Could Be Much Better (2008)
#49Earlier quoted context omitted.
Elixir is the solution to this with similar ergonomics.
The company I work for (mostly standard Web Dev) uses almost exclusively Elixir for any backend work. Only the fanboys of Elixir and functional everything are happy with it, just to be different to everyone else. The experience is terrible: Tooling (editor plugins, tests runners, IDEs (oh, there are no IDEs...), debugging) is like going back 20 years. There are no libraries for the most basic stuff you get almost by…
That's not the experience I had with the environment. The tooling is amazing and the libraries are plenty for pretty much anything.
Re: How Ruby on Rails Could Be Much Better (2008)
#50This really should be titled "How Ruby on Rails Could Be Much Better for Shared Hosting", as that's where the issue really was for Dreamhost at the time. In a shared hosting environment back then: * You didn't get root shell access. Dreamhost were (and still are) one of the good platforms in that they allowed shell access at all. Many shared hosting platforms didn't even do that, requiring you to upload files using F…
They should rebrand shared hosting as function-as-a-service AWS Lambda-alike. It's basically the same thing: startup and run this code, then return a response and exit.
Rails doesn't have fast boot times even now. exiting after each request would result in much slower apps. Also, you couldn't reuse database connections so you'd get additional latency built into starting up a new connection with your db.
This isn't just a Rails thing either.
FAAS is a good thing. I'm a big fan. It's essentially the same thing as CGI which was awesome back in the day, BUT there are multiple good reasons to choose a framework that isn't constantly exiting.