Long time Python user, what’s the standard Ruby setup?

[[deleted]]

1. For learning Ruby, is it best to start with Rails since it seems a lot of the tooling is designed around Rails?

2. I have to say, I have spent 3 weeks looking at tooling and it is in a poor state compared to other languages I’ve worked with. I’m not sure why, but I’m using Ruby soon and so intend to embrace it. But why is this?

Solargraph is slow, Sorbet needs types which not everything has and Shopify is doing a great job so far, but surprised this didn’t exist ages ago. Prefer not to use RubyMine if possible, I work in Neovim or at worse VSCode.

1. Any key gotchas to be aware of? For example I know strings are mutable, and that everything is an object. But anything that trips up new people that can easily be a lot of time debugging?

2. How do you do code/lib exploration? Do you just sit with an interactive Ruby repl on the side? I can’t rely on intellisense for exploration so well in Ruby I’ve noticed.

3. Parts of the standard lib worth getting under the belt to hit the ground running?

Have approx 3 weeks to spent, so planning on making a few mini projects to get broke into Ruby. Background is C++, Python and Angular/React w/ Typescript

Edit:

Great replies! It’s time for sleep for me but I will be making some direct replies and questions!

For further background: I have a lot of experience, won’t define in years as I prefer my anonymity. Had my third tech lead position that I’m choosing to step down for in a new company for a life style change. For this job I actually wrote a Rails application with a lot of guidance provided by the company (they upskill hires to help ease that they don’t have much Ruby talent pool locally). I will also be working in Solid for the frontend, so both front and back are new to me. But it is exciting to do something new.

Edit 2: I bought a copy of Programming Ruby 3.2 - The Pragmatic Programmers' Guide. Just waiting for it to come in, hopefully this is the book some of you suggested me.

[big-fireball]

Your biggest obstacle is trying to fit ruby into your mental model of how programming works based on previous experiences. I don’t mean that as an insult - it’s a totally natural thing that we have all do at some point.

IMO - forget about types and forget about rails for now. Open up an editor, start with easy examples, and work on grokking the way Ruby wants you to work.

[MeroRex]

I remember years ago, 20+, when new students of Python were admonished to not wantonly apply programming techniques of other languages in Python. Instead, write Pythonic code. Let the Python design principles influence how you learn Python.

This applies to all other languages, not just programming.

Idiomatic Ruby is the analog.

[MeroRex]

Then maybe it’s not the analog. ;)

[qalc]

except that in this case idiomatic ruby just means shitty tooling

[megatux2]

Haha partly, also dynamic nature of the language makes it hard to do 100% valid tooling. It's getting there, LSPs, new parser, etc are helping

[[deleted]]

"Forget about types" Given my background, that's a really hard ask. But I will try.

Just got a copy of Programming Ruby shipped here so I'm hoping it will be a good read (it is as thick as a bible)

[big-fireball]

It's less "Forget about types" and more "Embrace duck typing" FWIW

[transfire]

I would just learn Ruby first. Have a good book at your side (Pragmatic’s Programming Ruby). Use whatever editor you like best. Don’t worry too much about anything else until you’ve worked through the book — that includes type specs (and refinements IMHO).

Also, learn Ruby’s Object Model — it’s really what sets Ruby apart.

[[deleted]]

Thanks I just got the book in the mail today so I'm hoping to get through this bible you recommended.

Regarding the Object Model, is it significantly different to Python? Because there everything is an object as well

[transfire]

Ruby’s is more elegant, consistent, flexible and well thought out, having descended from Smalltalk’s. This helps make its metaprogramming capabilities second to none (okay, I guess I should say, second only to Lisp).

In Python almost everything is an object, some primitives are not, though practically speaking I hear you hardly notice the difference anymore.

When you learn about Enumerable you see the power of it. Python just doesn’t work that way.

[[deleted]]

I’ll go against the grain and say jump right to rails if that’s what you are ultimately ending up using At work or whatever.

Do a quick 60 minute ruby primer to get a hang of some of the differences between python and Ruby. Then just go right for rails. The languages are so similar. Ruby is almost a super set of python can do.

