I had this exact realization getting ramped up in a large rails codebase: ruby is optimized for experience of the code author, while most of the things people miss from it (explicit imports, static types) help with code maintenance and codebase scalability.

The small/large project distinction makes sense to me. I think there’s a clear point in project size where the joy of writing code has to be deprioritized behind maintainability and simplicity, even if it becomes less fun to write code that way.

It's not a pleasant experience to come on board and deal with a typeless, styleless, inconsistent mess. And that's what Ruby on Rails will create, unless you spend an inordinate amount of effort on adding back all the tooling you need to make functional software in large groups.

Even then - there's no real path to a mature and maintainable language/framework. In my area (Atlanta) we're seeing a glut of RoR devs available because a lot of the large employers have given up and shut down the RoRs projects in favor of anything more suitable to teams in the 15 to 500 engineer range. Usually this has been typescript/java/.net.

Even within the RoR guys I know - a LOT of them are trying to get out and work with something else (several folks I know are moving to elixir)

> a LOT of them are trying to get out and work with something else (several folks I know are moving to elixir)

Dumb move, Elixir has around 1000 job openings in the U.S while Ruby has 35000. In fact I find it pretty hard to believe they can't get a Ruby job in the U.S, and they choose Elixir from all stacks as a solution to their problem. Sounds to me like they just wanna try Elixir and can't really build a good argument in their head on why they're doing it. Jobs-wise things are definitely not gonna be easier for them with Elixir.

I agree. Elixir is just too obscure.

>Even then - there's no real path to a mature and maintainable language/framework.

Hopefully that is what Github and Shopify brings to the table. Instead of just using Rails they are now actively shaping its future direction.

>because a lot of the large employers have given up and shut down the RoRs projects

My impression is that the vast majority of Rails communities don't care much about its ecosystem growth. They are just happily using it.

This has been my experience. I gave into learning Ruby and how things can be written several different ways. Even when tools like Rubocop and the like are used it still can result in a codebase that is very difficult to use.

My opinion, typed/tooled is useful when the desired solution/behavior/concept is complex.

Elixir is also dynamically typed but due to its pattern matching and immutability, I've found it eliminates about 90% of the issues that I've found with dynamic typing in other languages.

It's still got most of what made Ruby a joy to work with and several unique advantages, too!

Lots of people complain about Elixir's lack of types and possible incomprehensible mess caused by Macros. It kinda proves to me that everyone has different tastes in software and that's about it, there is no objective truth to any of it. For me Java code is a nightmare.

> I think there’s a clear point in project size where the joy of writing code has to be deprioritized behind maintainability and simplicity, even if it becomes less fun to write code that way.

I completely disagree. Joy of writing code must always be a top priority, also in large codebases. There are enough examples of where Ruby (on Rails) is used in large codebases with GitHub, Shopify, etc.

I guess it's a matter of personal match, too. Some people match better with TypeScript, others better with Rails. Nothing wrong about that.

I'm aware that they use a heavily modified version of Rails, but it still is Rails in the fundament.

Gitlab, Discourse, Mastodon, Forem (dev.to) etc etc. All are big OSS software and are maintainable and seem to have quite a high velocity feature development. If it was an unmaintainable mess the whole opens source thing wouldn't have worked as well as it does for them. So maybe we should steer the debate towards - it CAN be done (as you can see) but it's more difficult with Rails (which I think is false).

Well, sometimes joyfully written code can be less than joyful for those who have to read & maintain it…