Hacker News Reader

Comment by drchopchop | Hacker News Reader

I've had to deal with Ruby for the last 2 years, and one of the main problem is the gem ecosystem. The language and standard libraries are pretty narrow, unless you add Rails (which adds a new variety of breaking upgrade headaches).

Thus, there's always the desire to use third-party gems to achieve pretty basic stuff (localization, decent networking/REST, database drivers, etc). These then tend to go out of date. It's pretty common to find well-used gems that haven't been updated in 5, even 10 years. This puts the developer in a tough spot - reinvent the gem/wheel? Or be forced to stay on an EOL version of Ruby?

View on HN

I haven't had your same problem and I've been working with Ruby for the last 8 years. I've also deployed Go, Python, Elixir, and Javascript to production. Here are my thoughts on Ruby in 2020:

Ruby, between versions, doesn't have many breaking changes, if any. They're more additive changes than they are subtractive. That obscure gem that has a last commit date of 2 years ago? Probably still works. Bundler complaining the Ruby version isn't supported in the gemspec? Fork, edit, push, bundle, success.

When you say basic stuff, I think of "busy work that's already solved by someone else, probably in a more complete than my half-assed attempt would be just so I can focus on more domain-specific problems and implement business logic." That's a fine tradeoff. My clients don't pay me to implement things like authentication or design an ORM: They pay me to do business logic. `bundle add devise; rails g devise:install; rails g devise User; rake db:migrate` gets me rock-solid authentication and I didn't have to think twice about it.

"Look at all the things I'm not doing" was something DHH said when he released Rails. A lot of Ruby is the same way. That's fine with me, and a lot of others.

There's a lot to love with Ruby in 2020. I still find it to be the most hyper-productive ecosystem and it doesn't change daily (see: Javascript's ecosystem). It's a language that's expressive, enjoyable, and plain fun. And for the very vast majority of web applications — which are CRUD-centric — Rails is still an extremely valuable means to get up and running. Scale? 99% of us won't need to worry about scale, and when we do, that's a great problem. Speed? For 99% of us, our database will be the slowest part of our application — even when indexed and tuned.

Sure, it may not be 2020 sexy. The socks you're wearing probably aren't either, but they still get the job done.

Ruby is plenty sexy to me! Been working in a large "modern" Typescript codebase for about a year now, and every chance I get to go back to writing Ruby, it's a breath of fresh air!

Ruby is a joy and I'm always a little confused by it getting so much negativity on internet forums. I guess we all have our preferences, but the Ruby ecosystem feels sane and stable to me.

A lot of people are put off by all the 'magic' and weird syntax. I've heard a lot of criticisms from the python crowd about hidden state and whatnot... but you have to understand where those folks are coming from and what language principles they subscribe to. (Python and Ruby are principally opposed in many areas, as an example that I'm familiar with)

Personally I don't mind magic or hidden state that much but then again I came from perl.

Like a Ruby dev is going to take lip from someone who thinks midnight is false.

Never realized this... yay for Javascript-like screwy type coercion. Now I have some more ammo to rib the pythonistas in my life. Thanks!

Good points, and I certainly understand why the Ruby community is so passionate. The language is expressive, mutable, and has some nice syntax. My personal problems are:

- Rails is the monolith that gives you all of that auth/database/etc capability, and it's very non-trivial to upgrade

- Refactoring a large codebase with a dynamic, untyped language like Ruby is extremely difficult without 100% test coverage

- Unusual syntax conventions which can get you into trouble (y = x.blah vs x.blah!), strings vs symbols, magical naming conventions for Rails, etc etc

- Auto-loading is a mess

- ActiveRecord is great until you care about DB performance, and then you end up continually working around it's quirks (the N+1 problem, indexes failing due to int/string type conversion, etc)

- Everything in Rails is convention over configuration. File paths, names of classes, names of routes, mapping of AR to DB table, etc. Sure it "just works", but when it doesn't, it's not always easy to figure out why.

- Monkey-patching is cute, but, seriously? Hot-patching system library functions?

- What's a variable? What's an accessor? What's a function? Parentheses are optional, return is optional (yet @ is required for class/instance vars?)

Again, none of this prevents you from building a quick and easy CRUD app, but I've found the deeper I go, the less I like it.

Your points are valid. Understanding the quirks and features of Rails is a lot, too.

It sounds like you had to dive head-first into a mess where it was hacked together by non-Rubyists who learned "just enough" to push to production, and were by no means diligent about following Rails conventions.

Obviously, this issue is agnostic of what language one chooses. But it certainly leaves a bad taste when there's all this "magic" happening (see: metaprogramming). That magic is what makes working with Rails so productive.

Rails makes it easy to do bad things because of how magical it is. `@post.comments.each { }` when you didn't preload `comments` is bad. This is fixed with `Post.includes(:comments)`.

Similarly, if you avoid its conventions — overriding `table_name` on your model, in your example — and try work against it, rather than with it — it becomes more of a chore than it does a treat.

Like all frameworks, they require a little bit of diligence and care and understanding to really get the full effect. Rails is great because it makes a lot of assumptions at the cost of brainpower, and for the vast majority of things this is good. It's not always the right tool, and it doesn't need to be. But when it is — again, a large majority of web apps are just CRUD — and when it's written with a little bit of care, it's great.

