9 ms·

Counterpoint: I find it suspicious that so many people on this forum take the opportunity to bag on Ruby on Rails every time it comes up. It's almost like they

Counterpoint: I find it suspicious that so many people on this forum take the opportunity to bag on Ruby on Rails every time it comes up. It's almost like they hate the fact that it is, in fact, a perfectly valid choice of language and platform, and they're trying to justify the self-flagellation required to use Java for web apps. I've been around the block a couple of times now, and done projects in PHP, ASP, .NET, and Java. But I've been using Rails whenever possible to make LOB CRUD apps for almost 15 years now, and there's nothing that can even hold a candle to it for productivity. Still. Things that can take just a line or two in Rails often take HUNDREDS in Java & <insert popular JS framework>, and be a nightmare to keep square with strong typing that's so popular with Typescript now. So go ahead, cast aspersions on Rails. I'll be over here, happily cranking out features as fast as my users request them, while the corporate IT departments at my Fortune 250 take 6 months to even put a request on their schedule. EDIT: As an example, I once rewrote a web app for a department. The original was all Java/Struts. It took a team of outsourced developers 2.5 years to write. It took me 4 months to rewrite it in Rails (having no access to the code), and mine did the main operation twice as fast, which meant that you could do it online, instead of having to wait for a backgrounded process to finish and send email.

sanderjd 4y ago
I totally agree that Rails is great at LOB CRUD apps. Apps like that don't get very large or complex, mostly do fairly simple transformations from a database, mostly have fairly simple validation and business logic, and can use a fairly small set of user interface components. I think the primary competitor to Rails in this space should be low/no-code frameworks that can do those things without requiring much or any code. I agree Java/Struts is worse for this, and that there is a huuuge amount of "dark matter" of apps like this out there to be written. But! Gitlab is not a LOB CRUD app. And I think a lot of people here have been burned by ending up working on bigger more complicated projects that started in Rails because it was convenient and then persisted with it because it never became clear that there was a positive ROI in migrating to something different. Some people who have had that experience tend to be skeptical of projects getting started with Rails, because it feels like starting to dig a hole that they know may be difficult to climb out of. But! You never really know whether some application is going to remain small and simple, or whether it is going to grow and become more complex. So everyone is just guessing based on very limited information about the future. My two cents is that I like services. Not micro-services, larger services with well-considered boundaries, but which are not a single monolith. If that structure or philosophy is in place, I worry a lot less about implementing the individual services with Rails, because the future path is much more clear. If a particular service grows too big for Rails' britches, it can be replaced with a different implementation, without reimplementing everything. I think services are an extremely useful hedge against the risk of path dependency leading to implementations that are not working well, but are very hard to fix.
azth 4y ago
Do you think it's fair to compare something written in Struts to a modern Java framework like Spring Boot or Quarkus? I'd bet that it would have taken a similar time to rewrite in one of those frameworks as it took to do your rewrite.
deleted 4y ago
[deleted]
corrral 4y ago
Rails is incredibly productive for 1-3 people to write something from scratch. As soon as everyone committing code isn't synced up with the same knowledge and solution styles, it goes to hell fast. It's bad at surviving team transitions intact, bad for onboarding once the project is past its earliest days, et c.
- TheRealDunkirk 4y ago
  Now, see, I would argue EXACTLY the opposite. I worked (briefly) for a Rails "house." I was assigned to a project that someone who had left the company had been working on, and told to add payment processing. I started working through the idea, putting stuff in the places it should go throughout the stack. About halfway through the process, I finally noticed some code that looked almost exactly like my function, "below the fold" of the text editor window. Then I started noticing that I had duplicated the little snippets of code needed in many files. They looked almost the same, and they were in all the same files. In fact, I realized that ALL the code to enable the processing was already done, and all I had to do was expose it on the page. To me, it was a crystal clear example that each bit of code needed to do something in Rails has a "correct" spot, and it's hard for me to believe that anyone with a nominal understanding of Rails wouldn't grok the organization, and naturally do things "the Rails way."
  - corrral 4y ago
    I've worked on four or five Rails codebases. All did things "the Rails way". All were quite different, and none were plainly incorrect.
  - nine_k 4y ago
    It's interesting though how you had to re-implement a large part before you were able to discover the existing code that does what you had needed. Discoverability problems are not specific to Rails, but may have something to do with convention over configuration, though.
  - jasonwatkinspdx 4y ago
    My experience doing agency work with Rails has been similar. Love or hate the opinionated nature of it, switching projects was fast because generally you'd just know where any given thing's home would be.
swman 4y ago
What is “LOB” crud?
- LesZedCB 4y ago
  "Line of Business"
  - edwinbalani 4y ago
    And CRUD -> create, read, update, delete. By "LOB CRUD" GP means those fairly generic apps that are mainly a front-end to some database, with a bit of business logic or integrations tacked on. They're not the apps making money for a business, they're just helping it tick along and do the things that actually bring in revenue.
