21 ms·

My Love Letter to Rails (and Ruby) – Or, Why RoR Isn't Dead Yet

80 points by xeena 3y ago

kawsper 3y ago
I'm very excited for the RoR documentary that they plug in the bottom of the article, https://youtu.be/NaEG5Dz7xzM https://youtu.be/NaEG5Dz7xzM
- xeena 3y ago
  FYI, this article comes from the same people that are creating the documentary! It's Honeypot, and that's their blog!
itake 3y ago
I wish the author dove deeper into "does ruby scale" with hard numbers instead of pointing at big companies. If Shopify, Github, or Gitlab wrote their code in golang or rust, would they need less CPU and memory? Would they have less bugs? Are refactors fast? How has RoR's ever changing JS ecosystem impacted these organizations?
- AlchemistCamp 3y ago
  If they’d written their code in golang or rust, they’d have been out-competed by a competitor who iterated faster and got better product-market fit. The only reason the three companies have the opportunity to suffer from scaling challenges is that they were wildly successful.
  - pantulis 3y ago
    Or, putting it the other way around: they out-competed their competitors because they were using RoR.
    - itake 3y ago
      Do you have a source? which is bigger: WooCommerce or Shopify? Does WooCommerce use Ruby or PHP?
      - mathverse 3y ago
        Your comparison does not really make sense to me or I am perhaps missing your point. PHP and Ruby are in the same category of fast response loop and ability to develop quickly.
  - itake 3y ago
    - Uber is built on Golang. - Lyft is built in Python (which IMHO, is comparable to ruby). Who out computed who? - WooCommerce is written in PHP. - Shopify is written in Ruby. Who has more customers? hint: [0] I do not think programming languages define a company's success. [0] - https://6sense.com/tech/ecommerce-platform/woocommerce-vs-shopify https://6sense.com/tech/ecommerce-platform/woocommerce-vs-sh...
    - les_diabolique 3y ago
      Uber was initially built in Python, then migrated to Node and now Go
    - lawgimenez 3y ago
      Instagram is still on Django.
  - pixelatedgengar 3y ago
    [dead]
  - report-to-trees 3y ago
    Having worked for one of those company's, I think the productivity of Rails is overstated. Yes it's quick to get a rough demo and POC working (which is already plenty quick in many other frameworks) but once you get into the weeds of actually building and iterating the difference is not so great. I think particularly if you look at these established companies, what tech stack they are running often is just a matter of what the founders knew at the time. The business wasn't successful because they chose Rails, it was a successful business who happened to pick Rails to start with.
    - AlchemistCamp 3y ago
      Were you working for them in the early days as one of the first 10 employees or were you there after they’d already found product-market fit?
    - alberth 3y ago
      What framework would you recommend instead? Just curious.
      - randomdata 3y ago
        The one you already know is going to be the best framework for quickly iterating on an early business idea.
  - MrRolleyes 3y ago
    I don't even think that's it—as convenient it is to explain—if someone knew exactly what product they were building java would have done just fine. Realistically scaling just isn't a bottleneck for most companies at the beginning. Excepting maybe, maybe, twitter.
- mooktakim 3y ago
  Looking at big companies is a good indicator of whether "it can scale". If you want to know what scales better, thats when benchmark would be useful.
  - danmaz74 3y ago
    Looking at big companies is a bad metric if you're not a big company - or at least a rich one. Startups and in general smaller companies need to be very efficient with their developers, because they can't get many. Big companies have other issues, eg coordinating the work of thousands of developers, and choose their tooling accordingly.
    - mooktakim 3y ago
      Not that bad metric if you consider they had to start from something. The argument on "rails dont scale" is that eventually you need to rewrite it. Which isn't actually true as there are many companies that continue to use it even though they've scaled, in product usage and employees.
- manojlds 3y ago
  If Shopify, GitHub or Gitlab didn't start in RoR, would they have survived such that scale became a factor?
  - pmontra 3y ago
    We will never know. What we know is that it didn't harm them. Add Twitter to the list. They started with Rails, then switched to something else. Too many background jobs, Ruby is not ideal for that. However they became Twitter and owned that space before having to switch so Rails didn't harm them too.