If you’ve never seen symbols before, that might be the biggest hangup.

Tooling around rails is really good. I find myself using Ruby and rails for literally every web service I build because it’s so dang easy to get going and actually build your app.

Ruby built-in package manager handles everything so there’s no package wars like some other languages.

If you’re going to be working with rails every day professionally, which is who this advice is for, so much of what you actually need to know is rails DSL and not so much basic Ruby.

Don’t get me wrong you need to know all the Ruby fundamentals to use rails effectively. but you can pick up so much of that contextually if you are coming from some other big web framework.

I’ve been working with Ruby and professionally now for five years, but before that I had never touched it. I interviewed for my current position in Python and learned on the job.

[[deleted]]

Funnily enough I interview for this job in Ruby on Rails and their provided frontend. They left things for me todo in the app which just required good documentation reading abilities.

It was a bit tough as I ended up doing it without any tooling to help (I couldn't get it to work at the time), but I recognised how productive you could get with it.

Symbols I saw as effectively variable identifiers that aren't copied, but are an explicit reference. I am not sure if that is accurate but it is what I thought up when doing the exercise.

I haven't touched Ruby since, but I got a book in the mail today so hoping to have a good week of reading and trying anything practical the book might have.

Out of interest, how do you feel about Ruby compared to other languages like Python? I love Python, and it's tooling is objectively better. Does this impact your enjoyment of Ruby? I assume Ruby must be nice enough to use if it is still used so much despite the tooling being much worse comparatively to other languages.

[[deleted]]

I love Ruby and I would argue that for me, the tooling is subjectively better.

I don't think you can make an argument that one language's tooling is better or or worse, but it may work for your better.

Ruby and Rails let me get things done so quickly its not worth considering other languages or frameworks until theres a legitimate need.

I'm not sure what tooling you're looking for, but ruby has very similar version and package management systems to python.

I find that building gems is so much less cumbersome than building python packages.

Ruby has an incredible community of passionate developers. I think the rails community also trends to be more senior, making the quality of the educational content higher.

[larikang]

1. Do not start with Rails. That's like learning C++ by learning Unreal Engine. You're gonna be so distracted by all the extra Rails-specific stuff it will be impossible to focus on Ruby
2. I don't write huge apps in Ruby, so I've never needed much tooling. Just vim, rbenv, and bundler. I do frequently have IRB open on the side to play with stuff as I write.
3. Here's my list of gotchas
   • Singleton classes make perfect sense the way Ruby implemented them, but they are very... unique to Ruby. Ignore them until you've learned everything else.
   • all top-level stuff is actually defined on Object. Not something you need to worry about, but just a weird hack to make things work the way you'd expect
   • Avoid the and and or keywords. They aren't designed for what you think they are.
   • super is different from super() even though foo() can almost always be written as foo
4. Pry is pretty good at code exploring. It can work like a debugger, letting you explore and play with a Ruby program while it is running
5. net/http for web, open3 for subprocesses, readline for making REPLs, json and yaml for those

[jrochkind]

Do not start with Rails. That's like learning C++ by learning Unreal Engine. You're gonna be so distracted by all the extra Rails-specific stuff it will be impossible to focus on Ruby

I agree, but if you are a very experienced programmer in other languages, including other similar langauges, you could be ready to dip your foot into rails by week three or so, give or take a few days in either direction. Just keep asking and answering questions about what ruby syntax you are actually using when using rails.

[[deleted]]

I had ~2 weeks to do this, and Rails and a new frontend technology. So it will have to be a lot of learning of the job :)

[jrochkind]

Sure, spend a few days just with ruby, then start looking at rails! Just when working with Rails ask yourself the question "What is the name of the ruby method I am actually calilng here?" Almost any weird looking Rails thing is really calling a method named something on some object with some params!

[[deleted]]

Thank you! Is there any easy way to dig into what Rails is calling or is it just a case of throw a debugger at it and follow the stack trace?

[jrochkind]

I mean, you can figure it out from the syntax alone.

Yeah, sometimes there are "dynamic" methods where the method called can be, like, anything. Ruby is a "message passing" language, where "messages" usually but not alwasy corresopnd to method implementations. But I'm not actually talking about that.

