Is there any effort to make WASM run under Ruby? Seems like easy work to get high performance without bespoke work on Ruby's VM.
Reducing Memory Usage in Ruby
51–58 of 58 posts
Re: Reducing Memory Usage in Ruby
#52Re: Reducing Memory Usage in Ruby
#53What I'm really keen to see is truffleruby receiving a lot of community support. The underlying JVM and the Truffle/Graal/SubstrateVM is the product of millions of man hours of research - and for the very first time, you have a compiler framework on top of that. The Truffle framework also brings in a lot of support that all languages get for free, like zero overhead profiling https://twitter.com/nirvdrum/status/94833…
The major obstacle right now is C extension, which I think Sulong [1] is suppose to solve.
It seems right now, TruffleRuby 99% of Ruby code without much problem. C Extension may be the key to wide spread adoption.
Re: Reducing Memory Usage in Ruby
#54Earlier quoted context omitted.
Yeah use Ruby. I prefer to have well defined interfaces for the objects I use. I love Ruby to death, but it's frustrating to encounter code like this: [:thing, :other_thing].each do |msg| define_method(msg) do @json[msg].to_s end end When this is far more clear and, for me, aesthetically pleasing: def thing @json[:thing].to_s end def other_thing @json[:other_thing].to_s end I'm not sure how you'd use a ruby object th…
The example in question is perfectly possible to do in Crystal during compile-time, using macros. What isn't possible is to create a new class on the fly as a sort of magic lookup table that magic methods is called upon. Good riddance, for that functionality.
For the sake of this example, consider [:thing, :other_thing] to be dynamically created at runtime.
Re: Reducing Memory Usage in Ruby
#55Earlier quoted context omitted.
See GraniteORM or my crystal-mongo-orm. You just have to specify your fields at compile time and you are good-to-go. It works just like active record. https://github.com/amberframework/granite-orm https://github.com/sam0x17/crystal-mongo-orm
"You have to specify your fields at compile time" is exactly not like ActiveRecord, though. That's exactly the downside to it for doing ActiveRecord. At that point, you may (should) just use an object mapper like ROM that has no model-class hooks at all. (Which I actually like. But the Rails world disagrees.)
You effectively do specify your fields before runtime in Rails, though, in the form of your migrations. Furthermore all of the associations (belongs_to, etc), are arguably also specified before runtime since those helpers run when the class is parsed.
Re: Reducing Memory Usage in Ruby
#56Earlier quoted context omitted.
Got me there. First time I've ever in my life heard of a legitimate example where you really do need dynamic methods.
If the problem is stated as you want a dynamic class to create instances where you call dynamic methods, then yes you need Ruby. However, that is basically a lookup table using string based dispatch to decide what to execute, and such a lookup table can be done in anything.
Crystal "does" have dynamic methods if you are willing to override method_missing.
Re: Reducing Memory Usage in Ruby
#57Earlier quoted context omitted.
If the problem is stated as you want a dynamic class to create instances where you call dynamic methods, then yes you need Ruby. However, that is basically a lookup table using string based dispatch to decide what to execute, and such a lookup table can be done in anything.
Crystal "does" have dynamic methods if you are willing to override method_missing.
No, the dispatch is still decided during compilation.
Re: Reducing Memory Usage in Ruby
#58Earlier quoted context omitted.
"You have to specify your fields at compile time" is exactly not like ActiveRecord, though. That's exactly the downside to it for doing ActiveRecord. At that point, you may (should) just use an object mapper like ROM that has no model-class hooks at all. (Which I actually like. But the Rails world disagrees.)
You effectively do specify your fields before runtime in Rails, though, in the form of your migrations. Furthermore all of the associations (belongs_to, etc), are arguably also specified before runtime since those helpers run when the class is parsed.
I frequently don't use Ruby-based migrations. I use datastores defined elsewhere and use Sequel as a convenient and easy interface for tasks against those datastores.
You're trying to slice too fine. Crystal can't do this. That's OK. Own it, don't try to hide it.