- rodrigodlu 3y ago
  I worked in one product that a "simple" re-architecture from rails 3 to rails 5+(async-as-most-as-we-can) was more than enough to handle MAU into millions and simultaneous sessions in high thousands. Enough for a big exit for the founders indeed and having an edge against other players using golang, but with double the headcount than my case. We also got 98~100 lighthouse by using pure JS with sprinkles of stimulus after the initial rendering.
  - JustLurking2022 3y ago
    Thousands of simultaneous sessions isn't all that many, if you are scaling your infra to dozens of servers. Can be handled by a single server, if code is optimized.
    - rodrigodlu 3y ago
      4x16gb/2x offpeak pure ec2 deployed with codedeploy that was easily paid and profitable 2x8gb elasticsearch 1x512mb redis 1xRDS mysql 16gb low thousands/year of cloudflare enterprise half of the budget (personnel+infra) than the next competitor in the niche I worked
- BiteCode_dev 3y ago
  Doesn't matter. Whether you use Python, JS, PHP or Ruby, you will need to reach millions of users before perfs become a problem for a typical web app because the hot path are almost never coded in the language. It's not a ruby thing, it's just that servers are beast nowadays, and cheap. And devs are more expensive than ever.
  - andrewstuart 3y ago
    You seem to be saying that bad performance doesn’t matter? I disagree….. see the other comment here who talks about moving to Golang. Only today I rewrote a Python application in Golang and the result was dramatically more responsive. Performance matters. Servers cost alot of money. You want to maximize that resource.
    - vidarh 3y ago
      Servers cost, but server cost in absolute terms hit few people before you're big enough that the cost of capital to address it is far lower. And almost any money you invest in trying to minimise server costs at an early stage will end up going out the window because the features you end up needing at scale and that end up costing money to scale will tend to look entirely different from what you started with. So even if you need to switch languages down the line, I'd argue you should pick your initial tools based on what lets you iterate fastest early on, not based on what will keep your server costs down the line. Assuming of course what you pick is fast enough for whatever you want to do. Put in more concrete terms, based on the actual VC deals I've been on one or the other side of the table for, the cost of capital drops to anything from 1/2 to 1/10 per early round if you're doing well. If you do well enough that your server cost is becoming a problem, by the time you need to address it paying to address it ought to not be a problem unless your decisions were truly pathological. Most companies don't survive long enough for this to become a problem. In other words, while performance matters, the value of performance now to an early stage startup is often really low compared to speed of delivery that might improve your odds of actually surviving to a point where performance becomes a problem, and you might easily be willing to trade 2x, 5x, even 10x the total dev cost in cash to deliver faster if you can defer a significant portion of that cost a few years down the line assuming you survive that long and your cost of capital in terms of proportion of equity is a tiny proportion of what it is at the start. This is not an argument for Rails, btw. This is an argument for whichever tool is fastest for YOU and YOUR team to deliver with. If you have multiple alternatives you're equally productive with and one of them is more performant than others, of course pick that one.
- e12e 3y ago
  > How has RoR's ever changing JS ecosystem impacted these organizations? As much as I think RoRs initial love for coffee script was a mistake (although it certainly did help at a time when javascript was in a horrible, braindead place) - I'm not sure I'd like the js mess at Rails' feet. I think that the team navigated js integration as well as could be expected - and everyone was happy in version 7 when js support in browsers had advanced to the point that most of the special handling could simply be ripped out. The remaining issue IMNHO is that there's no browser support for typescript - and using ts dictates a build pipeline which would otherwise be needless complexity with modern js and js modules.
  - arrowsmith 3y ago
    > javascript was in a horrible, braindead place was?
    - e12e 3y ago
      Before modules, "let"/"const", uniform APIs cross browsers (xmlhttprequest, anyone?) - js was much, much worse. Rails dates back to before 2005 - before chrome existed, and around the time Firefox emerged from Netscape.
  - PH95VuimJjqBqy 3y ago
    coffeescript was an obvious deadend at the time it was created. The only thing that could have saved (maybe) is better tooling but the community had no interest in it (who knows why). Rust feels like this too.
    - e12e 3y ago
      If I remember correctly, the first version of coffee script was quite sane, but the second version was completely different, and IMNHO much worse? I think the initial version was a moderate enhancement on js, fixing some things like global scope etc?