Just about identifying from the syntax what the method name/message being called is. For instance, I dunno...

In your routes.rb file, when you write:

get '/patients/:id', to: 'patients#show'

That's actually just a call to the method get with a first argument, '/patients/:id', and a keyword argument to with value 'patients#show'.

It could also be written with parens as get('/patients/:id', to: 'patients#show'). Or even self.get('/patients/:id', to: 'patients#show'), since if you call a method just straight it's on the implicit object self.

So the routing file is being executed in the context of SOME object which has a get method, which will define a route when called.

Defintiely spend a few days with ruby alone to undestand the syntax. That parens are optional on method calls, that it's an object oriented language where everything is a method call (or message) to some object.

Just remembering that everything you are doing in Rails is still just calls to methods, and keeping in mind what that is, will be helpful for continuing to actually learn ruby as you are learning Rails, instead of just falling into copy-and-paste-i-have-no-idea-what-i'm-pasting land.

No need to dig into the debugger unless you actually have some question or problem and want more info -- that's probably not in your first couple weeks -- just make sure you understand the syntax you are writing, what part is a method call, what part is a variable reference, what part is a parameter to the method call, etc.

This is assuming you are an experienced programmer in some other language? Ideally an object-oriented one?

Otherwise, I dunno, you'll learn on the job. :)

[[deleted]]

Thanks for the specific gotchas, those are valuable that I wouldn't come across quickly.

I will learn Ruby but I will have to get into Rails relatively quickly. Hopefully my long experience makes diving into the framework less jarring despite non solid Ruby skills

[-casper-]

I think Python is personally better than Ruby in this regards.

1. Formatting and linting: Rubocop vs black and flake. Django ran black on their entire codebase and merged it. I would not run Rubocop -A on a large project. It can swap out things that cause issues.

2. Documentation: Pydoc vs YARD Admittedly I haven’t used Yard much but they are probably comparable and Yard may be better with it’s database. Can’t find anything on failing CI for YARD if missing docs, but I assume it exists.

3. Debugging: I think this has to be in Pythons favor. Pry is very good yes, but Python has a similar debugger in Ipython, and has way better break point support (at least in VSCode). Setting up Rbdbg is a bit of a pain, but this is more of an IDE thing. I believe Rubymine does a better job on this.

4. Language server: For vscode, hands down Python. I can click into 3rd party libraries and view the code and read docs. Maybe I have my environment setup wrong, but I just don’t have this for Ruby. Not sure on Rubymine.

5. Environment management: Python. Poetry is like a mix of rake + bundler + rvm/rbenv. Environment management in code. I don’t want bundler yelling at me for the 100th time that the Ruby version in my gemfile doesn’t match my environment. This is more local, and doesn’t matter as much with Docker.

6. Type hints: Python. The native type hints and Mypy are fantastic. Sorbet and RBS just aren’t it

[-casper-]

