7 ms·

I posted this same comment to /r/ruby when this article was posted there: Having serious large scale full stack Rails and non-Rails (Py or Node) under my belt

I posted this same comment to /r/ruby when this article was posted there: Having serious large scale full stack Rails and non-Rails (Py or Node) under my belt now, it has become ever so clear how productive Rails is and how much of that is the fact that Ruby actually has a f*ing standard library (directed at JS). So I'm not surprised by these numbers. Then with gems like devise, filterrific, simple_form, cocoon, carrierwave, sidekiq, and activerecord-import I can whip together apps so quickly it just boggles my clients' minds. The ecosystem is deep, rich, documentation is good if not great and the language has several paths to getting some serious speed improvements behind it (Graal/Truffle/Substrate and JIT). Implementing the simplest things in the node ecosystem sometimes feels like wading through molasses. I love ES6/7 but damn for 95% of projects today regardless of (anticipated) scale I'd choose Rails to start with and then split off just the things which need to be fast or fancy like Delayed Processing / MQs, ETL, any data science, etc.

kendallpark 8y ago
I'm completely with you. Rails is still my go-to for short one-off projects that I need to build something FAST. Hell, I even use it for quick n' dirty data analysis because working with Active Record is so easy. Rake import the data, then muck around with the Active Record models in Rails console. I honestly prefer this to working with Jupyter notebooks, unless I need graphing or something fancy out of sklearn. "Rails can't scale" is a misnomer. Heroku and Github are RoR apps (or at least started there). At scale you might start pulling in some other services and technologies.
geekjock 8y ago
Agree completely. I enjoy programming with other languages but nothing beats Rails when it comes to getting a product out the door. Last week I found out that a Rails app I built for a SAAS company many years ago is still running reliably and generating millions of dollars per year. The painpoints I often run into with Ruby/Rails are concurrency and memory use. Both are addressable though.
- thomasfedb 8y ago
  In the time it takes to configure Webpack I can write an app in Rails. Convention. Over. Configuration.
  - deleted 8y ago
    [deleted]
  - geekjock 8y ago
    Hah, so true.
- armandososa 8y ago
  I never learned Rails. What would you say is the best path to write a modern rails application? I learn better trough videos, btw :D
  - lgregg 8y ago
    There are lots of playlists on youtube with tutorial walkthroughs. I'd go look for someone's todo app on Github and compare it to a language you know. Then write a todo app. That'll give you the initial questions you need to keep learning.
  - tortilla 8y ago
    https://gorails.com/series https://gorails.com/series https://www.railstutorial.org/ https://www.railstutorial.org/
vinceguidry 8y ago
Preach that gospel truth. It's still as true now as it was 2000^H^H^H^H10 years ago. We're porting a project over to node now. God I hate it.
- w8rbt 8y ago
  Why move? How is node better? Really honest question, I've never used either much.
  - vinceguidry 8y ago
    Beats the hell out of me. I didn't make the decision, and objected as strongly as I could.
  - tim333 8y ago
    While I'm not expert, node goes faster and makes real time stuff like instant messaging easier. Like for example I had a look at hackthon starters in rails, django and node and the node one has this cool dashboard https://hackathon-starter-2018.herokuapp.com/status https://hackathon-starter-2018.herokuapp.com/status I think stuff like that is hard to do in rails. Also I was trying to do instant messaging in web2py and gave up and just wrote a service in node which was like 10 lines with express/socket.io. Pragmatically I think it may be easiest to write the main app in rails of similar and link to a separate bit of node for stuff like the above.
    - vinceguidry 8y ago
      We do precisely none of that sort of thing. Our department's workload revolves around the shifting needs of a demanding media agency, who just wants pretty looking content that's easy to manage. Everything even remotely hard they use their own media talent for. What we do is perfectly suited for Rails.
pka 8y ago
For curious onlookers: true, one can "can whip together apps so quickly", as long as: * Your code is empirically around ~1 KLOC * You won't have to maintain it in the future So yeah: if you're going to make a one-off-deploy-once-never-touch-again message board/blog app with Google Maps integration, choose Rails. Otherwise: don't bother. Making Ruby/Rails maintainable at scale is a sisyphean task: it's possible, but at an enormous cost. This is why there are several attempts to bolt a type system onto Ruby, the most recent one being developed by Stripe [0]. I've no hard numbers, but the narrative "without Ruby my startup wouldn't last long enough to worry about engineering it the right way" sounds very very suspicious to me when talking about even remotely complex problem domains. Your speed will drop to zero in about 3 weeks from the start when you have to refactor some fundamental piece of code/data structure anyway, and then better hope you at least wrote some tests. And having to write tests essentially halves your dev speed anyway, so I really am not sure where this "prototyping speed" meme comes from. [0] https://news.ycombinator.com/item?id=17217815 https://news.ycombinator.com/item?id=17217815
- octernion 8y ago
  as a counterpoint, i work at instacart, where we have rails apps (we broke our application into "macroservices" several years ago) each around ~50-200k LOC which we have maintained for 5+ years while growing exponentially (customer base) and not exponentially (engineering headcount :) i've talked to other companies that have done similar things. where are you getting any of this from?
  - pka 8y ago
    From experience. I've worked on 5+ years old Ruby projects having around 100KLOC (including tests), and adding a timestamp to an internal API that affects several other internal microservices (something that shouldn't take more than 15mins) takes a week of code reviews and writing tests. As I said, I don't claim it's impossible to make Rails maintainable. Instacart is apparently a good example of how to do that.
    - octernion 8y ago