- herbst 3y ago
  I was serving a big database of information to up to 1000 concurrent users on a 10$ cloud server without bigger issues. I don't think many projects get to a 1000 concurrent connections point ever. IMO when you work with it properly it's so little of an issue (especially compared to the Dev time saved) that most Rails Devs simply don't care about the 'ruby doesn't scale' talk
benjaminwootton 3y ago
Because of my career path spent almost entirely as a consultant and now working with lots of startups, I must have seen 100+ web application builds. The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD app, which covers the vast majority of business software.
- andrewstuart 3y ago
  Can someone explain in concrete terms this sense that ROR let’s people be highly productive? It’s hard for me to imagine what could be so much more productive than any number of other languages//frameworks. What does ROR actually have that the next technology doesn’t?
  - pantulis 3y ago
    A web framework can be conceived as a selection of design choices already taken for you. The choices RoR does for you are extremely successful and very simple to understand, hence the name: you are developing "on rails" and as such you build things much faster. This was very true more than a decade ago before the Node revolution adn when the alternatives where Struts or Spring MVC in Java, or Zope with Python. Fast forward to 2023, I would say that other platforms have caught up a lot, but my personal opinion is that Rails still has the edge.
  - stefcoetzee 3y ago
    Sane defaults for most (all?) aspects of the run-of-the-mill CRUD app, a.k.a. "convention over configuration". Helps focus development energy on solving the problem at hand as opposed to on bike shedding or being slowed down due to decision fatigue. AFAICT, one has to go with the conventions as far as possible. Straying off the beaten path can lead one to lose time fighting the framework.
    - herbst 3y ago
      And that is the sole reason many rails projects are still easily maintainable 10 years later. Even if they aren't your own
andrewstuart 3y ago
Are new developers choosing Ruby on Rails? I feel like there’s a real shift towards strong (er) typing. What does this mean for Rails? My main language has been Python for a long time now but I’m really coming to prefer typescript for certain applications. Does Ruby remain relevant as the industry moves towards typed languages?
- sinkwool 3y ago
  ruby is strongly typed, in that it doesn't allow you to implicitly coerce between types*: 1 + "1" will raise an error. (As opposed to weak typing in C or JS) ruby however is not statically typed. *(there are actually ways to implement certain types of coercions by defining to_ary, to_str, to_int)
- werdnapk 3y ago
  Ruby has Sorbet and RBS as options to integrate types into Ruby projects, so Ruby isn't sitting still on this front.
  - e12e 3y ago
    Having seen how well typing works with python and FastAPI - I'm afraid the current path ruby is on isn't great, unfortunately. It feels extremely bolted on - but I hope something useful and enjoyable will come out of the various typing efforts.
- veidelis 3y ago
  Isn't ruby strong and dynamic?
  - ninkendo 3y ago
    There's no type annotations (outside of experiments), and thus no way for a "compiler" step to tell you if you're passing an array to a function that expects a string or something. The "strong" typing doesn't happen until runtime, so the closest you can get to this is writing a unit test that asserts on the behavior you want (assert that this method raises an exception when I pass an array, etc.) This is what people mean by "typed languages". Ruby isn't one of them.
