4 ms·
I'm more and more convinced Rails has caused much of the demise of Ruby. As well as make it big in the first place. I love Ruby. And with a decade of fulltime
by berkes 6y ago
I'm more and more convinced Rails has caused much of the demise of Ruby. As well as make it big in the first place.
I love Ruby. And with a decade of fulltime Rails development, know and like both Rails and Ruby very well. But 'sharp knives' have caused just too many rails projects to become mudballs over time. This makes teams or companies 'move to language X'. When it really was (their use of) Rails causing the mudballing. Let alone Ruby.
'Performance' is often cited, but I'm certain hardly anyone ever had severe performance issues in practice with Ruby. Maybe with Rails, probably activerecord and quite likely their own implementation thereof. But hardly Ruby the Language
- joelbluminator 6y agoIf those teams were all moving to Java / C# I would agree, but they mostly moved to Node. They're gonna run into very similar problems.
- nl 6y ago> They're gonna run into very similar problems. Once they get the build fixed. Again.
- berkes 6y ago1. Start writing software -greenfield-. "Wow this framework is really neat". 2. Grow it over years. Maintain it. "This language/framework/architecture really sucks" 3. We should rewrite it in Rust. Goto 1. The real problem is that architecture is hard. Maintainance is difficult, scope creap a thing and accumulating technical debt will kill you eventually. In Rails, getting a Proof of Concept "blog" out there, is done in hours. But all the "shortcuts" like "throw in Devise for auth" will get back to you in future, turning "hours of rapid development" into "months of stagnation". Getting a basis that will survive pivots, quick market changes, scope creep and allow to tackle technical debt when time is right, takes years of experience with not just Rails, but with "software architecture" in general.
- joelbluminator 6y agoYes, no argument there. Growing projects is plain hard, no matter what language/framework you use. People talk so much about stack choices as if that's where the problem/solution lies. It's more about building effective teams, respecting seniority, not churning out your employees, having good product people (e.g knowing what to build). That's way more important to most businesses than the endless chat about graphql/react/rails/node/php. But as techies, we tend to view every problem as a technical problem that can be solved by throwing more graphql at it...