4 ms·

I'm going to have go push back on this. I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspect

I'm going to have go push back on this. I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective. I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster. What you're saying here is true in theory, but what you're not telling people is how the community is about as close to the attitude of npm as you can get on the server side. hundreds of gems on your typical application, many of which are used in 1 or 2 places, helping avoid a grand total of less than 5 lines of code. Then there's the ratwheel you opt into with rails. Every single damned time I find myself having to manually patch libraries to get it working properly. I even once had to track down an old Ubuntu image of a version that had EoL'd 5 years prior and THEN had to manually patch a few C dependencies just to get it to build and run. Don't even get me started on wkhtmltopdf, fuck that dependency. If you use that in your RoR project, fuck you. ^ that's only partially meant to be humourous. My experience is that developers suggest RoR then run off into the sunset on their new project, leaving companies not understanding that they're now on a ratwheel of maintenance and upgrades until it's so bad only someone such as myself even has the skillset necessary to pick up the pieces. Contrast this with asp.net core. Each LTS version is supported for 2 years (which is too short imo), but more importantly, you can install the EOL versions just fine. I would never recommend RoR over asp.net core (asp.net 6+ ... LTS only) because developer productivity isn't worth the maintenance cost.

neonsunset 3y ago
.NET's LTS releases are supported for 3 years and STS are supported for 18 months. I wish LTS support was 5 years, it seems like ecosystem has matured enough post-going-OSS-wild-ride starting with .NET 6 release and is ready for such a support timeframe. Or at least they could have every other LTS be ELTS? Also, I do wonder if RoRs perceived productivity is by inertia? I have a hard time believing you can top the productivity of quick scaffolding for back-end you get circa .NET7-8?
- PH95VuimJjqBqy 3y ago
  you're right, looking closer I got my wires crossed. non-LTS is 2 years, LTS is 3 years https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core https://dotnet.microsoft.com/en-us/platform/support/policy/d... imo, short term RoR will beat the pants off asp.net core in terms of developer productivity. mid to long term asp.net core wins hands down in terms of developer productivity. I don't think the RoR productivity story is fake, but I do think it's not worth the long term maintenance costs.
- evntdrvn 3y ago
  On the flip side, within the last few years, upgrading .NET versions has become typically a very easy exercise. The ASP.NET team tends to churn stuff wayyy more often than I'd like for questionable reasons, which can make keeping more painful than I'd like - but tbh I often just keep using the older ways of doing things in ASP.NET since it's almost always still supported...
  - PH95VuimJjqBqy 3y ago
    I do think .net moves faster than it should (faster than it used to for sure) but I assuage that worry with the fact that you can still install .net framework 1 and it'll work.
block_dagger 3y ago
I think you have encountered some projects built by undisciplined teams. That is not a reflection on the framework, rather a reflection on the people improperly using it.
- PH95VuimJjqBqy 3y ago
  while that's true and obviously you can avoid these problems with any framework with enough discipline, my point is that the community in general isn't disciplined. I've repeatedly seen the same things over a 15+ year timespan.
  - awwaiid 3y ago
    Maybe people only need to hire you when they have problems, and the ones where things went well don't need your help?
- mattgreenrocks 3y ago
  The culture encourages a lack of discipline; indeed, high framework coupling is seen as the Rails way.
  - ric2b 3y ago
    Framework coupling sure, but that has little to do with adding other random dependencies. Also why would you be afraid of coupling to the framework? It's not like you're going to be able to change the framework after the project grows, anyway.
    - mattgreenrocks 3y ago
      For all the complaints of slow tests, the Rails community is reluctant to decouple from the framework, which is the root cause of the issue. To me, that is lack of discipline: choosing the framework way (e.g. tribal identity) over engineering integrity. It may be that slow tests are just easy to complain about, and there isn't much business value in doing that. Totally fine. But, other things come to mind: weird cottage industry of gems that did dubious things to speed up tests (and were prone to breaking), the skepticism around interactors, the hegemony of active record (the pattern). None of those are bad things, but they reinforced the fact that the technical values of the Rails community do not work for me.
mattgreenrocks 3y ago
Perfect storm of dynamic typing, needing to keep up with breaking changes, thought leaders that thought leader too much, and a community that seems to push back on anything that calls into question The True Rails Way.

neonsunset 3y ago

.NET's LTS releases are supported for 3 years and STS are supported for 18 months. I wish LTS support was 5 years, it seems like ecosystem has matured enough post-going-OSS-wild-ride starting with .NET 6 release and is ready for such a support timeframe. Or at least they could have every other LTS be ELTS? Also, I do wonder if RoRs perceived productivity is by inertia? I have a hard time believing you can top the productivity of quick scaffolding for back-end you get circa .NET7-8?

PH95VuimJjqBqy 3y ago
you're right, looking closer I got my wires crossed. non-LTS is 2 years, LTS is 3 years https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core https://dotnet.microsoft.com/en-us/platform/support/policy/d... imo, short term RoR will beat the pants off asp.net core in terms of developer productivity. mid to long term asp.net core wins hands down in terms of developer productivity. I don't think the RoR productivity story is fake, but I do think it's not worth the long term maintenance costs.
evntdrvn 3y ago
On the flip side, within the last few years, upgrading .NET versions has become typically a very easy exercise. The ASP.NET team tends to churn stuff wayyy more often than I'd like for questionable reasons, which can make keeping more painful than I'd like - but tbh I often just keep using the older ways of doing things in ASP.NET since it's almost always still supported...
- PH95VuimJjqBqy 3y ago
  I do think .net moves faster than it should (faster than it used to for sure) but I assuage that worry with the fact that you can still install .net framework 1 and it'll work.

block_dagger 3y ago

I think you have encountered some projects built by undisciplined teams. That is not a reflection on the framework, rather a reflection on the people improperly using it.

PH95VuimJjqBqy 3y ago
while that's true and obviously you can avoid these problems with any framework with enough discipline, my point is that the community in general isn't disciplined. I've repeatedly seen the same things over a 15+ year timespan.
- awwaiid 3y ago
  Maybe people only need to hire you when they have problems, and the ones where things went well don't need your help?
mattgreenrocks 3y ago
The culture encourages a lack of discipline; indeed, high framework coupling is seen as the Rails way.
- ric2b 3y ago
  Framework coupling sure, but that has little to do with adding other random dependencies. Also why would you be afraid of coupling to the framework? It's not like you're going to be able to change the framework after the project grows, anyway.
  - mattgreenrocks 3y ago
    For all the complaints of slow tests, the Rails community is reluctant to decouple from the framework, which is the root cause of the issue. To me, that is lack of discipline: choosing the framework way (e.g. tribal identity) over engineering integrity. It may be that slow tests are just easy to complain about, and there isn't much business value in doing that. Totally fine. But, other things come to mind: weird cottage industry of gems that did dubious things to speed up tests (and were prone to breaking), the skepticism around interactors, the hegemony of active record (the pattern). None of those are bad things, but they reinforced the fact that the technical values of the Rails community do not work for me.

mattgreenrocks 3y ago

Perfect storm of dynamic typing, needing to keep up with breaking changes, thought leaders that thought leader too much, and a community that seems to push back on anything that calls into question The True Rails Way.