wkjagt 3y ago
> Well, if neither of them can differentiate between Ruby and Ruby on Rails, please bear with me; I might mix a few things up as well. This made it sound like this was going to be a pretty detailed text, but instead it didn't say much of anything about Ruby or RoR. The author could have gone a lot deeper into what he loves about both.
mortallywounded 3y ago
I built my startup in Rails. I eventually re-wrote the entire application in Go as a monolith. In my experience, Go is just as productive if not more productive due to fewer errors at runtime. My day to day life is a lot better with Go-- no more exception emails, firefighting, etc. I really liked Rails and used it for several years, but Go came when Rails was making things difficult.. Ruby's heap memory kept growing and not being released or released too slowly. My server was using 12 GB of RAM and could hardly handle 300 concurrent users. The Go version uses 25 MB of RAM and can handle many thousands of concurrent users. edit: I understand the memory/concurrency issues are not Rails' fault entirely. It's likely ActiveRecord and Ruby as a VM that caused most issues, but it's part of the Rails deal. Getting good concurrency with Rails isn't easy, and memory issues are real.
- danmaz74 3y ago
  Which framework did you use with go to be as productive as with rails?
  - lsferreira42 3y ago
    That's what i was asking myself, i've been looking for a good batteries included golang web framework
    - konart 3y ago
      You should probably stop because this is not a Go-way. And you wan't find anything with "batteries" other than https://github.com/gobuffalo/buffalo https://github.com/gobuffalo/buffalo and https://github.com/beego/beego https://github.com/beego/beego Haven't see anyone actually using them in production though.
      - infecto 3y ago
        Using github stars and some kind of proxy for popularity/usage, Beego looks to be number 2. Seems like it could be production worthy and probably is being used somewhere.
herunan 3y ago
Say what you want about RoR, but it’s certainly getting some of the most exciting updates as a framework. My favourite one is this https://hotwired.dev https://hotwired.dev. DHH clearly wants to move away as much as possible from JS, and I love that.
- mortallywounded 3y ago
  Except Rails 6, which was a huge let down and JS-ridden.
- anonyfox 3y ago
  Or, you could use Elixir/Phoenix/LiveView, and have a javascript-free interactive fullstack framework that can do everything rails can do, except it is faster, scales _much_ better and maintenance is easier. For now Rails has more gems than Phoenix for a quickstart within the first days, but this quickly turns around when stuff gets complicated and you need to "optimize" ruby code instead of shipping more features, or when you want realtime that doesn't suck. It's like where DHH wants to end up with Rails, but available here and now, with a better technical foundation.
  - realusername 3y ago
    I'd say there's pro and cons to each side. Rails is definitely easier to recruit for which is not negligible and while I really like Ecto changesets concept, ActiveRecord has a better mapping to complex queries. On the plus side for LiveView though, to me it's the most productive web app technology in the world and there's just no match to it. It makes the hard things easy.
  - bgentry 3y ago
    Unfortunately the Elixir ecosystem is a harsh dose of reality: only a handful of good 3rd party libraries that are well maintained outside of Phoenix, Ecto, and Oban. I say this as somebody who’s spent several years full time in Elixir on and off since 2017, including in my current role. A strong Elixir ecosystem has unfortunately never materialized.
wmoxam 3y ago
Punk rock died when the first kid said "Punk's not dead, punk's not dead" You know Louisville is death, we've got to up and move Because the dead do not improve.
deleted 3y ago
[deleted]
pjmlp 3y ago
> Another company that you might have heard of, and that is still using Ruby On Rails, is Shopify! Indeed, and if Ruby did scale for them, they wouldn't be so invested into integrating JIT compiler infrastructure into CRuby. Likewise there wouldn't exist so much research in TruffleRuby and JRuby. Which is great from performance of dynamic languages point of view, and compiler nerds, but lets not pretend it doesn't matter.
mooktakim 3y ago
I'll add my 2 pence for why Rails is still suitable for startups. Rails is still the best framework for building web forms quickly. Web apps are mostly web forms. It helps you get going with everything ready for you (validations, style, views, etc). If you follow the conventions, you get a significant boost in productivity. I see people using other "modern" frameworks where they build api+validation, frontend+validation etc it is just a waste of time. Build the product, get it out there.
Alifatisk 3y ago
Can we just stop with saying “Ruby / Rails is dead”? I’ve heard this for years yet they both keep growing and the community is nowhere near dead. It’s an endless argument.

