5 ms·

I was programming Rails during the Heyday. I don't miss it one bit. Yes, you can build things quickly, "rails g scaffold" was quite a tool. But the level of d

I was programming Rails during the Heyday. I don't miss it one bit. Yes, you can build things quickly, "rails g scaffold" was quite a tool. But the level of discipline required to keep a large Rails codebase from turning into spaghetti is not to be underestimated. Plus, because of Ruby's flexibility, a bunch of functionality is sort of "magic pudding" and happens via extension and meta-method sort of things. This makes things like Ctrl+Click being the source of truth and being able to generate some sort of ERD-diagram in your IDE of everything that touches another thing difficult to implement. I also don't miss dynamic types in the slightest. Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though.

winrid 3y ago
you can use Django (python) with Types and the codebase will scale a bit larger, there are JITs available for Python too. ctrl+click works great can write simple Python code and not do anything crazy, works alright. up to around 30k lines I'd probably consider past the "prototype" phase though and would prefer a compiled language.
megraf 3y ago
I would say Rails is still in its Heyday. I've been writing ruby since 1.8.7 and I'm constantly surprised by the frequency of major releases of rails, and the backward compatibility (Rails 3 -> 5 was hard). I completely agree about the discipline required to keep a large project clean, although I find that true across the board with large codebases.
qudat 3y ago
I totally agree. The fact that it's not possible to determine the location of a method being called inside a file until it is run perfectly illustrates the problem with a hyper-dynamic language like ruby. It's a dream for people who love metaprogramming to do things magically, but a nightmare for anyone later inheriting that project. I have a rant about it: https://bower.sh/on-autoloading https://bower.sh/on-autoloading And don't get me started on the footgun that is ActiveRecord callbacks: https://guides.rubyonrails.org/active_record_callbacks.html https://guides.rubyonrails.org/active_record_callbacks.html
ecshafer 3y ago
I didn't program RoR when it was hot, but I am in a RoR shop now. RoR is by far the easiest framework to jump into an existing project and find what is going on that I have seen, if anything its the opposite of hard to not turn into spaghetti. Comparing this to Spring, React, Node, ASP, etc. I would much rather do Ruby.
AlchemistCamp 3y ago
> Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though. Why wouldn't you look at Phoenix LiveView, which inspired Laravel's Livewire, then? Elixir also gives you some other advantages you likely haven't encountered before if you haven't worked with Erlang or Akka.
gregors 3y ago
I actually agree about large RoR codebases, the last few major ones I've seen were absolute dumpster fires and the solutions implemented to fix them, was more or less standard enterprise java patterns. So you ended up doing java anyway. On the other hand, I'd say Elixir/Phoenix gives you exactly what you want these days and especially with the gradual type system, non-magic database ecto layer etc.

winrid 3y ago

you can use Django (python) with Types and the codebase will scale a bit larger, there are JITs available for Python too. ctrl+click works great can write simple Python code and not do anything crazy, works alright. up to around 30k lines I'd probably consider past the "prototype" phase though and would prefer a compiled language.

megraf 3y ago

I would say Rails is still in its Heyday. I've been writing ruby since 1.8.7 and I'm constantly surprised by the frequency of major releases of rails, and the backward compatibility (Rails 3 -> 5 was hard). I completely agree about the discipline required to keep a large project clean, although I find that true across the board with large codebases.

qudat 3y ago

I totally agree. The fact that it's not possible to determine the location of a method being called inside a file until it is run perfectly illustrates the problem with a hyper-dynamic language like ruby. It's a dream for people who love metaprogramming to do things magically, but a nightmare for anyone later inheriting that project. I have a rant about it: https://bower.sh/on-autoloading https://bower.sh/on-autoloading And don't get me started on the footgun that is ActiveRecord callbacks: https://guides.rubyonrails.org/active_record_callbacks.html https://guides.rubyonrails.org/active_record_callbacks.html

ecshafer 3y ago

I didn't program RoR when it was hot, but I am in a RoR shop now. RoR is by far the easiest framework to jump into an existing project and find what is going on that I have seen, if anything its the opposite of hard to not turn into spaghetti. Comparing this to Spring, React, Node, ASP, etc. I would much rather do Ruby.

AlchemistCamp 3y ago

> Nowadays, I would rather look at Laravel with Livewire and Alpine.js if you want something Rails-esque. PHP is godawful though. Why wouldn't you look at Phoenix LiveView, which inspired Laravel's Livewire, then? Elixir also gives you some other advantages you likely haven't encountered before if you haven't worked with Erlang or Akka.

gregors 3y ago

I actually agree about large RoR codebases, the last few major ones I've seen were absolute dumpster fires and the solutions implemented to fix them, was more or less standard enterprise java patterns. So you ended up doing java anyway. On the other hand, I'd say Elixir/Phoenix gives you exactly what you want these days and especially with the gradual type system, non-magic database ecto layer etc.