For example: I mean, you can monkeypatch anything (including _Object_) at runtime. You can use this to make 1 + 1 = 3, if you desired, or to add a method to all instances of any class currently instantiated. Want your database to respond to .fuckoff(), no problem..
This kind of stuff is also how rspec (used to?) actually run tests.
It's cool, but also pretty insane.
irb(main):001:0> class Object
irb(main):002:1> def fuckoff
irb(main):003:2> "lol"
irb(main):004:2> end
irb(main):005:1> end
=> :fuckoff
irb(main):006:0> 5.fuckoff
=> "lol"
irb(main):007:0> "Hello World".fuckoff
=> "lol"
irb(main):008:0>The bad thing is that this is often abused horribly, I blame the Rails ecosystem with its "just add this gem to the Gemfile and it will magically change your application" attitude.
https://kotlinlang.org/docs/extensions.html
https://docs.scala-lang.org/scala3/book/ca-extension-methods...
In Ruby, however, there is no concept of an import. You can require other files but this is transitive. So if something anywhere in your chain of dependencies is defining a new method on String, or Object, it's available everywhere. Plus, in Rails usually you don't even have to require anything, as the framework magic does that for you.
The fact that there is no proper import/module system is easily one of my most disliked features about Ruby, it makes it incredibly hard to understand where things come from.
Also, Ruby doesn't only allow you to add new behaviour to existing classes. It also allows overriding existing methods. And that suffers from the exact same problems, i.e. it could be in some transitive dependency, and suddenly your strings will be doing things you didn't expect them to do...
F fuckoff(x) "lol"
echo(5.fuckoff())
echo("Hello World".fuckoff())But you get optional typing too for speed
I guess I was trying to describe the frustration of switching languages and ecosystems while also trying to ship, thought I could do it, but I couldn’t.
I suppose I would have had a much better time and stayed in C-land (and gotten much better performance) if I had tried golang instead of clojure.
I switched to the JVM because I was annoyed enough at the things I had to deal with in Ruby that learning how to do things in a new way was worth it for me in the long run.
> I suppose I would have had a much better time and stayed in C-land (and gotten much better performance) if I had tried golang instead of clojure.
But Go is a completely different language than Clojure? By what criterion are you deciding which language to focus on? Mostly I'd think that people who choose Clojure do so because they want to use a homoiconic, dynamically typed, functional programming language and not something that looks a lot like a cleaned-up C.
Ruby (and rails) for web applications is very hard to beat ergonomically.
Go also feels this way to me, the development experience is very simple, deployment is even easier than ruby/rack (assuming no docker), and you get the added bonus of using a lot less memory on the server.