Those are fair points, but I just kind of hold the entire program space in my head. I work on a pretty large and complicated Rails app that does real world things (handle money, deal with people and companies, etc) and it's daunting at first but after a while it's sort of become one big system of objects interacting with other objects in a global objectspace and that's how it exists in my head.
I think for people that come to love Ruby it feels more natural to think about a program that way as opposed to thinking about a purely lexical context of a piece of code.
I think this is actually a very efficient way of programming. but it doesn't scale in project size and team size. Similar for Lisp. This is why these languages are really good for prototyping, but not as good anymore for big, longterm projects imho.
That's also why I don't think it's a great idea to add types etc. to programming languages like python or ruby. They are not made for this and they should focus on what they do well. Use the right tool for the job, don't try to make every tool being able to be used for the same task.
This is just not true. There are several multi-Billion dollar public companies with millions of users and thousands of employees built on Rails.
In fact, the philosophy of convention over configuration et all makes Rails MORE scalable and easier to onboard new people than anything else out there that I’ve seen.
I agree, the convention means there are very straight-forwarded places to look for things
I recently worked on a Rails project for someone who didn't like to create scaffolds, models or controllers for small things, thinking that it would add to the bloat. But conceptually it makes everything 10x times easier and faster to find and understand
Depends on your definition of major.
For a company to become a unicorn it usually takes 7 years (not sure on the number but it keeps changing). So many companies formed in 2015,16...+ aren't there still. Looking in Linkedin for Rails jobs there are a lot, not all of them are old companies.
Gitlab is a very famous name(2014) but it too IPO'ed so it's not a startup anymore.
Which isn't to say lexical scope isn't important in a ruby program -- it's paramount, especially for resolving constants -- it's just that after a while it's not that big of a deal that there is some ambiguity about where things come from. For me it's one of the most intuitive languages I've ever worked with but it requires a sense of intuition that is learned over time, as contradictory as that sounds.
It also requires a certain sense of confidence that whoever named that method you're calling gave it a good name. Fortunately (and not, I think, coincidentally) the ruby community has always tended towards good naming being really important.
I think for people that come to love Ruby it feels more natural to think about a program that way as opposed to thinking about a purely lexical context of a piece of code.