kendallpark 8y ago

I'm completely with you. Rails is still my go-to for short one-off projects that I need to build something FAST. Hell, I even use it for quick n' dirty data analysis because working with Active Record is so easy. Rake import the data, then muck around with the Active Record models in Rails console. I honestly prefer this to working with Jupyter notebooks, unless I need graphing or something fancy out of sklearn. "Rails can't scale" is a misnomer. Heroku and Github are RoR apps (or at least started there). At scale you might start pulling in some other services and technologies.

geekjock 8y ago

Agree completely. I enjoy programming with other languages but nothing beats Rails when it comes to getting a product out the door. Last week I found out that a Rails app I built for a SAAS company many years ago is still running reliably and generating millions of dollars per year. The painpoints I often run into with Ruby/Rails are concurrency and memory use. Both are addressable though.

thomasfedb 8y ago
In the time it takes to configure Webpack I can write an app in Rails. Convention. Over. Configuration.
- deleted 8y ago
  [deleted]
- geekjock 8y ago
  Hah, so true.
armandososa 8y ago
I never learned Rails. What would you say is the best path to write a modern rails application? I learn better trough videos, btw :D
- lgregg 8y ago
  There are lots of playlists on youtube with tutorial walkthroughs. I'd go look for someone's todo app on Github and compare it to a language you know. Then write a todo app. That'll give you the initial questions you need to keep learning.
- tortilla 8y ago
  https://gorails.com/series https://gorails.com/series https://www.railstutorial.org/ https://www.railstutorial.org/

vinceguidry 8y ago

Preach that gospel truth. It's still as true now as it was 2000^H^H^H^H10 years ago. We're porting a project over to node now. God I hate it.

w8rbt 8y ago
Why move? How is node better? Really honest question, I've never used either much.
- vinceguidry 8y ago
  Beats the hell out of me. I didn't make the decision, and objected as strongly as I could.
- tim333 8y ago
  While I'm not expert, node goes faster and makes real time stuff like instant messaging easier. Like for example I had a look at hackthon starters in rails, django and node and the node one has this cool dashboard https://hackathon-starter-2018.herokuapp.com/status https://hackathon-starter-2018.herokuapp.com/status I think stuff like that is hard to do in rails. Also I was trying to do instant messaging in web2py and gave up and just wrote a service in node which was like 10 lines with express/socket.io. Pragmatically I think it may be easiest to write the main app in rails of similar and link to a separate bit of node for stuff like the above.
  - vinceguidry 8y ago
    We do precisely none of that sort of thing. Our department's workload revolves around the shifting needs of a demanding media agency, who just wants pretty looking content that's easy to manage. Everything even remotely hard they use their own media talent for. What we do is perfectly suited for Rails.

pka 8y ago

For curious onlookers: true, one can "can whip together apps so quickly", as long as: * Your code is empirically around ~1 KLOC * You won't have to maintain it in the future So yeah: if you're going to make a one-off-deploy-once-never-touch-again message board/blog app with Google Maps integration, choose Rails. Otherwise: don't bother. Making Ruby/Rails maintainable at scale is a sisyphean task: it's possible, but at an enormous cost. This is why there are several attempts to bolt a type system onto Ruby, the most recent one being developed by Stripe [0]. I've no hard numbers, but the narrative "without Ruby my startup wouldn't last long enough to worry about engineering it the right way" sounds very very suspicious to me when talking about even remotely complex problem domains. Your speed will drop to zero in about 3 weeks from the start when you have to refactor some fundamental piece of code/data structure anyway, and then better hope you at least wrote some tests. And having to write tests essentially halves your dev speed anyway, so I really am not sure where this "prototyping speed" meme comes from. [0] https://news.ycombinator.com/item?id=17217815 https://news.ycombinator.com/item?id=17217815

octernion 8y ago
as a counterpoint, i work at instacart, where we have rails apps (we broke our application into "macroservices" several years ago) each around ~50-200k LOC which we have maintained for 5+ years while growing exponentially (customer base) and not exponentially (engineering headcount :) i've talked to other companies that have done similar things. where are you getting any of this from?
- pka 8y ago
  From experience. I've worked on 5+ years old Ruby projects having around 100KLOC (including tests), and adding a timestamp to an internal API that affects several other internal microservices (something that shouldn't take more than 15mins) takes a week of code reviews and writing tests. As I said, I don't claim it's impossible to make Rails maintainable. Instacart is apparently a good example of how to do that.
  - octernion 8y ago