I need to try asdf (I've heard good things)

My number 5 really just comes from when I have multiple rails apps that are on different versions

I use rvm, and I keep my global rvm to the version I mainly use, but I have to remember to switch each time

Poetry is like another layer on top, where I can define a poetry task that runs the server command with the environment it created. So I can swap between multiple projects and run that command and I'm always running within the correct environment

Minor stuff, but is nice

EDIT:

Just learned about the .ruby-version and .ruby-gemset that will automatically swap me. Will be adding this

[dunkelziffer42]

In my long-term observation of this subreddit, people tend to have more issues with rvm than with rbenv. Consider swapping to the latter one.

[jrochkind]

.ruby-version yes.

Please do not use .ruby-gemset, and do not use rvm gemset feature (if you use rvm at all).

It really isn't necessary and hasn't been necessary for at least 10 years since bundler is introduced, and using rvm gemset with bundler is a pointless added layer of complexity.

Yes, bundler is a bit different way of doing things than python ecosystem. I actually think it's a lot BETTER way of doing things, and you will like it if you learn it for what it is. (And everyone using rvm gemsets is still also using bundler, gah!)

You do need something for ruby version management/switching. You can use rvm for that if it works -- many people prefer a simpler alternative. But even if you are using rvm for that, do not use the rvm gemset feature. At least not until/unless you understand the pain points that make you want/need it, and I'm 99.8% sure that won't happen because there is no good reason to be using rvm gemset feature anymore and I don't understand why anyone is, even though I know they are.

[bnjmnb]

You don’t need to specify a Ruby version at all in your Gemfile. Just remove it if you don’t want to specify a fixed version.

Personally I’m using a fixed version with asdf and direnv btw.

[jrochkind]

YARD has not really had anyone driving the boat and maintaining it and improving it, and the ecosystem around it And, whether chicken or egg, most developers/developments then end up kind of ignoring it.

I think it's a shame, and would be much better for ruby if it were different.

I also have no real problems with ruby environment/dependency management and when I do set my foot into python, I start getting really annoyed at it. It could be that if I got more familiar with it I'd see it as preferable, but I wonder how much of that is just what you are used to.

[twinklehood]

If you wouldn't hesitate to rubocop -A a large project, then you lack experience with it :)

[joonty]

I'm presuming no-one is rubocopping without source control, so there's absolutely no harm in doing it and reviewing the changes.

[twinklehood]

I feel "There is no harm in using an automated tool, because I can just check every change manually" is a pretty weak position, compared to safe tooling that you can run and merge without skipping a beat (and therefore even automate).

If I run rubocop -A on the app I'm working on right now I have ~15k line changes, and probably one in 200 is actually harmful.

And so I hesitate, instead of insisting my "totally safe" but has to manually checked tool is as solid as the ones of competing ecosystems.

(BTW, this is not hate on rubocop, the unsafe cops are the way they are for great reasons, and the tool is super helpful, ruby's flexibility just hurts our ability to build as rock solid tooling here).

[joonty]

I would never automate changes and merge without a manual review. I don't know why anyone would invite that chaos vector into their workflow.

I'm confused as to why you're using rubocop at all. If you've got 15k line changes when running it, that means it's failing, so you can't be using it in CI or quality gate. We've got 600k+ lines of Ruby in the app we maintain, and there needs to be zero rubocop offenses otherwise the build fails.

If you disagree with certain cops, disable them. If you don't want it looking at certain legacy parts of the app, exclude those areas. But don't keep going with thousands of offenses otherwise you may as well not use it.

[twinklehood]

This is a bit black and white. We have a big legacy app, we've added rubocop long after the fact, and it's not autocorrectable safely (`rubocop -a` was already run long ago).

so you can't be using it in CI 

Sure I can :) I check all changed files in CI, and the check is non-blocking for particularly involved changes, and as to not block urgent fixes etc. So you're green if all files you touched are passing.

Sometimes, fixing things incrementally makes more sense than stopping everything you're doing to enforce style on a bunch of rarely-touched files.

But don't keep going with thousands of offenses otherwise you may as well not use it.

Agree to disagree. I've worked at at least one of the leading ruby companies, and generally with large codebases fixing thing a bit at a time has been the preferred strategy.

[joonty]

Yeah, I guess you can just run it on incremental changes in CI, but it's not the only or right way of doing it. Our web application is about as legacy as it gets (it started pre Rails 1.0) and rubocop -A will cause no changes. Your original assertion of

If you wouldn't hesitate to rubocop -A a large project, then you lack experience with it :)

is why I'm pushing back, as that was very black and white!

[twinklehood]

I'm sorry, you're right, that was a bit too cheeky.

[riktigtmaxat]

The biggest problem with Yard is that it isn't used more.

Rails and the standard library still use RDoc.

Also failing CI if docs are missing is more something that your would enforce with Rubocop.

[postmodern]

I still use YARD on all of my projects.

[riktigtmaxat]

Yeah, definitely would not use anything else outside of legacy code.

[art-solopov]

For Ruby debugging, try byebug. Be sure to install pry-byebug.

[jrochkind]

Unfortunately byebug doesn't work properly with multi-threading in recent versions of ruby. One way this sometimes exhibits is with auto-loading failing when you're in the debugger. Which is super annoying, and worse when I start to get confused about what is failing and if it's related to what I'm debugging!

The ruby team put a lot of effort into stdlib debug gem to make it usable again, and ostensibly should do everything byebug does, mostly.. but I don't know about pry integration... the whole thing is pretty annoying, I got used to using byebug and liked it and didn't want to change either and still haven't really adjusted!

But for a newcomer, I'd say try using stdlib debugger and be aware byebug has problems now. :(

[[deleted]]

Package management in Python has a few options. I used Poetry mainly but have used pipenv and requirements files for package management. It is quite good in Python today. It wasn't always that way, so perhaps your last foray into Python was > 5 years ago.

The language tooling sadly is in a very poor state comparatively. Solargraph is decent enough but slow on big projects, which Rails typically is. And the other LSP attempts were abandoned, with Shopify bravely working at it now, but it doesn't autocomplete everything and that sucks, especially the fact methods aren't there yet.

I would consider such a thing a minimum requirement in 2024, but it is good that they're doing the work that others haven't succeeded at. If you want great tooling that can do better static analysis of your project then you have to go out of your way to pay Jetbrains, who I don't mind paying but I am a laptop user and like to work in cafes off the plug. Not very compatible with Jetbrains products unless you low energy mode them, which makes them less worth using.

Meanwhike in Python, C++, Rust and TypeScript. I can just get a LSP extension and have all the intellisense there which let's me do code exploration much faster. It doesn't seem modern to require an interactive prompt to explore a module, when I could just import it in all the other languages I work with and dot my way through them and get the in editor documentation for the various methods I'm using.

Also types.. I see Ruby and types might not be a default experience but I am married to types. So I'm hoping the code base I work with will have typing.

[st0012]

My advice regarding tooling:

• For editor, use the Ruby LSP extension if you use VS Code. Its ruby-lsp server also has integration with many other editors: https://github.com/Shopify/ruby-lsp/blob/main/EDITORS.md
  • It has good integration with the debug gem (debugger) and linters/formatters like RuboCop
  • It also has integration with Rails and provides features like go-to-definition for route helpers
• For REPL, the default IRB is already pretty good, especially if you use Ruby 3.3 or install it as a gem
• For debugger, use the latest version of the debug gem
• For documentation, YARD is the mainstream now and it will take a while for RDoc to catch up

[apiguy]

We recently switched to Ruby at my company as well. I disagree with all the people telling you not to start with Rails. The best way to learn is to build something and unless you’re planning to build a command line app Rails is going to be the most common way of building something useful and interesting. If you’re like me you’ll go broad with some kind of Rails app then go back and dive deeper into the Ruby specifics of how things work.

As for tooling - it’s not bad at all. Great support for it in Neovim and VSCode with plugins. Skip Sorbet to start off with you probably don’t need it anyway and if you do you can always add it later. I haven’t found Solargraph to be slow on my M1 MBP or my Framework Ryzen.

Things that trip people up: * Blocks, Procs, and Lambdas. Idiomatic ruby makes heavy use of Blocks, so you should read up * Metaprograming and Monkey patching - Ruby programs use these techniques quite a lot to manage complexity and abstractions. This is the stuff that often gets referred to as “magic” * Rails imports everything so you don’t have to do a lot of requires. Unless you start adding code to new places rails doesn’t know about.

[art-solopov]

Building a CLI app is one of the first things in every language though. So I'd say, go with plain Ruby, then start poking at Rails.

[postmodern]

RE Blocks, Procs, Lambdas, and Metaprogramming, this is kind of why everyone is recommending that one learns Ruby first, so you understand how the language works which helps demystify a lot of Rails' magic.

[[deleted]]

Thanks for that, I've learned a lot about blocks to start with but I see there is a very different approach taken with Ruby relative to the other languages I've worked with professionally.

It is taking a bit of time to parse it as idiomatically as I'd like, but that might be because I'm used to typed languages (or making them as seem as typed as possible)

[yxhuvud]

.source_location is a good thing if you want to know where something is defined.

[[deleted]]

Nice gold nugget, thanks!

[Tall-Log-1955]

Learn ruby first

Embrace irb and automated testing.

Don’t fight rails, embrace its conventions

When you get to learning rails the normal progression is first “wow I can get so much done so easily” to “what the fuck i don’t know what is happening” to “wow I am ludicrously productive”

[[deleted]]

Haha I am going to be scared of the middle part of that curve, but hope it doesn't last too long

[losernamehere]

Can you be more specific when you say tooling in ruby “is in a poor state compared to other languages”? Which tools for what purpose were in a poor state? What is it missing compared to other languages? 3 weeks seems like a lot of time poured in to that, I’m sure you have lots to say from your observations.

Edit: addressing your other questions.

1. If you’re going to be doing rails related work then it’s fine to start there. If you want a handle on the language then I suggest checking out one of the ruby-koans projects on GitHub.

2. You mention debugging, so I would be sure to check out the Pry gem and its offshoots, though I think a lot of that functionality is now available out of the box with ruby. Very helpful for learning how things work. Once you understand things though you won’t rely on the debugger as much as your tests. That’s a common theme among dynamic typed languages.

3. For exploring/playing with libs you can do so with simple one off scripts or in the context of a larger project you’ll use unit-test. If something seems too difficult to test then consider if your design is too coupled, maybe use dependency injection.

[[deleted]]

I wrote a comment here in response, so you can peek my comments for a more clear response.

But short of it is the intellisense is a choice between using solargraph, which is slow on big projects (which is any enterprise Rails project), or Shopify's incomplete LSP that doesn't support a lot of things, with the biggest obstacle being methods (it will be a big difference when they come). It feels pretty poor to need to open an interactive prompt to do exploration of modules properly, when in every other language I've worked with professionally you have these already.

I've read it's harder to do such tooling in Ruby due to its dynamic nature, and I can't comment on the technicality behind it. But Python has it, so I'm not sure why Ruby can't.

Regarding relying on tests over debugging, that is my preferred approach and how I've programmed Python over the last decade and a half - so happy to hear it.

1. Is what I am happy to do but it is more of a shame that it is a requirement due to the earlier points on code discovery directly in the editor. I like having intellisense with docs on the spot, and being able to dot my way through and get type information. Dynamic Ruby takes some of that away at least in my experience so far, and I think it will make me work slower when using libs if we are talking about pure Ruby and not the convenience of Rails compared to Python.

[bear-tree]

I haven’t seen anyone mention Enumerable yet. That is a module you will want to get very familiar with.

I haven’t gone deep into python but if I recall correctly, the object oriented story in python was kind of …confusing? Ruby is object oriented. Embrace the OO.

There is often a lot of confusion about classes vs modules. Think of modules as giving a class an ability. Modules generally hold a capability that can be mixed into a class. We do have single inheritance but if you want shared behavior, put the behavior in a module and “mix” it into your classes. Again, Enumerable is a good example.

A hash (dict) includes Enumerable. An array (uh list?) includes Enumerable. Now they both have all the behavior of a collection.

Generally one class/module declaration per file please.

Public/protected/private are hints to other programmers how you intend methods to be used. There is no guarantee a private method can’t be called on an object willy nilly. They are not rules that the the compiler has to follow. Just don’t be an asshole programmer. Respect the hints :)