80 points by xeena 3y ago

I'm very excited for the RoR documentary that they plug in the bottom of the article, https://youtu.be/NaEG5Dz7xzM https://youtu.be/NaEG5Dz7xzM

xeena 3y ago
FYI, this article comes from the same people that are creating the documentary! It's Honeypot, and that's their blog!

itake 3y ago

I wish the author dove deeper into "does ruby scale" with hard numbers instead of pointing at big companies. If Shopify, Github, or Gitlab wrote their code in golang or rust, would they need less CPU and memory? Would they have less bugs? Are refactors fast? How has RoR's ever changing JS ecosystem impacted these organizations?

AlchemistCamp 3y ago
If they’d written their code in golang or rust, they’d have been out-competed by a competitor who iterated faster and got better product-market fit. The only reason the three companies have the opportunity to suffer from scaling challenges is that they were wildly successful.
- pantulis 3y ago
  Or, putting it the other way around: they out-competed their competitors because they were using RoR.
  - itake 3y ago
    Do you have a source? which is bigger: WooCommerce or Shopify? Does WooCommerce use Ruby or PHP?
    - mathverse 3y ago
      Your comparison does not really make sense to me or I am perhaps missing your point. PHP and Ruby are in the same category of fast response loop and ability to develop quickly.
- itake 3y ago
  - Uber is built on Golang. - Lyft is built in Python (which IMHO, is comparable to ruby). Who out computed who? - WooCommerce is written in PHP. - Shopify is written in Ruby. Who has more customers? hint: [0] I do not think programming languages define a company's success. [0] - https://6sense.com/tech/ecommerce-platform/woocommerce-vs-shopify https://6sense.com/tech/ecommerce-platform/woocommerce-vs-sh...
  - les_diabolique 3y ago
    Uber was initially built in Python, then migrated to Node and now Go
  - lawgimenez 3y ago
    Instagram is still on Django.
- pixelatedgengar 3y ago
  [dead]
- report-to-trees 3y ago
  Having worked for one of those company's, I think the productivity of Rails is overstated. Yes it's quick to get a rough demo and POC working (which is already plenty quick in many other frameworks) but once you get into the weeds of actually building and iterating the difference is not so great. I think particularly if you look at these established companies, what tech stack they are running often is just a matter of what the founders knew at the time. The business wasn't successful because they chose Rails, it was a successful business who happened to pick Rails to start with.
  - AlchemistCamp 3y ago
    Were you working for them in the early days as one of the first 10 employees or were you there after they’d already found product-market fit?
  - alberth 3y ago
    What framework would you recommend instead? Just curious.
    - randomdata 3y ago
      The one you already know is going to be the best framework for quickly iterating on an early business idea.
- MrRolleyes 3y ago
  I don't even think that's it—as convenient it is to explain—if someone knew exactly what product they were building java would have done just fine. Realistically scaling just isn't a bottleneck for most companies at the beginning. Excepting maybe, maybe, twitter.
mooktakim 3y ago
Looking at big companies is a good indicator of whether "it can scale". If you want to know what scales better, thats when benchmark would be useful.
- danmaz74 3y ago
  Looking at big companies is a bad metric if you're not a big company - or at least a rich one. Startups and in general smaller companies need to be very efficient with their developers, because they can't get many. Big companies have other issues, eg coordinating the work of thousands of developers, and choose their tooling accordingly.
  - mooktakim 3y ago
    Not that bad metric if you consider they had to start from something. The argument on "rails dont scale" is that eventually you need to rewrite it. Which isn't actually true as there are many companies that continue to use it even though they've scaled, in product usage and employees.
manojlds 3y ago
If Shopify, GitHub or Gitlab didn't start in RoR, would they have survived such that scale became a factor?
- pmontra 3y ago
  We will never know. What we know is that it didn't harm them. Add Twitter to the list. They started with Rails, then switched to something else. Too many background jobs, Ruby is not ideal for that. However they became Twitter and owned that space before having to switch so Rails didn't harm them too.