- acoard 4y ago
  As LesZedCB said, LOB is "Line of Business". In practice, this is where your business-logic resides. edit: CRUD means Create-Read-Update-Delete. It's a basic programmer term for a simple application, or those simple parts of it at least. Even something big like Wikipedia, at it's core is a CRUD site. Most things are, with business logic sprinkled in; but some things aren't CRUD at all (eg a video game). For example, if you're a car dealership your LOB CRUD API would handle stuff like submitting new cars, or staffs, or associating a sale of a specific car with a specific salesman or whatever other biz logic you have. This could be in contrast with, say, your Document Storage CRUD API which handles integrations with your document storage (eg storing things on a SharePoint, or Ceph, or S3, etc). LOB has no inherent value with regards to microservice vs. monolith, it's simply another way to refer to the business specific logic. The term LOB is common across business as a whole, whereas "business logic" is generally a phrase used by programmers about programs. https://en.wikipedia.org/wiki/Line_of_business https://en.wikipedia.org/wiki/Line_of_business
cultofmetatron 4y ago
checkout elixir/phoenix. Its almost as productive as rails while having performance within the same realm as go. pros: imutable data types. ruby like syntax. similar codebase organization. super fast. more modular than rails. the websocket system is way faster to develop in and deploy. cons: no runtime metaprogramming but you do have a sophisticated macro system. not as many drop in libraries. not as many jobs for it yet.
- your_username 4y ago
- zumu 4y ago
  Unfortunately Elixir just doesn't have the network effects of Ruby. Ruby support (libraries, SDKs, first class integrations) and popularity (ability to hire effective devs) is just an order of magnitude or more higher than Elixir. I say this as a massive Elixir and functional programming fanboy.
  - cultofmetatron 4y ago
    network effects take time to develop. unfortunately it doesn't have a major company or foundation pushing it forward aggressively. That said, I'm hopeful. its defiantly the BEST platform for building anything websocket based. the killer apps for picking elixir will be anything requiring soft realtime. case in point, I built my startup in elixir. completely agree on the difficulty in hiring but its not hard to teach. It was harder for me to find people who knew sql well. Unlike active record, ecto embraces sql so you have to know sql to use it. anyways, its time will come. more and more companies are adopting it from discord to supabase to <cringe> trump media group.</cringe>
    - freedomben 4y ago
      Yeah I've found that many people have ruby/rails experience, and they can usually pick up elixir pretty well since so much will be familiar.
leke 4y ago
Interesting! I'm wondering since you have programmed in PHP, what has been your experience with that? I assume you would be using web frameworks like Laravel or Symfony or equivalent. Does Rails still beat those like it did Java and <Foo>JS?
- freedomben 4y ago
  Not OP but in similar situation. Just my opinion. Laravel is pretty amazing, and with modern PHP the languages are pretty comparable. PHP still has a reputation problem though, and hiring has been tough because so many PHP devs haven't used Laravel (or Rails) so they have a bit of a steep learning curve. The tooling for ruby/rails is also still a bit better than laravel, but that may not be true forever.
jcelerier 4y ago
> It's almost like they hate the fact that it is, in fact, a perfectly valid choice of language and platform, why is gitlab is so surreally SLOW then ? even on simple projects on powerful hosted instances it's barely tolerable
- fy20 4y ago
  That's like asking why there is a car doing 60mph on the highway when everyone else is doing 75mph. If they are driving a VW, would you assume that means VW makes slow cars?
  - jcelerier 4y ago
    > That's like asking why there is a car doing 60mph on the highway when everyone else is doing 75mph. thankfully in my country being too slow on the highway (lower limit being 80 km/h apparently) will net you a fine. It's people's right to drive whatever van they fancy... as long as this does not have any too much negative influence on society.
kaba0 4y ago
> The original was all Java/Struts Okay, come on! That is fking Struts, it is hardly a fair comparison. Though otherwise I agree that Rails is a great choice for almost every CRUD app, like we really should stop overstressing it. Just use whatever one we are comfortable with and has enough internal knowledge on and with modern computers it will be plenty fast enough.
- TheRealDunkirk 4y ago
  This whole thing happened about 4 years ago now, and the original application was written several years before that, before the rise of React and Angular, which have BECOME popular (IMNTBHO) because they try to address the gaping hole which is the frontend of using Java for web apps. Around that same timeframe, I tried using JHipster, which sort of attempts to do for Java everything that a Rails app stack does for Ruby. It took 45 minutes for my top-of-the-line Dell laptop/workstation to bootstrap it, and it was... unapproachable.
  - kaba0 4y ago
    Why did you use Struts 4 years ago? That framework died at least a decade ago. But don’t get me wrong, I see where you are coming from, I’m just saying that your experience may not have been up-to-date even then, let alone now. In practice, with spring boot, quarkus and the like developing a backend app is plenty productive in java.
    - TheRealDunkirk 4y ago
      Ay yi yi. Maybe go back and reread what I wrote. I didn't use Struts, and the original app was written at a time when that was an accepted "meta." I've used Spring Boot. We'll have to "agree to disagree" that it's "productive." All these things that people are stacking on top of Java are just trying to implement concepts and features that Rails has had for 15 years, and they're still nowhere near as "productive."