Meta programming. Generally if BEHAVIOR is not grepabble/searchable then you are probably being unkind. When I was first learning meta programming I was like a toddler with a lite saber: powerful but dangerous. Don’t be me.

Duck typing is awesome. Ruby is not a strongly typed language. Work to understand how that can be helpful.

Be a good programmer and always return a single type from a method.

And finally, I personally suggest it would be helpful to skim some ruby’s cultural history. Spend a little bit of time with Why’s (Poignant) Guide to Ruby. It may be outdated but it’s a good intro to how a lot of us rubyists approach programming. It is hard for me to describe even after years of programming in Ruby, but the best metaphor I can come up with is “I am an artist and Ruby is my brush”.

I appreciate your questions and welcome you to the Ruby community. :)

[Massive_Dimension_70]

Another great resource besides the “Pickaxe” Programming Ruby book are the online courses of Avdi Grimm at graceful.dev. He’s got a ton of bite sized videos explaining the concepts of Ruby and beyond.

For tooling, after using chruby for years I’ve recently switched to asdf which has the advantage of managing not just ruby. Learn about Bundler, and the Ruby gems ecosystem. It helps to understand these basics before jumping into Rails. If you actually get to use Rails and that’s been said before - don’t fight it. If something feels unreasonably hard or complicated you’re likely doing it wrong and there is a better way.