rodrigodlu 3y ago
I worked in one product that a "simple" re-architecture from rails 3 to rails 5+(async-as-most-as-we-can) was more than enough to handle MAU into millions and simultaneous sessions in high thousands. Enough for a big exit for the founders indeed and having an edge against other players using golang, but with double the headcount than my case. We also got 98~100 lighthouse by using pure JS with sprinkles of stimulus after the initial rendering.
- JustLurking2022 3y ago
  Thousands of simultaneous sessions isn't all that many, if you are scaling your infra to dozens of servers. Can be handled by a single server, if code is optimized.
  - rodrigodlu 3y ago
    4x16gb/2x offpeak pure ec2 deployed with codedeploy that was easily paid and profitable 2x8gb elasticsearch 1x512mb redis 1xRDS mysql 16gb low thousands/year of cloudflare enterprise half of the budget (personnel+infra) than the next competitor in the niche I worked
BiteCode_dev 3y ago
Doesn't matter. Whether you use Python, JS, PHP or Ruby, you will need to reach millions of users before perfs become a problem for a typical web app because the hot path are almost never coded in the language. It's not a ruby thing, it's just that servers are beast nowadays, and cheap. And devs are more expensive than ever.
- andrewstuart 3y ago
  You seem to be saying that bad performance doesn’t matter? I disagree….. see the other comment here who talks about moving to Golang. Only today I rewrote a Python application in Golang and the result was dramatically more responsive. Performance matters. Servers cost alot of money. You want to maximize that resource.
  - vidarh 3y ago
    Servers cost, but server cost in absolute terms hit few people before you're big enough that the cost of capital to address it is far lower. And almost any money you invest in trying to minimise server costs at an early stage will end up going out the window because the features you end up needing at scale and that end up costing money to scale will tend to look entirely different from what you started with. So even if you need to switch languages down the line, I'd argue you should pick your initial tools based on what lets you iterate fastest early on, not based on what will keep your server costs down the line. Assuming of course what you pick is fast enough for whatever you want to do. Put in more concrete terms, based on the actual VC deals I've been on one or the other side of the table for, the cost of capital drops to anything from 1/2 to 1/10 per early round if you're doing well. If you do well enough that your server cost is becoming a problem, by the time you need to address it paying to address it ought to not be a problem unless your decisions were truly pathological. Most companies don't survive long enough for this to become a problem. In other words, while performance matters, the value of performance now to an early stage startup is often really low compared to speed of delivery that might improve your odds of actually surviving to a point where performance becomes a problem, and you might easily be willing to trade 2x, 5x, even 10x the total dev cost in cash to deliver faster if you can defer a significant portion of that cost a few years down the line assuming you survive that long and your cost of capital in terms of proportion of equity is a tiny proportion of what it is at the start. This is not an argument for Rails, btw. This is an argument for whichever tool is fastest for YOU and YOUR team to deliver with. If you have multiple alternatives you're equally productive with and one of them is more performant than others, of course pick that one.
e12e 3y ago
> How has RoR's ever changing JS ecosystem impacted these organizations? As much as I think RoRs initial love for coffee script was a mistake (although it certainly did help at a time when javascript was in a horrible, braindead place) - I'm not sure I'd like the js mess at Rails' feet. I think that the team navigated js integration as well as could be expected - and everyone was happy in version 7 when js support in browsers had advanced to the point that most of the special handling could simply be ripped out. The remaining issue IMNHO is that there's no browser support for typescript - and using ts dictates a build pipeline which would otherwise be needless complexity with modern js and js modules.
- arrowsmith 3y ago
  > javascript was in a horrible, braindead place was?
  - e12e 3y ago
    Before modules, "let"/"const", uniform APIs cross browsers (xmlhttprequest, anyone?) - js was much, much worse. Rails dates back to before 2005 - before chrome existed, and around the time Firefox emerged from Netscape.
