5 ms·

I think my favorite part is buried in footnote 5: > Ironically, the performance issue becomes less articulated in this non-http, non-rails context, yet in thes

I think my favorite part is buried in footnote 5: > Ironically, the performance issue becomes less articulated in this non-http, non-rails context, yet in these cases people generally dismiss ruby as option, for its performance-issues. Which, catch-22, is one of the reasons Ruby is hardly used outside of Rails (and/or Web). It's a shame that most people only write Ruby in the context of Rails. It's a lovely language, and performant enough for a wide array of tasks. It can be startlingly elegant and exceedingly productive. Of course, it's valid to talk about Ruby performance in the context of Rails, as the author does. However, it's gratifying to see a more detailed discussion on what Ruby folks mean when they say "your database is usually the bottleneck," and the author does a good job at examining different aspects. (All that said: Rails is still a really good choice. So much of our work is just writing CRUD apps, and it's kinda boring. Rails makes it boring and easy, and it's a really good tradeoff.)

spoiler 4y ago
> It's a shame that most people only write Ruby in the context of Rails I fully agree with this! I used to use Rails for a few years (not professionally, FWIW), but didn't enjoy Rails that much. Even though, it's hands down the best "in class" framework, it beats anything in the JS or Python ecosystems (and claiming Django is anything close to Rails is just offensive to Rails). But anyway, I've yet to find something that's as good as Ruby for daily scripts or task automation. Ruby is one of those few languages you can just read (I can't explain it well), and coming back to old Ruby code, the "wtf is going on here" moments are fairly scarce (sans code that touches metaprogramming/eigenclasses/DSLs, but even then it's more straightforward than in other languages). Lately I tend to just use Fish for most things (which are simple), but still reach for Ruby when the task is a bit more involved. Like, yeah there's Python, but I never liked Python. That's not to say Ruby isn't without any warts, but that's just... Technology, I guess lol.
- drewbug01 4y ago
  I don’t have some kind of grand, unified theory about this - but the people I know who genuinely enjoy Ruby on its merits seem to think about code differently. Not different-as-in-bad, but just… different. I too find it hard to explain. > Ruby is one of those few languages you can just read I think this has something to do with it, though. The stdlib has a lot of different ways to “say” the same thing (TIMTOWTDI, anyone?) and used well it can be quite legible. But some programmers I know find that really frustrating. Maybe it has something to do with how one visually processes and reads code? How one might associate semantic meaning to things? I don’t know how, but it feels like there’s something interesting there to study.
  - KerrAvon 4y ago
    Yeah, there's a reason that _why the luck stiff was a Ruby person. Writing Ruby is (or can be) a more creative endeavor. Some people really dislike the inability to recommend or see one unambiguous path to follow. These people are generally happier with Python.
- ryantgtg 4y ago
  I agree. I’m not a professional developer, but I sometimes make bots/daily scripts, as well as scripts for work that are beyond Excel, and I always use ruby. My colleagues use python for similar work scripts, but to me they are painfully difficult to read and understand.
arkis22 4y ago
rails, postgres, PORO, and htmx is a monstrously productive stack
- iamgopal 4y ago
  Any examples?
  - arkis22 4y ago
    you're looking for what? my personal million dollar website or my billion dollar startup?
    - boredtofears 4y ago
      just any evidence to back up your argument
      - arkis22 4y ago
        just my years of experience, sorry
- ithrow 4y ago
  If you are one Rails, why not the hotwire stuff?
  - arkis22 4y ago
    https://github.com/hotwired/hotwire-rails https://github.com/hotwired/hotwire-rails deprecated. they use stimulus and its worse obfuscated JS than htmx IMO
- Lio 4y ago
  Personal opinion, if I was going to use htmx with a PORO backend I'd probably go for Roda[1] and Sequel[2]. If it was going to be read heavy I think I'd also pair that with SQLite for low latency and cheaper deployments. If I didn't know exactly how requirements are likely to change over time I'd probably go with with Rails, Postgres[2], Redis and Hotwire. You can go a long way with that and a small team. 1. https://roda.jeremyevans.net/index.html https://roda.jeremyevans.net/index.html 2. https://sequel.jeremyevans.net/ https://sequel.jeremyevans.net/
boredtofears 4y ago
I'm gonna play devil's advocate here: Ruby sucks in large codebases where conventions aren't well defined (unlike Rails, which has well understood concepts and abstractions). Having no ability to do any kind of static analysis means a large legacy codebase will contain giant rabbit holes for you to fall into any and everywhere you look -- unless, of course, the architect(s) responsible for the codebase thought very carefully about this and limited the number of abstractions. If they didn't, you're left stepping through all the metaprogramming and one-off abstraction implementations. Obviously, my experience is anecdotal, but I've decided my current job is the last Ruby job I'll take. I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up.
- ngc248 4y ago
  You are exactly right and the pitfalls you talk about are common to all dynamically typed languages.
  - heurisko 4y ago
    Which is why some dynamically typed languages, like PHP, are moving towards types.
- Lio 4y ago
  > Having no ability to do any kind of static analysis Wouldn't Sorbet count as static analysis? It even supports gradual typing specifically for legacy codebases. https://sorbet.org/docs/gradual https://sorbet.org/docs/gradual
- cntainer 4y ago
  > Ruby sucks in large codebases where conventions aren't well defined The community is working to improve the outside-Rails ecosystem with efforts like dry-rb or ROM. So you can find plenty of useful non-Rails conventions if you look for them, but if you're doing typical web stuff it is hard to compete with the productivity monster that Rails has become. > I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up. I guess RBS and Sorbet are trying to cover this point. I don't know how well they scratch that particular itch of yours as I haven't worked with Ruby for quite some time.

spoiler 4y ago

> It's a shame that most people only write Ruby in the context of Rails I fully agree with this! I used to use Rails for a few years (not professionally, FWIW), but didn't enjoy Rails that much. Even though, it's hands down the best "in class" framework, it beats anything in the JS or Python ecosystems (and claiming Django is anything close to Rails is just offensive to Rails). But anyway, I've yet to find something that's as good as Ruby for daily scripts or task automation. Ruby is one of those few languages you can just read (I can't explain it well), and coming back to old Ruby code, the "wtf is going on here" moments are fairly scarce (sans code that touches metaprogramming/eigenclasses/DSLs, but even then it's more straightforward than in other languages). Lately I tend to just use Fish for most things (which are simple), but still reach for Ruby when the task is a bit more involved. Like, yeah there's Python, but I never liked Python. That's not to say Ruby isn't without any warts, but that's just... Technology, I guess lol.

drewbug01 4y ago
I don’t have some kind of grand, unified theory about this - but the people I know who genuinely enjoy Ruby on its merits seem to think about code differently. Not different-as-in-bad, but just… different. I too find it hard to explain. > Ruby is one of those few languages you can just read I think this has something to do with it, though. The stdlib has a lot of different ways to “say” the same thing (TIMTOWTDI, anyone?) and used well it can be quite legible. But some programmers I know find that really frustrating. Maybe it has something to do with how one visually processes and reads code? How one might associate semantic meaning to things? I don’t know how, but it feels like there’s something interesting there to study.
- KerrAvon 4y ago
  Yeah, there's a reason that _why the luck stiff was a Ruby person. Writing Ruby is (or can be) a more creative endeavor. Some people really dislike the inability to recommend or see one unambiguous path to follow. These people are generally happier with Python.
ryantgtg 4y ago
I agree. I’m not a professional developer, but I sometimes make bots/daily scripts, as well as scripts for work that are beyond Excel, and I always use ruby. My colleagues use python for similar work scripts, but to me they are painfully difficult to read and understand.

arkis22 4y ago

rails, postgres, PORO, and htmx is a monstrously productive stack

iamgopal 4y ago
Any examples?
- arkis22 4y ago
  you're looking for what? my personal million dollar website or my billion dollar startup?
  - boredtofears 4y ago
    just any evidence to back up your argument
    - arkis22 4y ago
      just my years of experience, sorry
ithrow 4y ago
If you are one Rails, why not the hotwire stuff?
- arkis22 4y ago
  https://github.com/hotwired/hotwire-rails https://github.com/hotwired/hotwire-rails deprecated. they use stimulus and its worse obfuscated JS than htmx IMO
Lio 4y ago
Personal opinion, if I was going to use htmx with a PORO backend I'd probably go for Roda[1] and Sequel[2]. If it was going to be read heavy I think I'd also pair that with SQLite for low latency and cheaper deployments. If I didn't know exactly how requirements are likely to change over time I'd probably go with with Rails, Postgres[2], Redis and Hotwire. You can go a long way with that and a small team. 1. https://roda.jeremyevans.net/index.html https://roda.jeremyevans.net/index.html 2. https://sequel.jeremyevans.net/ https://sequel.jeremyevans.net/

boredtofears 4y ago

I'm gonna play devil's advocate here: Ruby sucks in large codebases where conventions aren't well defined (unlike Rails, which has well understood concepts and abstractions). Having no ability to do any kind of static analysis means a large legacy codebase will contain giant rabbit holes for you to fall into any and everywhere you look -- unless, of course, the architect(s) responsible for the codebase thought very carefully about this and limited the number of abstractions. If they didn't, you're left stepping through all the metaprogramming and one-off abstraction implementations. Obviously, my experience is anecdotal, but I've decided my current job is the last Ruby job I'll take. I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up.

ngc248 4y ago
You are exactly right and the pitfalls you talk about are common to all dynamically typed languages.
- heurisko 4y ago
  Which is why some dynamically typed languages, like PHP, are moving towards types.
Lio 4y ago
> Having no ability to do any kind of static analysis Wouldn't Sorbet count as static analysis? It even supports gradual typing specifically for legacy codebases. https://sorbet.org/docs/gradual https://sorbet.org/docs/gradual
cntainer 4y ago
> Ruby sucks in large codebases where conventions aren't well defined The community is working to improve the outside-Rails ecosystem with efforts like dry-rb or ROM. So you can find plenty of useful non-Rails conventions if you look for them, but if you're doing typical web stuff it is hard to compete with the productivity monster that Rails has become. > I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up. I guess RBS and Sorbet are trying to cover this point. I don't know how well they scratch that particular itch of yours as I haven't worked with Ruby for quite some time.