I've been working with Ruby professionally for something like 10 years and all of those points are generally just things you learn to work around.

And Rails itself is less monolithic than you think. You can swap out most of the components for other gems, like ActiveRecord vs. DataMapper (though I am not aware of anyone who does this anymore and the level of support for Rails gems generally outclasses everyone else) or remove those components entirely.

Much of the "Rails magic" is inside ActiveSupport, which you can import without bringing in all of Rails proper. Personally I think much of the stuff in ActiveSupport should go core.

These issues could be applied to any modern language - I don't see them as specially affecting Ruby. As someone who has worked in many languages professionally for 20 years, Ruby/Rails is my favorite productivity tool for web apps, hands down.

FYI see Zeitwerk gem for autoloading improvements.

The article mentions about the use of "refinement" that only monkey patches to your local scope and won't affect the rest of the codes.

Also, type hinting is coming to ruby 3.

> magical naming conventions for Rails

That's rails' problem. I don't like it either but nothing to do with ruby.

Seems like half your problem comes from rails.

A lot of gems don’t need to be updated. Stable software is a thing, especially in more mature ecosystems such as Ruby.

> The language and standard libraries are pretty narrow, unless you add Rails

Rails is neither the language nor the standard library, so the “unless” part seems superfluous.

> These then tend to go out of date. It's pretty common to find well-used gems that haven't been updated in 5, even 10 years. This puts the developer in a tough spot - reinvent the gem/wheel?

If it's open source, why would reinvention rather than forking and assuming maintenance (for one's own needs, not necessarily publicly) be an issue?

This is because the next generation of hot coders is working on JS or something more exotic like Rust. This is why I think that even though Rails is still a good platform for building a certain class of webapps the writing is on the wall and I'm planning to transition away from it over the next few years.

In 5 years there'll be another shiny thing everyone will flock to. It's part of the fun, but there are some languages that just do that particular thing just right. Ruby/Rails is bittersweet to me. It does that thing just so right, but it feels like there's an evolution around the corner that could be an upgrade when it comes to the ecosystem. It certainly doesn't feel like Rust is a good replacement if you enjoy Ruby syntax and dynamic typing simplicity. Ruby reminds me a lot of how Perl 5 is a great language, yet finding jobs in Perl 5 is becoming more and more difficult.

I'd love to think that Raku (formerly Perl 6) would be that language, but it doesn't seem like the trajectory is there.

Or you could become an open source contributor and improve the ecosystem by submitting PRs to existing gems or writing your own.

The community is us. Ruby is what we make it. So let's make it better.

Rails has been very good to me over the years so I am tempted to try to help out but I think if I'm going to volunteer I'd prefer to help a more modern stack like KTOR.

Consider Laravel (PHP) and Django (Python) if you want a like-for-like replacement in a better supported ecosystem.

I'd probably go for Django but it feels like a step sideways more than a step forward. Once you've gotten used to a more modern language with great tooling, typechecking & null handling it's frustrating to go back to a stack where you're getting errors in production that would have been caught by a compiler.

I'm in the same spot. I still use & love Rails, but having adopted TypeScript & VS Code (w/ React) for the front-end, I find myself missing those luxuries when I switch back to Ruby/Rails/Vim.

I'm leaning towards a full TypeScript stack for my next project. The idea of sharing types & code between client & server is incredibly seductive. But there's no Rails for TS/Node, so I know it's going to be a shit show assembling all of my chosen libraries into a cohesive whole.

Although looking at your previous comment, perhaps I should give Kotlin / Ktor a try?

FYI I think Redwood is trying hard to be Rails for TS/Node...

(https://news.ycombinator.com/item?id=22537944)

Redwood looks really interesting. I'd like to try it on a small project. The emphasis on serverless seems like a bit of a different direction than Rails though.

I'm in exactly the same boat. Rails gives you so much functionality for free. Kotlin/KTor is not a drop in replacement since it's closer to something like Sinatra in scope but it still looks like the best bet going forward to me.

> The language and standard libraries are pretty narrow

Compared to which other language?

> Compared to which other language?

Java, for one, but obviously it's subjective

You can use JRuby and then have access to both library ecosystems.

Not JavaScript or Go, that's do sure...

Ruby is generally very backwards compatible, so I rarely run into an issue where an old gem requires that I run an old Ruby version.

Ruby is super backwards-compatible with new versions. Even to much. The core team almost made religion from it. So I don't really understand what the problem is - aside from using not maintained library. It will work, unless it was written for 1.8 or something.

Just because something hasn't been updated for a while doesn't mean it's broken.

Does the dependency manager not enable fork + override dependency?

Yes, but you can easily get in a situation where say Github says "gem X is vulnerable, upgrade it", but can't generate it needs to update version of dependent gem Y, and that would break gem Z which is version locked because ruby versions etc...

This happens, but it's not really that common, and it's certainly not insurmountable.

You can fork any gem in github, fix whatever issue it has, and point your Gemfile at your fork on github. Bundler treats it as the same package so it doesn't break your dependency tree either above or below it. I've used this to fix an incompatibility in the middle of my dep tree before. It's annoying, but it's not exactly a big deal.

Reply on news.ycombinator.com