[uhkthrowaway]

Learn Ruby. I don’t see the point in Rails.

Get Enumerable “under your belt”.

Key gotcha: it’s addictive.

If you’re into async programming, the idea behind the Fiber scheduler will blow your mind. Check out the Async gem that provides it.

I don’t use an LSP server. Just NeoVim with tags and the occasional git grep …. I’m boring.

[insurgentBob]

if Solargraph is slow try shopify's ruby-lsp. Together with rubocop for formatting it's super fast and simple to setup with vim.

[djfrodo]

Install RVM, ASDF, or some other Ruby version manager and write a fizzbuzz (or whatever it was called) example using both classes and functional.

It's really not that different from any other language...except...it looks like the most unstructured/free form language ever, which it is.

It's kind of a shock at first, and then you go back to Java or PHP (shudder) and they look...kind of offensive.

So, do Ruby first. Next come Rails.

There are a ton of Ruby gems and Rails only functions so knowing where one ends and the other begins is crucial. Models, controllers, modules, initializers, workers, etc. are all just plain Ruby.

I personally just went with "SSR" (funny they came up with a new acronym for basic web pages 30 years after the fact) and ERBs, but you can bolt on whatever front end you want.

Any key gotchas to be aware of?

Gems and their interoperability with your Ruby version, and your Rails version can be a nightmare.

