Give it a try. The languages are actually very similar, on roughly the same level of "high-low-level-ness", they both come batteries included, both are very mature and refined.

Some things you may find nice are: the elegance and ease of use of blocks instead of explicitly declared lambdas, the standard library full of nicely named methods with aliases for the most used ones (e.g. array.map / array.collect do the same thing, some people hate this), the {do,if,case,loop}-end syntax that doesn't fuck your code up when you just quickly comment these parts out without reindenting the rest, and if you're into OOP (as in OOP, not explosion-in-the-factory-factory), then of course the hardcore OOP-ness.

Depends on your use-cases - Rails is unparalleled in my opinion for getting a web app up and running, testing startup ideas, and building quickly in response to customer feedback.

I've been using Python recently as I've done more ML work, and I do prefer Ruby (though the syntaxes are similar and you won't have any difficulty).

If you learn for Rails, start with 5.2.3, webpacker and the other black magic in Rails 6 will frustrate you and currently eliminates a lot of the ease of getting started and building relatively sophisticated web apps quickly.

"If you learn for Rails, start with 5.2.3, webpacker and the other black magic in Rails 6 will frustrate you and currently eliminates a lot of the ease of getting started and building relatively sophisticated web apps quickly."

Anyone else agree with this?

Nope.

Webpacker is here to stay and takes about 5 minutes to understand. Might as well take advantage of it so you can quickly add complex front end components via React or whatever flavor of FE you prefer.

I agree, webpacker makes learning Rails harder. It's a shame. But learning on a non current version is a short term solution. A good tutorial, like Michael Hartl's, will get you over that hump.

I'm learning rails 6 right now for a work project, and webpacker is just broken so I can't even get hello world to work.

I'd go with something that has static/strong types when picking a new tool. Not saying I dont love Ruby, but when the codebase/team becomes large i've always regretted not having strong type safety. Today I'd go with Kotlin.

Try rails you won't look back

I tried (am trying at current company) and still don't like it. I completely see the appeal for getting an idea up and running quickly, it absolutely delivers on that.

However, I joined a rails company about a year ago and the codebase is just a mess at this scale. I find it annoying that in order to know where dependencies are coming from, I can't just go to the top of the file and see what's imported. I have to know how rails injects it and then track it down from there.

Don't get me wrong, there are issues with django, Go, etc.. but for the most part I can jump in and track down what's happening much easier.

Now, Ruby itself isn't bad at all.

Yeah, that's gotta be one of my biggest complaints after years of working with Rails. Eventually you sort-of memorize the conventions and can relatively accurately guess where a file lives, until someone decides to get clever and put things in a weird place.

It also implicitly discourages you from asking yourself if you should be accessing the thing you are. IMO a lot of the tight coupling in Rails codebases begins with being able to grab literally anything and use it with no one the wiser unless the read that specific line of code.

I love Ruby. Have used it for 15 years, but I can't stand Rails. It's just massive overkill for most things.

I prefer to start with Sinatra + Sequel for web projects. Sometimes Padrino + Sequel. As your project grows, sure, you'll pull in many things similar to Rails, and probably pull in some projects that started out with Rails too, but it allows you to be much explicit about which dependencies you pull in, why, and to limited where it gets pulled in.

I have not tried Sinatra, only heard good things about it I will check it out. Thanks!

Sinatra is great - it's small enough to read the whole thing and understand it. But it's also very minimalist, so you might also want to look at Padrino, which layers neatly on top of Sinatra, yet is still small and ORM agnostic.

It's also fairly painless to start with Sinatra, and layer in components from Padrino if/when you need them. E.g. you can simply register Padrino's helpers, mailer, routing, rendering or cache components in a Sinatra app if/when you need them. They're just straightforward Sinatra plugins.