- PH95VuimJjqBqy 3y ago
  coffeescript was an obvious deadend at the time it was created. The only thing that could have saved (maybe) is better tooling but the community had no interest in it (who knows why). Rust feels like this too.
  - e12e 3y ago
    If I remember correctly, the first version of coffee script was quite sane, but the second version was completely different, and IMNHO much worse? I think the initial version was a moderate enhancement on js, fixing some things like global scope etc?
herbst 3y ago
I was serving a big database of information to up to 1000 concurrent users on a 10$ cloud server without bigger issues. I don't think many projects get to a 1000 concurrent connections point ever. IMO when you work with it properly it's so little of an issue (especially compared to the Dev time saved) that most Rails Devs simply don't care about the 'ruby doesn't scale' talk

benjaminwootton 3y ago

Because of my career path spent almost entirely as a consultant and now working with lots of startups, I must have seen 100+ web application builds. The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD app, which covers the vast majority of business software.

andrewstuart 3y ago
Can someone explain in concrete terms this sense that ROR let’s people be highly productive? It’s hard for me to imagine what could be so much more productive than any number of other languages//frameworks. What does ROR actually have that the next technology doesn’t?
- pantulis 3y ago
  A web framework can be conceived as a selection of design choices already taken for you. The choices RoR does for you are extremely successful and very simple to understand, hence the name: you are developing "on rails" and as such you build things much faster. This was very true more than a decade ago before the Node revolution adn when the alternatives where Struts or Spring MVC in Java, or Zope with Python. Fast forward to 2023, I would say that other platforms have caught up a lot, but my personal opinion is that Rails still has the edge.
- stefcoetzee 3y ago
  Sane defaults for most (all?) aspects of the run-of-the-mill CRUD app, a.k.a. "convention over configuration". Helps focus development energy on solving the problem at hand as opposed to on bike shedding or being slowed down due to decision fatigue. AFAICT, one has to go with the conventions as far as possible. Straying off the beaten path can lead one to lose time fighting the framework.
  - herbst 3y ago
    And that is the sole reason many rails projects are still easily maintainable 10 years later. Even if they aren't your own

andrewstuart 3y ago

Are new developers choosing Ruby on Rails? I feel like there’s a real shift towards strong (er) typing. What does this mean for Rails? My main language has been Python for a long time now but I’m really coming to prefer typescript for certain applications. Does Ruby remain relevant as the industry moves towards typed languages?

sinkwool 3y ago
ruby is strongly typed, in that it doesn't allow you to implicitly coerce between types*: 1 + "1" will raise an error. (As opposed to weak typing in C or JS) ruby however is not statically typed. *(there are actually ways to implement certain types of coercions by defining to_ary, to_str, to_int)
werdnapk 3y ago
Ruby has Sorbet and RBS as options to integrate types into Ruby projects, so Ruby isn't sitting still on this front.
- e12e 3y ago
  Having seen how well typing works with python and FastAPI - I'm afraid the current path ruby is on isn't great, unfortunately. It feels extremely bolted on - but I hope something useful and enjoyable will come out of the various typing efforts.
veidelis 3y ago
Isn't ruby strong and dynamic?
- ninkendo 3y ago
  There's no type annotations (outside of experiments), and thus no way for a "compiler" step to tell you if you're passing an array to a function that expects a string or something. The "strong" typing doesn't happen until runtime, so the closest you can get to this is writing a unit test that asserts on the behavior you want (assert that this method raises an exception when I pass an array, etc.) This is what people mean by "typed languages". Ruby isn't one of them.

wkjagt 3y ago

> Well, if neither of them can differentiate between Ruby and Ruby on Rails, please bear with me; I might mix a few things up as well. This made it sound like this was going to be a pretty detailed text, but instead it didn't say much of anything about Ruby or RoR. The author could have gone a lot deeper into what he loves about both.

mortallywounded 3y ago

