This is very detailed. I remember discovering many of these Ruby conventions when I answered a stackoverflow question about to_a vs to_ary years ago. It goes even deeper than I imagined, that bit about sleep was especially interesting.
> raise an error implicitly - effectively analogous to praying you get the right types
That's...not the case. Not explicitly testing or raising an error is neither “praying you get the right types” nor (as the piece later claims) the worst option, or leaving things to the next developer.
Its deferring type checking and error reporting (or type conversion) to some other method that the argument is passed to, and its absolutely what you should do 100% of the time instead of adding additional layers of redundancy if (1) you are passing the argument to a method that’s interface commits to the right type verification or conversion for the use case, and (2) you don't (in the case of error reporting) have a need to report errors differently than it will.
Learn functional style programming, it will take you a long way towards writing maintainable, concise code. The request/response cycle and stateless applications are a great fit for functional programming in Ruby.
You may be tempted to use a lot of meta programming, because Ruby makes it easy. Resist the urge and only use it if you have no other option (which is rarely the case).
Byebug (or whatever debugger you have available) is your best friend. Also using your repl (irb/rails console) will let you “play” with your application and use your application like a shell with a domain specific language.
If you have access to Ruby 3.0, absolutely learn how to incorporate static types into your application it will save you so many headaches in the long run.
If you’re working on a web app, learn how to use your database without the ORM. ActiveRecord, for example, is really nice but if you don’t understand the underlying SQL it generates you’re going to be in for a word of pain. Learn the different ways to inject custom SQL into your active record queries. Use the .merge function to easily create complex queries using scopes from multiple activerecord classes.
Checkout Trailblazer to learn modern paradigms for building web apps with Ruby.
If your employer will pay for it, or you can afford it: Rubymine is absolutely worth every single penny. Use the 30 day trial and you’ll be hooked, I can almost guarantee it.
Take a few minutes and understand how the Ruby Ghost Class works, it’s seldom useful but you’ll impress any senior developer with his salt if you know what it is and how it works.
I have my own license for all JetBrains products so I have RubyMine (and the ruby plugin in intellij which is the same thing). The code base is still in 2.5 or 2.6. But I hope to bring it to 3.0 slowly the get typing. I'm used to typed languages and I would really miss that.
Why would I have different debuggers available? Can't I just choose the one I want locally?
Different code bases and teams usually just end up with a bespoke debugger, there are multiple available. There’s the default debugger, byebug, pry debug and I believe Rubymine uses one called debase, under the hood.
You can use whichever you want but usually one will be specified in your project Gemfile because someone on the team likes that particular debugger and added it long ago.
Rather tangential, however Ruby seems to exist entirely on the backs of Shopify now [1], and every Ruby-related post on here goes back to a Shopify employee. Did the founder of Shopify start with Ruby so now they’re wed to it culturally? Each of these Ruby posts has a gross mismatch between engagement and score.
I apologize for the digression, but Shopify today reminds me of some Delphi/object pascal shops I’d engaged with earlier in my career. Where the tooling became the primary focus and identity of the staff rather than the solutions (a sort of cargo culting off of that initial business success), and that focus meant the firm ended up being staffed with what could best be described as big fish in little ponds (e.g. the “Delphi expert” who was the guy who stuck with Delphi after everyone else had moved on to other technologies), in a recursive loop.
[1] - other successful companies started with Ruby / RoR (though in many cases it could be called legacy), but right now it seems that 100% of Ruby advocacy comes out of the halls of Shopify. The firm has turned to evangelism.
The overwhelming bulk of the Ruby entrants on that list formed in 2009-2012 (as did Shopify). At the time Ruby was the love interest of HN, and it isn't at all surprising that the HN-affiliated had an affinity to it. The next cycle will be built on whatever the current hotness is. Rinse and repeat.
No one should cargo cult off of that. Ultimately the product is magnitudes more important than the technology (at least in most cases).
I don't think that's totally true, Stripe has Sorbet for example. On the other hand, Ruby seem to be less popular than before and almost no one uses it in Europe. But Ruby 3 seems very nice. It's hard to predict its future.
I mean, materials coming out of Ruby and Rails are so rare and few I could hardly call them evangelism. And for the first time ever in history RoR has some decent resources backing it. Compared to Python, JS, Go.
And if people dont like the word dying, then RoR is definitely in decline. So doing a little bit of push and PR or evangelism isn't so bad.
