4 ms·

> reason for a company to choose Ruby is if they want Rails And that there, is the whole "Problem" of Ruby. Ruby is a beauty. Rails isn't. It's nice, producti

by berkes 4y ago

> reason for a company to choose Ruby is if they want Rails And that there, is the whole "Problem" of Ruby. Ruby is a beauty. Rails isn't. It's nice, productive (for certain niches) and has a long track-record. But Rails is also often the root of problems such as maintainability, long-term-productiveness, hosting (performance, scaling), and lock-in. There are far better solutions for simple CRUD-apps today than writing them all out in MVC code. And when you need complex business-logic (i.e no longer a simlpe CRUD app) the , the weird MVC (plus Concerns) that rails offers is simply not cutting it. Yet Ruby is Rails, and Rails is Ruby. So when Rails looses its niche and usefulness, Ruby uses it's niche and usefulness. And that's a shame. (I am a 12+years Ruby, former Rails, and now moving-to-Rust developer)

Felipebury 4y ago
[dead]
- devoutsalsa 4y ago
  Honestly I don’t agree. In my experience Rails easily becomes a rat’s nest of magical code that is nearly impossible to read. A bajillion imports leads to code being pulled in from who knows where.
  - ubercore 4y ago
    Last time I used Rails was years ago, but I found Rails had a huge mental load when developing. So much magic and inference, you had to carry the whole Rails mental model around with you to read some simple code. I think that's a danger in any framework, but it felt especially acute to me in Rails.
  - stiltzkin 4y ago
    That's your experience, many think it was a fresh air using Rails than using Java for webdev.
  - michaelteter 4y ago
    This is really a matter (or problem) of how people use Rails. I am very much not a fan of magic, and I prefer explicit over implicit. You cannot use the same approaches for serious, big Rails projects as you might for quick and dirty proof of concepts. And by that I mean OO, mixins, fat models, overemphasis of ORM, etc. will hurt down the road. But most of these same points are true for Django too. The better way to use Rails is for the core features, and then keep the business logic in modules in "services" (just domain specific organized modules which have little or no dependency on Rails, and are therefore super easy to write complete tests for). An organically grown Rails project that started as an MVP will predictably turn into a ball of sadness if not refactored significantly at various stages in the life of the project.
vidarh 4y ago
I've used Ruby since 2005, and I've disliked Rails pretty much from day one, and really wish the two were not so intertwined. At the same time I've used Ruby professionally almost as long while only rarely needing to touch Rails so I disagree it loses its usefulness though Rails fading from popularity certainly has an effect.
- berkes 4y ago
  I did not mean that Ruby isn't useful without Rails. But I do see the fading popularity of Rails (and therefore) Ruby to start affecting its usefulness. Less libraries, fewer bindings, abandoned libs and fewer hosting options.

by berkes 4y ago

Felipebury 4y ago

[dead]

devoutsalsa 4y ago
Honestly I don’t agree. In my experience Rails easily becomes a rat’s nest of magical code that is nearly impossible to read. A bajillion imports leads to code being pulled in from who knows where.
- ubercore 4y ago
  Last time I used Rails was years ago, but I found Rails had a huge mental load when developing. So much magic and inference, you had to carry the whole Rails mental model around with you to read some simple code. I think that's a danger in any framework, but it felt especially acute to me in Rails.
- stiltzkin 4y ago
  That's your experience, many think it was a fresh air using Rails than using Java for webdev.
- michaelteter 4y ago
  This is really a matter (or problem) of how people use Rails. I am very much not a fan of magic, and I prefer explicit over implicit. You cannot use the same approaches for serious, big Rails projects as you might for quick and dirty proof of concepts. And by that I mean OO, mixins, fat models, overemphasis of ORM, etc. will hurt down the road. But most of these same points are true for Django too. The better way to use Rails is for the core features, and then keep the business logic in modules in "services" (just domain specific organized modules which have little or no dependency on Rails, and are therefore super easy to write complete tests for). An organically grown Rails project that started as an MVP will predictably turn into a ball of sadness if not refactored significantly at various stages in the life of the project.

vidarh 4y ago

I've used Ruby since 2005, and I've disliked Rails pretty much from day one, and really wish the two were not so intertwined. At the same time I've used Ruby professionally almost as long while only rarely needing to touch Rails so I disagree it loses its usefulness though Rails fading from popularity certainly has an effect.

berkes 4y ago
I did not mean that Ruby isn't useful without Rails. But I do see the fading popularity of Rails (and therefore) Ruby to start affecting its usefulness. Less libraries, fewer bindings, abandoned libs and fewer hosting options.