sanderjd 4y ago

I totally agree that Rails is great at LOB CRUD apps. Apps like that don't get very large or complex, mostly do fairly simple transformations from a database, mostly have fairly simple validation and business logic, and can use a fairly small set of user interface components. I think the primary competitor to Rails in this space should be low/no-code frameworks that can do those things without requiring much or any code. I agree Java/Struts is worse for this, and that there is a huuuge amount of "dark matter" of apps like this out there to be written. But! Gitlab is not a LOB CRUD app. And I think a lot of people here have been burned by ending up working on bigger more complicated projects that started in Rails because it was convenient and then persisted with it because it never became clear that there was a positive ROI in migrating to something different. Some people who have had that experience tend to be skeptical of projects getting started with Rails, because it feels like starting to dig a hole that they know may be difficult to climb out of. But! You never really know whether some application is going to remain small and simple, or whether it is going to grow and become more complex. So everyone is just guessing based on very limited information about the future. My two cents is that I like services. Not micro-services, larger services with well-considered boundaries, but which are not a single monolith. If that structure or philosophy is in place, I worry a lot less about implementing the individual services with Rails, because the future path is much more clear. If a particular service grows too big for Rails' britches, it can be replaced with a different implementation, without reimplementing everything. I think services are an extremely useful hedge against the risk of path dependency leading to implementations that are not working well, but are very hard to fix.

azth 4y ago

Do you think it's fair to compare something written in Struts to a modern Java framework like Spring Boot or Quarkus? I'd bet that it would have taken a similar time to rewrite in one of those frameworks as it took to do your rewrite.

deleted 4y ago

[deleted]

corrral 4y ago

Rails is incredibly productive for 1-3 people to write something from scratch. As soon as everyone committing code isn't synced up with the same knowledge and solution styles, it goes to hell fast. It's bad at surviving team transitions intact, bad for onboarding once the project is past its earliest days, et c.

TheRealDunkirk 4y ago
Now, see, I would argue EXACTLY the opposite. I worked (briefly) for a Rails "house." I was assigned to a project that someone who had left the company had been working on, and told to add payment processing. I started working through the idea, putting stuff in the places it should go throughout the stack. About halfway through the process, I finally noticed some code that looked almost exactly like my function, "below the fold" of the text editor window. Then I started noticing that I had duplicated the little snippets of code needed in many files. They looked almost the same, and they were in all the same files. In fact, I realized that ALL the code to enable the processing was already done, and all I had to do was expose it on the page. To me, it was a crystal clear example that each bit of code needed to do something in Rails has a "correct" spot, and it's hard for me to believe that anyone with a nominal understanding of Rails wouldn't grok the organization, and naturally do things "the Rails way."
- corrral 4y ago
  I've worked on four or five Rails codebases. All did things "the Rails way". All were quite different, and none were plainly incorrect.
- nine_k 4y ago
  It's interesting though how you had to re-implement a large part before you were able to discover the existing code that does what you had needed. Discoverability problems are not specific to Rails, but may have something to do with convention over configuration, though.
- jasonwatkinspdx 4y ago
  My experience doing agency work with Rails has been similar. Love or hate the opinionated nature of it, switching projects was fast because generally you'd just know where any given thing's home would be.

swman 4y ago

What is “LOB” crud?

LesZedCB 4y ago
"Line of Business"
- edwinbalani 4y ago
  And CRUD -> create, read, update, delete. By "LOB CRUD" GP means those fairly generic apps that are mainly a front-end to some database, with a bit of business logic or integrations tacked on. They're not the apps making money for a business, they're just helping it tick along and do the things that actually bring in revenue.