I built my startup in Rails. I eventually re-wrote the entire application in Go as a monolith. In my experience, Go is just as productive if not more productive due to fewer errors at runtime. My day to day life is a lot better with Go-- no more exception emails, firefighting, etc. I really liked Rails and used it for several years, but Go came when Rails was making things difficult.. Ruby's heap memory kept growing and not being released or released too slowly. My server was using 12 GB of RAM and could hardly handle 300 concurrent users. The Go version uses 25 MB of RAM and can handle many thousands of concurrent users. edit: I understand the memory/concurrency issues are not Rails' fault entirely. It's likely ActiveRecord and Ruby as a VM that caused most issues, but it's part of the Rails deal. Getting good concurrency with Rails isn't easy, and memory issues are real.

danmaz74 3y ago
Which framework did you use with go to be as productive as with rails?
- lsferreira42 3y ago
  That's what i was asking myself, i've been looking for a good batteries included golang web framework
  - konart 3y ago
    You should probably stop because this is not a Go-way. And you wan't find anything with "batteries" other than https://github.com/gobuffalo/buffalo https://github.com/gobuffalo/buffalo and https://github.com/beego/beego https://github.com/beego/beego Haven't see anyone actually using them in production though.
    - infecto 3y ago
      Using github stars and some kind of proxy for popularity/usage, Beego looks to be number 2. Seems like it could be production worthy and probably is being used somewhere.

herunan 3y ago

Say what you want about RoR, but it’s certainly getting some of the most exciting updates as a framework. My favourite one is this https://hotwired.dev https://hotwired.dev. DHH clearly wants to move away as much as possible from JS, and I love that.

mortallywounded 3y ago
Except Rails 6, which was a huge let down and JS-ridden.
anonyfox 3y ago
Or, you could use Elixir/Phoenix/LiveView, and have a javascript-free interactive fullstack framework that can do everything rails can do, except it is faster, scales _much_ better and maintenance is easier. For now Rails has more gems than Phoenix for a quickstart within the first days, but this quickly turns around when stuff gets complicated and you need to "optimize" ruby code instead of shipping more features, or when you want realtime that doesn't suck. It's like where DHH wants to end up with Rails, but available here and now, with a better technical foundation.
- realusername 3y ago
  I'd say there's pro and cons to each side. Rails is definitely easier to recruit for which is not negligible and while I really like Ecto changesets concept, ActiveRecord has a better mapping to complex queries. On the plus side for LiveView though, to me it's the most productive web app technology in the world and there's just no match to it. It makes the hard things easy.
- bgentry 3y ago
  Unfortunately the Elixir ecosystem is a harsh dose of reality: only a handful of good 3rd party libraries that are well maintained outside of Phoenix, Ecto, and Oban. I say this as somebody who’s spent several years full time in Elixir on and off since 2017, including in my current role. A strong Elixir ecosystem has unfortunately never materialized.

wmoxam 3y ago

Punk rock died when the first kid said "Punk's not dead, punk's not dead" You know Louisville is death, we've got to up and move Because the dead do not improve.

deleted 3y ago

[deleted]

pjmlp 3y ago

> Another company that you might have heard of, and that is still using Ruby On Rails, is Shopify! Indeed, and if Ruby did scale for them, they wouldn't be so invested into integrating JIT compiler infrastructure into CRuby. Likewise there wouldn't exist so much research in TruffleRuby and JRuby. Which is great from performance of dynamic languages point of view, and compiler nerds, but lets not pretend it doesn't matter.

mooktakim 3y ago

I'll add my 2 pence for why Rails is still suitable for startups. Rails is still the best framework for building web forms quickly. Web apps are mostly web forms. It helps you get going with everything ready for you (validations, style, views, etc). If you follow the conventions, you get a significant boost in productivity. I see people using other "modern" frameworks where they build api+validation, frontend+validation etc it is just a waste of time. Build the product, get it out there.

Alifatisk 3y ago

Can we just stop with saying “Ruby / Rails is dead”? I’ve heard this for years yet they both keep growing and the community is nowhere near dead. It’s an endless argument.