8 ms·

Rails is still “a thing” and is better today than it has ever been.

by mostlysimilar 4y ago

kache_ 4y ago
only because the companies that use rails are stuck on it :P
- djfobbz 4y ago
  Majority of the ones I know are making billions. Why change something that’s already profitable?
  - kache_ 4y ago
    Why make billions when you can make millions (not dealing with bad async primitives and type safety that doesn't need some third party project like sorbet)
- wiseowise 4y ago
  Nope.
- moooo99 4y ago
  Many start-ups (especially ones that aren't backed by millions of VC money) choose Rails because of the super high developer productivity and the broad availability of well tested packages. You could just fade out rails as you could with any other monolith, but many companies aren't doing it because it offers legitimate advantages.
hirvi74 4y ago
Really? I miss it sometimes. I haven't kept up with it in over 5 years (switched to .Net now). I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.
- deleted 4y ago
  [deleted]
- paulgb 4y ago
  I haven’t kept up with either, but remember that “because you know it” is a perfectly reasonable and fine reason!
  - travisgriggs 4y ago
    I struggle with this a little. Or rather, I struggle with the counter corollary: “Because you don’t know it.” I mean, I solve most of my problems with the hammers I have at hand. But I try not to fall exclusively in this trap of “I will use tech X because that’s what I know.” But I see a majority of my programming peers who will avoid moving “forward” because it’s easier to “stay behind.” At first, this works, because the difference between what’s new and evolving versus what’s established and a “core competency” is trivial and easy to marginalize. As it persists over time though, the investment can become a real millstone. I am pretty comfortable with Python. We use it some pretty key areas in our product. It’s an established technology and competency for us. Last year, I needed to construct a service that was going to involve spinning up LOTS of little long lived threads. I was concerned about doing this in Python. Doing so would be easy and straightforward. “Because I know it” would definitely have said “do this in Python right now, deal with scaling issues later.” Instead I looked around and deemed this a good reason to take Elixir for a spin. I’m glad I did. It turned out to be a good fit for this problem. “Because I don’t know it” caused others around me to raise their eyebrows and question my approach initially. Was it the 100% best choice? Who knows for sure. But it’s worked out well. Ironically, just the other day, a data serialization library I have in both systems, the Python one needed to run faster (new use case for it suddenly needed speed that we didn’t hitherto care about). After some profiling, I rearchitected the python algorithm to be more similar to the Elixir one and gained about 50% speed up.
    - weatherlite 4y ago
      There's so much more to this then Stack X runs faster or has better concurrency - there's development time, there's the team's ability to maintain the code, there's community size. Performance is overrated most of the time - it simply doesn't matter much to the business if you save some money on AWS bills compared to human cost.
LAC-Tech 4y ago
I avoid rails-style megaframeworks like the plague. I'm fine writing the glue code if it means I understand more of the stack, or it doesn't refuse to budge if I occasionally have to go "off the rails".
charlie0 4y ago
Same for Laravel, although it hasn't grown as much as Rails, the amount of batteries included is amazing. There's very little I've had to reinvent, unlike my Node JS projects, where there's too much time wasted in finding and learning 3rd party packages that are outdated in a year or two.

Rails is still “a thing” and is better today than it has ever been.

kache_ 4y ago

only because the companies that use rails are stuck on it :P

djfobbz 4y ago
Majority of the ones I know are making billions. Why change something that’s already profitable?
- kache_ 4y ago
  Why make billions when you can make millions (not dealing with bad async primitives and type safety that doesn't need some third party project like sorbet)
wiseowise 4y ago
Nope.
moooo99 4y ago
Many start-ups (especially ones that aren't backed by millions of VC money) choose Rails because of the super high developer productivity and the broad availability of well tested packages. You could just fade out rails as you could with any other monolith, but many companies aren't doing it because it offers legitimate advantages.

hirvi74 4y ago

Really? I miss it sometimes. I haven't kept up with it in over 5 years (switched to .Net now). I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.

deleted 4y ago
[deleted]
paulgb 4y ago
I haven’t kept up with either, but remember that “because you know it” is a perfectly reasonable and fine reason!
- travisgriggs 4y ago
  I struggle with this a little. Or rather, I struggle with the counter corollary: “Because you don’t know it.” I mean, I solve most of my problems with the hammers I have at hand. But I try not to fall exclusively in this trap of “I will use tech X because that’s what I know.” But I see a majority of my programming peers who will avoid moving “forward” because it’s easier to “stay behind.” At first, this works, because the difference between what’s new and evolving versus what’s established and a “core competency” is trivial and easy to marginalize. As it persists over time though, the investment can become a real millstone. I am pretty comfortable with Python. We use it some pretty key areas in our product. It’s an established technology and competency for us. Last year, I needed to construct a service that was going to involve spinning up LOTS of little long lived threads. I was concerned about doing this in Python. Doing so would be easy and straightforward. “Because I know it” would definitely have said “do this in Python right now, deal with scaling issues later.” Instead I looked around and deemed this a good reason to take Elixir for a spin. I’m glad I did. It turned out to be a good fit for this problem. “Because I don’t know it” caused others around me to raise their eyebrows and question my approach initially. Was it the 100% best choice? Who knows for sure. But it’s worked out well. Ironically, just the other day, a data serialization library I have in both systems, the Python one needed to run faster (new use case for it suddenly needed speed that we didn’t hitherto care about). After some profiling, I rearchitected the python algorithm to be more similar to the Elixir one and gained about 50% speed up.
  - weatherlite 4y ago
    There's so much more to this then Stack X runs faster or has better concurrency - there's development time, there's the team's ability to maintain the code, there's community size. Performance is overrated most of the time - it simply doesn't matter much to the business if you save some money on AWS bills compared to human cost.

LAC-Tech 4y ago

I avoid rails-style megaframeworks like the plague. I'm fine writing the glue code if it means I understand more of the stack, or it doesn't refuse to budge if I occasionally have to go "off the rails".

charlie0 4y ago

Same for Laravel, although it hasn't grown as much as Rails, the amount of batteries included is amazing. There's very little I've had to reinvent, unlike my Node JS projects, where there's too much time wasted in finding and learning 3rd party packages that are outdated in a year or two.