acoard 4y ago
As LesZedCB said, LOB is "Line of Business". In practice, this is where your business-logic resides. edit: CRUD means Create-Read-Update-Delete. It's a basic programmer term for a simple application, or those simple parts of it at least. Even something big like Wikipedia, at it's core is a CRUD site. Most things are, with business logic sprinkled in; but some things aren't CRUD at all (eg a video game). For example, if you're a car dealership your LOB CRUD API would handle stuff like submitting new cars, or staffs, or associating a sale of a specific car with a specific salesman or whatever other biz logic you have. This could be in contrast with, say, your Document Storage CRUD API which handles integrations with your document storage (eg storing things on a SharePoint, or Ceph, or S3, etc). LOB has no inherent value with regards to microservice vs. monolith, it's simply another way to refer to the business specific logic. The term LOB is common across business as a whole, whereas "business logic" is generally a phrase used by programmers about programs. https://en.wikipedia.org/wiki/Line_of_business https://en.wikipedia.org/wiki/Line_of_business

cultofmetatron 4y ago

checkout elixir/phoenix. Its almost as productive as rails while having performance within the same realm as go. pros: imutable data types. ruby like syntax. similar codebase organization. super fast. more modular than rails. the websocket system is way faster to develop in and deploy. cons: no runtime metaprogramming but you do have a sophisticated macro system. not as many drop in libraries. not as many jobs for it yet.

your_username 4y ago
zumu 4y ago
Unfortunately Elixir just doesn't have the network effects of Ruby. Ruby support (libraries, SDKs, first class integrations) and popularity (ability to hire effective devs) is just an order of magnitude or more higher than Elixir. I say this as a massive Elixir and functional programming fanboy.
- cultofmetatron 4y ago
  network effects take time to develop. unfortunately it doesn't have a major company or foundation pushing it forward aggressively. That said, I'm hopeful. its defiantly the BEST platform for building anything websocket based. the killer apps for picking elixir will be anything requiring soft realtime. case in point, I built my startup in elixir. completely agree on the difficulty in hiring but its not hard to teach. It was harder for me to find people who knew sql well. Unlike active record, ecto embraces sql so you have to know sql to use it. anyways, its time will come. more and more companies are adopting it from discord to supabase to <cringe> trump media group.</cringe>
  - freedomben 4y ago
    Yeah I've found that many people have ruby/rails experience, and they can usually pick up elixir pretty well since so much will be familiar.

leke 4y ago

Interesting! I'm wondering since you have programmed in PHP, what has been your experience with that? I assume you would be using web frameworks like Laravel or Symfony or equivalent. Does Rails still beat those like it did Java and <Foo>JS?

freedomben 4y ago
Not OP but in similar situation. Just my opinion. Laravel is pretty amazing, and with modern PHP the languages are pretty comparable. PHP still has a reputation problem though, and hiring has been tough because so many PHP devs haven't used Laravel (or Rails) so they have a bit of a steep learning curve. The tooling for ruby/rails is also still a bit better than laravel, but that may not be true forever.

jcelerier 4y ago

> It's almost like they hate the fact that it is, in fact, a perfectly valid choice of language and platform, why is gitlab is so surreally SLOW then ? even on simple projects on powerful hosted instances it's barely tolerable

fy20 4y ago
That's like asking why there is a car doing 60mph on the highway when everyone else is doing 75mph. If they are driving a VW, would you assume that means VW makes slow cars?
- jcelerier 4y ago
  > That's like asking why there is a car doing 60mph on the highway when everyone else is doing 75mph. thankfully in my country being too slow on the highway (lower limit being 80 km/h apparently) will net you a fine. It's people's right to drive whatever van they fancy... as long as this does not have any too much negative influence on society.

kaba0 4y ago

> The original was all Java/Struts Okay, come on! That is fking Struts, it is hardly a fair comparison. Though otherwise I agree that Rails is a great choice for almost every CRUD app, like we really should stop overstressing it. Just use whatever one we are comfortable with and has enough internal knowledge on and with modern computers it will be plenty fast enough.

TheRealDunkirk 4y ago
This whole thing happened about 4 years ago now, and the original application was written several years before that, before the rise of React and Angular, which have BECOME popular (IMNTBHO) because they try to address the gaping hole which is the frontend of using Java for web apps. Around that same timeframe, I tried using JHipster, which sort of attempts to do for Java everything that a Rails app stack does for Ruby. It took 45 minutes for my top-of-the-line Dell laptop/workstation to bootstrap it, and it was... unapproachable.
- kaba0 4y ago
  Why did you use Struts 4 years ago? That framework died at least a decade ago. But don’t get me wrong, I see where you are coming from, I’m just saying that your experience may not have been up-to-date even then, let alone now. In practice, with spring boot, quarkus and the like developing a backend app is plenty productive in java.
  - TheRealDunkirk 4y ago
    Ay yi yi. Maybe go back and reread what I wrote. I didn't use Struts, and the original app was written at a time when that was an accepted "meta." I've used Spring Boot. We'll have to "agree to disagree" that it's "productive." All these things that people are stacking on top of Java are just trying to implement concepts and features that Rails has had for 15 years, and they're still nowhere near as "productive."