I use Ruby from a user level and really don't deal with the internals. I have know Rubinius as 'Ruby in Ruby' which I assumed was a generalization. Recently, I got an error with Rubinius in the RubySL (no, I don't have error msg).
I started looking at RubySL and was a little surprised to see Rubinius everywhere. I really like Ruby and was just curious why Rubinius is in most of the RubySL? It seems to be used with things like locks / unlocks (such as https://github.com/rubysl/rubysl-thread/blob/2.0/lib/rubysl/thread/thread.rb ). Definitely not questioning it, just curious.
RubySL is short for Ruby Standard Library. It is a basic part of the shipped code bundle which forms what is generally known as Ruby. The standards library provides rather basic stuff you often need but which doesn't need to be part of the core language.
For example, the implementation of the Hash or Array, the language keywords, how assignment works, ... are part of the core language. These are often implemented in a language other than Ruby. MRI (the common C-Ruby) implements this mostly in C, JRuby implements this in Java. Rubinius implements this patly in C++ but mostly in Ruby itself. It can do this by bootstrapping itself from a very simple base VM and gradually adding more stuff with Ruby.
The standards library however is mostly implemented in Ruby in all implementations (with some exceptions mostly for performance reasons). Now, all Ruby implementations right now have their own implementation of the Ruby standards library which can thus differ in minor details.
Rubinius' approach to implementing a standards library was to implement it as separate gems. The idea was to one day provide a common standards library which could be used by other implementations (including MRI). This is in line with the efforts of esp. the Rubinius community to drive the RubySpec project in order to provide a common language specification and test suite for all Ruby implementations.
The RubySpec project was eventually abandoned and right now, it doesn't seem as if other Ruby implementations seem to be moving to the RubySL gems for implementing their standards library.
Thus, (and this is the TL;DR), the RubySL gems implement the Ruby Standard Library for the Rubinius project. Thus, it is expected to see the Rubinius project all over the place there: it is their code which is generally not used by other Ruby implementations.
Related
Current status of truffleruby says:
TruffleRuby is progressing fast but is currently probably not ready for you to try running your full Ruby application on. Support for critical C extensions such as OpenSSL and Nokogiri is missing.
Why does truffleruby need C extensions? It's built on GraalVM which is built on top of the JVM, it is in fact a fork of JRuby:
TruffleRuby is a fork of JRuby, combining it with code from the Rubinius project, and also containing code from the standard implementation of Ruby, MRI.
Can't they use JRuby world gems instead of depending on their C variants?
EDIT link to the issue on github
Running C extensions is hard because the C extension API is just the entire internals of MRI exposed as a header file. You aren't programming against a clean API - you're programming against all the implementation details and internal design decisions of MRI.
JRuby's Java extensions have exactly the same problem! The JRuby Java extension API is just the entire internals of JRuby, and you aren't programming against an API, instead you're programming against all the implementations details and design decisions of JRuby.
We plan to eventually tackle both problems in the same way - which is to add another level of abstraction over the C or Java code using an interpreter which we can intercept and redirect when required, so that it believes it is running against MRI or JRuby internals, but really we redirect these to our internals.
We think C extensions are more important, so we're tackling those first. We haven't really started on Java extensions yet, but we have started the underlying interpreter for Java that we'll use.
This video explains all
https://youtu.be/YLtjkP9bD_U?t=1562
You have already gotten a good answer by the project lead himself, but I want to offer a different point of view:
Why does truffleruby need C extensions?
It doesn't need them. But they do exist and there is code out there which uses them, and it would sure be nice to be able to run that code.
I ran bundle install and to my surprise, most of the gems that ship with Rails 4 installed just fine. byebug was one that did not, but no big deal.
What makes a gem incompatible with JRuby exactly?
In this particular case, the gem is written as a C extension for YARV, so it works only with YARV, not any other Ruby implementation, including, but not limited to, JRuby, Rubinius, MagLev, MRuby, IronRuby, etc.
The sad part is: as far as I can see, it only uses public Ruby APIs, it doesn't actually use any private internal information of the YARV VM, so it could just as well have been written in portable Ruby.
In general, there are several reasons why a gem may work only on one particular Ruby implementation:
It uses some particular feature of the host platform that is not available to all Ruby implementations. For example, a gem written in Java which uses Java platform libraries, will most likely not work with YARV, only with JRuby.
It accesses private internal implementation details of a particular Ruby implementation. This is obvious, I think. What's not so obvious is that there is no portable C API even amongst C-based Ruby implementations. What is usually called the "Ruby C extension API" is really just YARV laying bare its internals. Both Rubinius and JRuby have put in an enormous amount of work developing emulation layers for YARV so that at least some C extensions work, but it's hard. For example: YARV's garbage collector is extremely simple, it never moves objects in memory. Many C extensions rely on that, but this is simply not true for modern GCs such as Rubinius's or the JVM's. YARV doesn't allow multiple Ruby threads to run at the same time, many C extensions rely on that, but this is not true for pretty much all other Ruby implementations. And so on … Plus, those emulation layers are slow. Really slow. It is perfectly possible for a gem that has been "re-written in C for performance" to run slower than its pure-Ruby counterpart on JRuby or Rubinius. (After all, Rubinius can, in some cases, already compete with C. E.g. the Hash class in Rubinius is written in Ruby, and performs comparable to YARV's Hash class which is written in C.)
It uses a Ruby feature that is missing from a particular implementation. For example, Refinements have been widely criticized for being un-implementable in implementations that perform aggressive optimization of method lookup (or more precisely: Refinements, the way they are currently specified, make it impossible to apply those optimizations). The designers of Refinements all happen to be YARV developers, where it doesn't matter, because YARV doesn't optimize method lookup anyway, but e.g. the JRuby developers have decided to simply not implement Refinements. (10 years ago, they did the same thing with continuations.) So, if a gem uses Refinements, it won't work on JRuby.
The Rubinius and JRuby developers have developed an FFI API that can be used to make C APIs available from Ruby in a manner that is portable across many Ruby implementations. Rubinius, JRuby, MacRuby, and (I believe) MagLev support FFI natively, and for YARV, there is a gem which adds FFI support to it. Gems that use the implementation-independent FFI API instead of the YARV API should work on pretty much all implementations. However, the FFI API doesn't give access to the implementation internals (obviously), so for some gems it is not usable. For example, there are gems which try to give you access to the source code of a Proc, that's highly implementation-specific (and may not even work, e.g. when you ahead-of-time compile to a Java .class file with jrubyc, the source code doesn't even exist at runtime), so there has to be a different version of that gem for every Ruby implementation.
SAP announced Blue Ruby, a version of Ruby that runs inside the ABAP Virtual Machine.
This seems to lend additional credibility to the Ruby language but, except for SAP developers, does this have any applicability to the rest of the Ruby community?
I'm just wondering what other significance this may have. Additional job opportunities, perhaps, for Ruby developers to be hired to work on SAP projects?
Any other potential benefits for Ruby programmers?
Also, something I'm not clear about: Besides MRI and JRuby, how many different implementations are there and why do I, as a Ruby programmer, need any implementation except the MRI? I understand I might need JRuby if I want to integrate with Java libraries. Are there any other times I might need to look into an implementation besides the MRI or JRuby?
I notice that Blue Ruby is compiled. Is that a big benefit and would this be the first compiled version of Ruby?
Sorry - maybe too many questions but this is being discussed as a big deal except I'm not sure why/if it really is. Would be grateful to get some feedback from people who understand Ruby (and I.T.) better than I do.
There are actually quite a few alternative implementations. The reason for so many versions is partly because while Ruby itself has a lot of fans, MRI is often considered to be not quite as nice as the language it hosts.
This is a list of all the other Ruby implementations I know of:
MRI
JRuby for Java. Its speed advantage isn't as great now that Ruby 1.9 is out, but it's still a big player for its integration with Java.
IronRuby (still in development) for .NET
MacRuby for making native Mac OS X applications. It's currently based on Ruby 1.9, but they're going to release a new LLVM-based virtual machine for the next version, which looks to offer a major speed boost and will hopefully be portable to other LLVM target platforms.
MagLev (still very much in development) for high-capacity Web apps. It will probably be a commercial product.
Rubinius is a ground-up reimplementation meant as an alternative to MRI with a much cleaner foundation.
I doubt Blue Ruby will have much of an impact on the general software development landscape. It will probably be nice for SAP programmers and allow them to cast a wider net for potential hires since Ruby is somewhat more popular than ABAP.
All of the current Ruby implementations are compiled to bytecode. Contrary to SAP's claims, as of Ruby 1.9, MRI itself includes a bytecode compiler, though the ability to save the compiled bytecode to disk disappeared somewhere in the process of merging the YARV virtual machine. JRuby is compiled into Java .class files. I don't have a lot of details on MagLev, but it seems safe to say it will take that road as well.
Each implementation has its own use cases. JRuby is useful for much the same reasons Jython is. IronRuby will be useful in a .NET environment, when it exists in a usable state.
Things like this make Ruby more acceptable on the Enterprise level, and hasten the spread of Good Programming Languages.
Of course, Blue Ruby is intended for SAP related people. I don't think is going to have much more of an impact on the Ruby community because most Ruby developers are not related to ABAP development.
The main purpose of Blue Ruby is to bring a powerful Scripting Language into the ABAP world, providing more tools for ABAP developers.
You can read my blog on Blue Ruby providing an SE16 (Data table explorer) emulator.
https://weblogs.sdn.sap.com/pub/wlg/14222
Greetings,
Alvaro "Blag" Tejada Galindo.
Senior ABAP Consultant - SAP Mentor.
There are multiple Ruby implementations in the works right now. Which are you looking forward to and why? Do you actively use a non-MRI implementation in production?
Some of the options include:
Ruby MRI (original 1.8 branch)
YARV (official 1.9)
JRuby
Rubinius
IronRuby - Ironruby.net
MagLev (Thanks Julian) Github link
MacRuby (Thanks Damien Pollet)
Maglev. It will have the speed benefit of all the optimization that has gone into a major Smalltalk VM over many, many year. Plus it will automatically persist all your data pretty much automatically so there is no more need to monkey around with Object-Relational mapping layers and so on.
Ruby 1.9 (YARV) gives us a good idea as to where ruby is headed, but I wouldn't recommend using it for production use. While it's certainly much faster than 1.8, even some parts of the syntax keep changing, so I don't think you could call it stable. It does have some interesting new features and syntax which will surely find their way into all the other implementations over time.
JRuby and IronRuby are useful in that they give ruby access to a whole range of new libraries and environments where ruby couldn't be used otherwise. I've not found much use for them myself yet, but think it's great that they exist. They may allow ruby to infiltrate corporate environments where it wouldn't otherwise be permitted. That can only be a good thing.
Rubinius and Maglev are probably the most interesting projects, but also those where their benefit to the community is likely to be furthest into the future. Rubinius may well develop into a cutting edge 'pure' VM for the ruby language, allowing ruby code to run much faster than it can now. Maglev too seems extremely promising, backed as it is by 20+ years of VM experience. It will also provide features over and beyond a standard VM, but of course these will come at the cost of code portability.
Overall though, what I'm most excited about is the competition between these implementations. Having competing projects all working to make ruby better can only make the ruby ecosystem stronger. From what I've seen too, while the competition exists it is friendly; each project giving and taking ideas from each other. The work done by the JRuby and Rubinius teams in creating a ruby spec is probably the most important outcome so far, as it will help ensure that all implementations remain compatible.
jRuby is stable and reliable today. Maglev is very promising.
No one mentioned MacRuby yet? I guess it's a bit Mac-specific now, but it could probably be made to compile to the GNU or Étoilé objective-c runtimes too.
Also, I'm waiting for Maglev :)
What about Enterprise Ruby? This has been out there for a while.
https://www.phusionpassenger.com/enterprise
Has anyone ever done work to get Ruby to do continuations (like Seaside on Smalltalk)?
Yes, in most cases. MRI (1.8) have supported them as far as my memory reaches, Ruby 1.9 (YARV) does it, too, so does Rubinius. JRuby and IronRuby don't have continuations, and it's quite unlikely they will get them (JVM and CLR use stack-instrospection for security)
Ruby as a language supports continuations via callcc keyword. They're used, for example, to implement Generator class from standard library.
continuations on ruby-doc
Continuation-based web frameworks (like seaside, or one from Arc's std. library) seem less popular. I've found wee that claim to let you do optional continuations, but I've never used it.
As others have said already, Ruby 1.8 supports continuations.
Ruby 1.9 has not supported them for a while however. They have been added back some time this year, but most of the other Ruby interpreters (JRuby, IronRuby, etc) don't support them.
If you want your code to be usable on other platforms than the mainline Ruby, I'd suggest not using them.
Read this InfoQ article for a more comprehensive discussion on the topic.
Btw this is an example of restartable exceptions (aka conditions) implemented using continuations. I used it few times and it's a cool thing to have in a Ruby toolbox.
neverblock uses 1.9 fibers for a single threaded ruby web server