4 ms·
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
by joshmn 6y ago
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.
- jaredcwhite 6y agoRuby 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!
- mostlysimilar 6y agoRuby 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.
- tomc1985 6y agoA 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.
- drchopchop 6y agoGood 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.
- joshmn 6y agoYour 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.