[tolmasky]

Maybe its because I'm a JavaScript dev, but I seem to clearly understand the critique (vs maybe if you are a Ruby dev it just sounds like "I don't like it"): too many built-in methods, lots of magic behavior, and an over-reliance on syntactic sugar. Seems pretty straightforward.

Possible non-code-altering solutions to the problems include: 1) limiting educational material on Rails to only use a subset of the built-in methods so that newcomers aren't overwhelmed by feeling they need to learn the entire std library before being able to make progress, 2) Using more explicit versions of code vs the more terse but harder to understand versions enabled by syncretic sugar to ensure that people coming from other languages first understand what is going on, then are blown away when they discover you can write it in an even cooler way, 3) a deeper explanation of what is going on under the hood to make the magic seem "OK".

[aeze]

I considered it an "I don't like it" post because aspects that the top level poster described are intentional features, not problems or issues that need to be fixed (at least according to DHH & co).

And I guess the word 'critique' connotes a somewhat more detailed, analytical assessment - at least to me.

[tolmasky]

I guess the perspective difference comes from having run and worked in open source myself in the past: its a better strategy to try to understand the pain point the user is facing regardless of how "analytical" the assessment is. A lost customer is a lost customer, and in this particular case, this seems to be a common critique. Given that the critique attacks as you say intentional features, that's why my mind went directly to the problem of education of the features. Perhaps this class of use is a lost cause: or perhaps this reflects a gap in the learning curve that could be strengthened.

[aeze]

Fair enough. There are great resources available like https://rebuilding-rails.com/ which should receive more attention, IMO.