An OpenStruct is slower than a hash, but then again, an OpenStruct is kind of pointless.
If the reason not to use better principles is because Ruby makes them painful, rather than there's something about the domain that makes them a bad idea, why choose Ruby to begin with? Presumably the ecosystem.
I agree with emphasizing caution, but I definitely think it's worth being at least somewhat weird with your Ruby to get as much as you can from the best of both worlds, the Ruby ecosystem and functional principles.
It requires a good knowledge and dedication to consistently return a new object (not mutate state). Further, chaining is problematic for tracing errors because so much happens on a single line. Ruby has many subtle features that can bite you in the ass.
Don't get me wrong, I LOVE RUBY, I would love these paradigms to be better suited (rbx/jruby come close). I just find if I embrace mutability, state, and OO principles in Ruby I am rewarded in quality by having other smart people who are more easily able to critique my code and better it.
The abstraction I (completely willing to admit being wrong/stupid) don't believe is worth it. I think less effort and more reward can be had using the right tool for that job. I, for what it is worth, came to my conclusion through the pain of trying.
I generally agree with the rest of your comment though, however I think some ruby code (per the original post) can be improved by introducing some of these paradigms.
And immutable structures with efficient "updates". Because otherwise every time you're altering the structure you have to copy it in full (though shallowly) then mutate it in place.
Not that I don't wish we could swap tired old Java for Scala at work, but I worry that opt-in immutability means somebody will opt-out and foul things up in Scala, as well :-(
For languages (e.g. - Scala, Nim) that have separate keywords for declaring/initializing immutable and mutable symbols, I wish they would avoid short words like "var" for mutable identifiers, maybe using a keyword like "mutable", "datadivision" or "ipeedinthepool" to discourage mutable data.
1.) A struct in ruby isn't just data, it is an object.
2.) Structs come with some weird gotchas, most notably that it is an Enumerable!
3.) It's generally better to use a hash (in ruby) if you want "pure" data object (and they at least used to be faster).
I myself have written a lot of "weird" Ruby and I will say that more often than not it's detrimental to an application that is used/developed by others. Often times ideas that seem brilliant in one language, cannot be translated into another (immutability), and it's best to use the recommended paradigms. Especially when those using the software are not familiar with them, and most likely won't become familiar with them....
For me, many functional paradigms are just lost on ruby because it's so highly mutable that practicing them is more academic than practical (sadly). That's why I write Scala or Elixir now when I want/need those paradigms-- because they're the right tools for that job.
I definitely don't want to discourage innovation, or bringing great ideas to ruby from other places-- I just want to emphasize caution :)