Beyond Ruby: Mirah, Reia, Rite(igvita.com)
igvita.com
Beyond Ruby: Mirah, Reia, Rite
http://www.igvita.com/2010/12/14/beyond-ruby-mirah-reia-rite/
5 comments
I think mirah is an interesting implementation of ruby like syntax on the jvm. I like the flow of ruby and to compile down to jvm bytecode should theoretically yield the performance of java. I think as with any language its growth is down to a few key factors like some interesting public projects, big names using it, library support and then a community forming behind it. Its all about use cases right?
Ruby for me was a web language that I took to scripting and then tried some server side work in, but I'm starting to see its limitations and overheads.
Rite while being an embeddable language and having a specific use case will most likely be this light weight barebones ruby that can be run in place of our existing web software, scaling up nicely. However thats just speculation.
Ruby for me was a web language that I took to scripting and then tried some server side work in, but I'm starting to see its limitations and overheads.
Rite while being an embeddable language and having a specific use case will most likely be this light weight barebones ruby that can be run in place of our existing web software, scaling up nicely. However thats just speculation.
So the trend here is... Ruby syntax, compiled to other languages' semantics?
This would excite me more if Ruby's syntax were better. I want metaprogramming on top of everything and its brother, not Ruby syntax. Even though I love Ruby.
This would excite me more if Ruby's syntax were better. I want metaprogramming on top of everything and its brother, not Ruby syntax. Even though I love Ruby.
The win with Mirah has more to do with adding other modern features like type inference and closures to Java without introducing a foreign runtime. It also has metaprogramming in the form of pluggable compiler macros, but I haven't really tried those out yet.
It's my impression that the Ruby syntax was chosen simply because it was the closest thing at hand.
It's my impression that the Ruby syntax was chosen simply because it was the closest thing at hand.
I think Mirah could be a serious competitor to Scala.
I'm skeptical. Mirah can't really do much to support functional programming without adding a runtime, since the JDK's built-in classes don't provide data structures amenable to FP. But the point of Mirah is to be lightweight without its own standard library.
You could use Mirah with Clojure or Scala to get access to the necessary libs, but then you lose the lightweight advantage and could fragment the community.
You could use Mirah with Clojure or Scala to get access to the necessary libs, but then you lose the lightweight advantage and could fragment the community.
Are you talking about higher order functions or something else.
Of course, it all depends on definitions; in this case things are fuzzy. Functional programming means a lot of things to a lot of people. "Supports higher-order functions" is necessary for pretty much any definition of FP, but it sets a very low bar.
My definition would have to include "supports pure functions idiomatically", which means it must be practical to write the bulk of your programs without side-effects. This is really only possible if you have persistent data structures that can efficiently share structure internally; otherwise avoiding side-effects involves lots of wasteful copying. (See http://technomancy.us/132 for an explanation of persistent data structures.)
Of course, if you asked a Haskell programmer, they would be mortified that you would leave monadic computation out of your definition, so no single definition is going to please everyone.
My definition would have to include "supports pure functions idiomatically", which means it must be practical to write the bulk of your programs without side-effects. This is really only possible if you have persistent data structures that can efficiently share structure internally; otherwise avoiding side-effects involves lots of wasteful copying. (See http://technomancy.us/132 for an explanation of persistent data structures.)
Of course, if you asked a Haskell programmer, they would be mortified that you would leave monadic computation out of your definition, so no single definition is going to please everyone.
Scala had some of the same design goals as Ruby, especially the goal of being a pleasant language to live in on a daily basis. Mirah essentially removes the (theoretically, at least) performance advantage that Scala had over JRuby. Of course there is the issue of not being able to use MRI Ruby code with Mirah; overcoming that in a clean way would bring a lot of MRI folks over to Mirah.
> I want metaprogramming on top of everything and its brother, not Ruby syntax.
Depending on what you mean by metaprogramming, my goals for Magpie may fit what you're looking for. Its syntax is a bit like Ruby, and it features the dynamicism and open classes you get from Ruby. But, beyond that, I'm planning to add full Lisp-style quasi-quoting metaprogramming, as well as an in-language-extensible parser.
Depending on what you mean by metaprogramming, my goals for Magpie may fit what you're looking for. Its syntax is a bit like Ruby, and it features the dynamicism and open classes you get from Ruby. But, beyond that, I'm planning to add full Lisp-style quasi-quoting metaprogramming, as well as an in-language-extensible parser.
> Rite: an embeddable Ruby. Think Lua, but better
For some reason, this really came off as fan talk, and it really annoyed me.
For some reason, this really came off as fan talk, and it really annoyed me.
That's a fair statement - it was a joke at RubyConf.. Quoting Matz actually. :-)
I don't know why more people aren't excited about Reia. ErlangVM w/ more approachable syntax? Awesome. Not that I don't like Erlang syntax, I just think more people would be willing to use it if it has more familiar syntax.
For the curious, I mixed JRuby + Duby to create (realtime) audio processing (VST) plugins.
https://github.com/thbar/opaz-plugdk/blob/master/plugins/Dub...
https://github.com/thbar/opaz-plugdk/blob/master/plugins/Dub...
In this example JRuby provides the "declarativeness" and ease of use of Ruby, while Duby makes the "heavy computation".
Duby in this case is just as fast as Java used on floats (it's actually translated into Java).
Of course, to get to write VST plugins with this, you already have a C++ <=> Java wrapper (jVSTWrapper), then a Java <=> JRuby wrapper I wrote.
https://github.com/thbar/opaz-plugdk/blob/master/src/JRubyVS...