3 ms·

The usual amount of snarkiness I've come to expect from the Ruby community. What a smarmy tweet: "Lol 20 something developers using new tools when they could j

The usual amount of snarkiness I've come to expect from the Ruby community. What a smarmy tweet: "Lol 20 something developers using new tools when they could just use this ancient slow dynamically typed OO language I allied myself with doing the exact same thing 10 years ago" Ok I'll bite: - Because it had it's milkshake drunk by nodejs which has better support for modern front end workflows and great languages like typescript built in top of it. And is faster and better supported. - because it's slow and difficult to scale - because it has years and years of baggage - because I prefer elixir it golang or rust or Scala - because it's not a perfect fit for every project - because I do not like stateful object oriented languages with magic so I can trust my intern and Jr devs to write something decently maintainable

jrs95 8y ago
1. Node on the server does not have a comprehensive framework that compares to rails. You'll roll your own, and it will suck. 2. It's not any more difficult to scale than Node, you'll just need more servers to handle the load. Horizontal scaling works basically the same for both platforms. 3. Well understood baggage is better than baggage only a handful of people in your company know about as a result of your custom web framework. 4/5 of course nothing is a perfect fit for every project and everyone has their preferences, but this can be said for any language or platform so it's sort of a non argument. 6. Good luck finding interns and junior devs who can be productive writing in some esoteric functional language.
stevebmark 8y ago
extend ActiveSupport::Concern attr_accessor :foo class << self included do def method_missing(name) do define_method(:after_save) do |bar| ... end end end end What do you mean? This stateful, first class mixin OO metaprogrammed magic, implicitly globally mixed in to your application, makes it super easy to understand the flow of your application and the capabilities of your system. It's also super easy to see where things are defined, and the structure of methods/classes/object doesn't depend on luck / the order your program _executes_ in! Fat models are the way to go, there's obviously no problem with stateful mixins to "separate" model logic and make sure your model can do absolutely everything, because what is data, really? Perfect for junior and senior devs alike. edit: I forgot to include `method_missing`, which definitely isn't a design flaw, and there's absolutely no fundamental community problem that Ruby developers don't see any problem with using it.
- eximius 8y ago
  This is sarcastic right? I really can't tell. And you either deserve and upvote or a downvote and I can't tell which because of it.

jrs95 8y ago

1. Node on the server does not have a comprehensive framework that compares to rails. You'll roll your own, and it will suck. 2. It's not any more difficult to scale than Node, you'll just need more servers to handle the load. Horizontal scaling works basically the same for both platforms. 3. Well understood baggage is better than baggage only a handful of people in your company know about as a result of your custom web framework. 4/5 of course nothing is a perfect fit for every project and everyone has their preferences, but this can be said for any language or platform so it's sort of a non argument. 6. Good luck finding interns and junior devs who can be productive writing in some esoteric functional language.

stevebmark 8y ago

extend ActiveSupport::Concern attr_accessor :foo class << self included do def method_missing(name) do define_method(:after_save) do |bar| ... end end end end What do you mean? This stateful, first class mixin OO metaprogrammed magic, implicitly globally mixed in to your application, makes it super easy to understand the flow of your application and the capabilities of your system. It's also super easy to see where things are defined, and the structure of methods/classes/object doesn't depend on luck / the order your program _executes_ in! Fat models are the way to go, there's obviously no problem with stateful mixins to "separate" model logic and make sure your model can do absolutely everything, because what is data, really? Perfect for junior and senior devs alike. edit: I forgot to include `method_missing`, which definitely isn't a design flaw, and there's absolutely no fundamental community problem that Ruby developers don't see any problem with using it.

eximius 8y ago
This is sarcastic right? I really can't tell. And you either deserve and upvote or a downvote and I can't tell which because of it.