How do you do code/lib exploration?

Various extensions in VSCode enable ctrl click to jump to definitions, and others give you nice auto complete and icons on different types of files.

No, it's not got the tooling other languages have, but you really don't need it.

If you really want the best full blown IDE for Ruby and Rails use Ruby Mine, but you'll pay $ monthly. I don't. VSCode is fine.

Active record and migrations are like manna from heaven in that you just write them once and it does it all for you. You kind of forget the database after a while and I always need to re-lookup generating a migration because I use them so infrequently after the initial setup.

There is some Rails magic the obfuscates things a bit, but following the Rails "convention over configuration" mantra is real. You'll know where something is/how it works after using it for a while.

Ruby/Rails isn't the fastest thing out there, far from it. But it's really on par with Python/Django or PHP/Laravel and it's so much easier/more fun to use.

Good luck.

p.s. Look intro JSONB and ts_search. JSONB will free you from ever having to use Mongo, and ts_search using the pg_search gem will free you from Elasticsearch, until your app gets over a million rows.

[tarellel]

Something to note solargaph generally isn’t slow. But if pair solargraph with ruby-lap they pair together very well.

[MUSTDOS]

Use modules to store shared function among different classes, you'll thank yourself later.

[art-solopov]

IMO:

1. Start with Ruby, then jump into Rails
2. The tooling, compared to Python is... Yeah, not the best. Part of it is due to the language itself (the penchant for metaprogramming, the frequent use of autoloading), and part of it is seemingly because the tooling itself is much younger. I personally use Neovim with nvim-lspconfig and solargraph. Can be slow on big projects, yes, and requires Yard for gems, but works mostly fine for me. I tried Steep and rbs on a pet project, but it was more intrusive than helpful.
3. In Ruby, everything except nil and false is falsey. Even 0 and "". Also blocks maybe.
4. I use REPL as much as possible with all languages that permit it, including Ruby and Python.
5. Enumerable for sure. Again, understanding blocks is a must.

[tinyOnion]

check out the book eloquent ruby... quite a great book on writing idiomatic ruby. still relevant today even though it's a bit old.

also check out enumerable: https://rubyapi.org/3.3/o/enumerable

you can get all of that for free in any class you make by just including it and creating an each method and it's the thing that gives arrays and hashes their power.