Rhizome – A pedagogical example of a JIT for Ruby, implemented in Ruby
github.com
github.com
In the past, I've tried looking in the past of the repo and trying to make maps of the dependencies between different files over time, to better understand which classes or types are the most widespread. In dynamic languages, I really don't know how I'd start, I'd probably just see how it's invoked and start depth-first from there.
For non-rails web apps (and rails apps), I'll usually find a portion of the UI and just start tracking from the front-end to the back-end. Something like finding some text on the page, and trying to reverse back to where that particular piece of text was defined and what steps it took to get there (which view, helper, controller, etc.)
For non web-apps, I don't have any good techniques, unfortunately.
For database-driven applications, that means, read the DB schema first. For everything else, look at their in-memory equivalents.
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus Torvalds (2006)
- earliest committed files
- most recently committed files
- tests / examples folders
If it's a popular library, I also go to github and search for "import <library name>" and go to the code results, and look at a few examples of files from different projects that use that library to see how it can actually be used
Chris Seaton is one of the most influential programmers out there for me. I'm so interested in just about everything he's touched. What a guy. Ruby will never die so long as people have ideas like his, though not all can follow through and create such cool things!
I'm curious to see where performant ruby goes in the midst of Crystal. I quite like Ruby for exploring, Pry is an unrivalled repl experience, but then Crystal is very fast and quite efficient for big things. I like the idea of types guiding me amongst a big large codebase that I might not be familiar with.
We'll just have to keep hacking and see what happens!
There are lots of different ways to extend Ruby with code in other languages such as C or Rust, there's DragonRuby if you wanna make games, you can run Ruby on the JVM, JRuby and nowadays TruffleRuby, there's even a slimmed-down Ruby suitable for use in embedded contexts, mruby, which is what I replaced all of my Crystal code with. (if you go this route, the best way I've found is to compile your own mruby with whatever you want in it, and put a #!/path/to/mruby shebang at the top of your scripts. Compile if you need even more perf, I found JITted mruby to be more than sufficient.)
Crystal isn't a bad language, but the only thing it shares with Ruby is a small subset of syntax. It's sorely lacking in maturity and in libraries and tools. It's unfortunate because Crystal is an idea worth exploring, but its proximity to Ruby means people will always position it against Ruby, and it will always fall short. And with types now in Ruby that's one less reason to pick Crystal over Ruby.
Example: Last time I checked couldn't find a firebase library for Rust, so gave up on it.
Rust seems a bit immature in the library department no? But didn't stop it becoming popular. I bet Crystal will do the same.
You mean at least a year younger ?
Rust
>The language grew out of a personal project begun in 2006 by Mozilla employee Graydon Hoare,[18] who stated that the project was possibly named after the rust family of fungi.[29] Mozilla began sponsoring the project in 2009[18] and announced it in 2010.
Crystal
>Work on the language began in June 2011
The story around types in Ruby is very early. There are "competing" ways to do it and they are really not dev ergonomic.
I think Ruby has a loooong way to go with typing to take it off the list of things to use Crystal for.
Crystal is a statically typed language, so the traditional performance considerations about static <> dynamic languages apply. AFAIK Ruby is also particularly hard to optimize, due to its very dynamic nature (pretty much every concept can be changed at runtime).
> Crystal is very fast and quite efficient for big things
It can'be currently said "very fast" about such a young language; it will depend on how much manpower will be put it in the long term. Parallelism is not even yet stable, which is a considerable factor.
I personally think it as a pleasant language to write small tools/scripts. If parallelism would have been implemented from day 1, I would have actually used it.
It's either faster than what you consider "very fast", or it is not; how long the language has been around is, IMO, a complete non-sequitur.
That it can be made, possibly, much faster than it is I guess can probably weigh in here, but that's not what they were talking about.
That still doesn't make it a speed demon. But it does make it 'fast enough' for me.
The reading list is the starting point https://github.com/chrisseaton/rhizome#how-to-read-this-repo..., as is the code in lib of course. You can also run the experiments to generate programs before and after passes.
Someone who knows about basic things like bytecode might like to start reading at https://github.com/chrisseaton/rhizome/blob/main/doc/constru... and may find that then starts to be new information.
I spent months getting it to the point where it could just properly run rubyspec, and then months more just making it pass a decent number of its tests.
I can't imagine this has gotten any easier since then, it would be a hell of a project to make anything like this a complete working project.
[1] it's kind of horrifying to me now but it's still up on my github at github.com/stormbrew/channel9 -- the actual goal was a multilanguage vm where you can implement languages in themselves. It was originally written in ruby and eventually the bytecode interpreter core was rewritten in C++. The OP project is much nicer, more directed, and better documented by far than what I wrote there though.
Off topic: If Ruby could achieve the performance that Crystal provides, it'd wager the adoption rate would be huge.
I didn't know different units could be compared as if they had an equivalence ratio...
So sure they can't be directly compared but that doesn't mean that one cannot effect the other.
Let's see the data on that. Then let's see the cost of maintenance vs Java.
If you really want to be pedantic, 1_000_000 user operations are to be done. If you write something that does 1_000_000 user operations/second, and it takes 6 mos to write, it'll be done in 6 mos and 1 sec.
If it only does 500 ops/sec but takes 1 day to write, it'll be done in ~3.3 days.
Which one is faster?
Now we are in the regime where parallelism and memory bandwidth efficiency is more important than constant factors of speed increase. 1k, 10k or 100k cores will be commonplace, even with slow interpreted code, the code the scales to more cores faster will win, even against C++. We already have more cores than we know what to do with.
Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be. Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput.
Of course that's one of the reasons, and that goes directly against the notion that python and ruby are somehow cheaper or more efficient to develop in.
> Horizontal scaling isn't the reason and nor is it the bugaboo you make it out to be.
The point is horizontal and vertical scaling don't automatically resolve the drawbacks of slow code. Using 10x the resources to make up for slow code is generally not a solution if performance actually matters.
> Vertical scaling might get you a factor of 100 on modern hardware over dynamic languages, vertical with threading might get you to 1000x, massive parallelism afforded by the coming exponential jump in core counts is going to get folks to 10-50k increases in throughput.
Not sure what you're trying to argue here. Yes 'dynamic' languages are slower, yes you can vertically and horizontally scale both. I don't see how that's relevant for a comparison of languages.
> doubt
(Full disclosure: I work on TruffleRuby, in case that matters.)
And it starts with R, so the idea was I could write a new command-line option -rhizome to enable it, but that would actually run a library hizome.rb, with -r being the standard option to load libraries in Ruby, so letting me add a new option to an unmodified Ruby.