Tony Arcieri (@bascule) Has been in the Ruby community for quite a while. He's got a strong interest in concurrency, which lead to my interviewing him about Revactor last year.
When he couldn't get the performance he was looking for with Revactor, he started working on a new Ruby inspired language on the Erlang VM — Reia. Tony was kind enough to sit down and spend some time with me doing an interview about his new project.
Besides yourself, who's using or working on Reia?
Tony A number of people have made minor contributions. One of the main people involved is Phil Pirozhkov, who is working on a web framework for Reia called Ryan.
The other contributors can be seen on the Github impact graph.
Who should be looking at it?
Tony Anyone interested in using dynamic languages to develop web or other network services, particularly people with a background in object oriented languages but not a lot of background in functional languages.
Other than web and network programming, what problem domains do you think Reia will do well in?
Tony Most of the areas I think it will stand out will be subsets of web or network programming, but perhaps I can go into some of those more specifically.
I think Reia will be good at the sorts of interfacing and automation tasks that Ruby has become incredibly successful at, but will carry with it all the distributed computing power offered by the Erlang/OTP framework. In that regard I think Reia will do well at automating tasks on distributed systems, particularly in regard to handling failures.
Cloud computing services offer a great platform for building distributed systems for automating tasks. I think Reia will do quite well there. It's the same problem domain that EngineYard is trying to address with Vertebra, but with Reia I hope the solution offered can be accomplished using one language rather than two (Erlang and Ruby in the case of Vertebra). I also expect Reia could work quite well in conjunction with the Erlangy parts of Vertebra.
I also think Reia could work quite well as a language for Erlang testing as it has full access to the Erlang runtime and excellent Erlang interfacing. I have strong hopes of seeing a tool like RSpec implemented in Reia and being able to use it for Erlang testing. RSpec has seen great success in the Ruby community and I hope I can bring it to the Erlang world.
In your blog post Reia and Object Aware Concurrency you talk about object concurrency, is this enough?
Tony No, and for that reason Reia also has processes and the full power of Erlang's actor model exposed at the language level.
Objects are there for cases that can be solved primarily with RPCs.
What about the FP claims that idempotency and freedom from side effects are the high road to concurrency?
Tony While Reia has a number of side effects not present in Erlang, great care is taken to localize side effects. All operations with side effects use copy on update semantics, and side effects are actually manifest in the form of destructive rebinding (which is in turn compiled to a pure functional form with single assignment). In most cases the side effects are completely localized to the function they occur in.
What is typing like in Reia — Static or Dynamic, Strong or Weak? Why?
Tony Reia has strong dynamic typing. This is largely inherited from Erlang which also has strong dynamic typing, although Reia does add automatic type coercion in a few places (e.g. interpolated strings)
I'm a fan of dynamic languages in general and this is one of the characteristics which drew me to Erlang in the first place. I find dynamic typing less obtrusive than static typing and believe it helps programmers develop more quickly.
How are you managing the differences between types in Reia and the Erlang VM?
Tony Reia's built-in types which do not have direct Erlang equivalents, such as strings and regexes, are represented internally as tagged tuples. Reia tuples are also tagged to distinguish them from the other types.
Calling out to Reia from Erlang is done through a "reia" module which automatically converts types which have direct equivalents, however types which can't be natively represented in Erlang such as regexes and tuples are left untouched.
Reia has first class syntax for calling out to Erlang which also automatically handles type conversions.
In The cutting edge of VM design you wrote:
"Approaches like software transactional memory ... are better suited to certain types of concurrency problems than Erlang's shared-nothing process approach."
What spaces are the Erlang VM and Reia not well suited for?
Tony Problems which are intrinsically tied to a central shared state are difficult to address in Erlang (and by virtue of that, Reia as well), because Erlang bends over backwards to avoid shared state. There are tools like ETS and Mnesia to model shared state, but solutions offered in Erlang are generally going to be much slower than solutions which can concurrently operate on the same state with tools like STM.
Ulf Wiger brought up the chameneos-redux problem from the Programming Language Shootout as a benchmark where Erlang does quite poorly.
It would be difficult to add Erlang-style fault tolerance to a system which uses STM (and for that reason it would be difficult to add STM to Erlang). Erlang isolates state per process, so when errors occur the process can simply crash and get restarted in a clean state by its supervisor. With STM unless you're able to completely blow away the shared state and start over in the event of a fault, you're left with trying to handle the error and roll back to a clean state, which is a far more difficult problem than Erlang's "just crash and start over clean" approach to fault tolerance.
Problems with a strong sense of time and a need for global synchronization are probably ill-suited for Erlang/Reia and better addressed by a dataflow language. Erlang/Reia are inherently asynchronous and designed with a work-at-your-own-pace approach in mind, using mailboxes to synchronize execution. If you want all processes to work in sync with a global clock your best bet would be to look elsewhere.
Numerical computing is another area where Erlang is somewhat weak, although Erlang/HiPE actually does significantly better at this than many other languages, like Perl, PHP, Python, or Ruby. As I intend to add various degrees of operator overloading to Reia it is only going to get worse in this regard.
All that said, the core Erlang developers are largely focused on making the existing model work better and not particularly willing to try to incorporate other concurrency paradigms like STM into the language. I'm quite happy they're doing that and are focused on the problem of improving this like the SMP scheduler. However, I'm much more open to experimenting with other approaches to concurrency in Reia. I would love to see a hybrid STM/actor system and may eventually try to pursue that with Reia.
What resources (books, blog posts, papers, etc.) are you looking at as you design/build Reia?
Tony Other people have been my biggest resource. I'm constantly soliciting feedback on IRC, mailing lists, and elsewhere. Some of the best feedback I've received has come from big names in the Erlang community like Joe Armstrong, Ulf Wiger (@uwiger), and Robert Virding (@rvirding).
This is a particulary interesting set of questions I went through and tried to make sure I had decent answers for. I've thought about trying to put together a blog post answering some of the questions from the lightweight languages list.
I've read Open Reusable Object Models as well, although I'm not sure I can really fulfill its requirements in Reia.
The The Definitive ANTLR Reference
If someone wants to get involved with Reia development, where should they start?
Tony Signing up for the Google group and asking that same question would be a great place to start.
Three areas where contribution from outside developers would be most welcome are: testing, built-in types, and the standard library. All of these are largely self-hosted in Reia. Just writing simple tests for presently untested parts of the language would be immensely helpful. In addition, the built-in types still lack a lot of the functionality present in Ruby and Python. Dive in, look for a feature from your favorite language which seems to be missing, and add it.
Most people don't try to develop 'the one true language'. What are your goals with Reia? How will you know if you've succeeded?
Tony Reia is certainly intended to be a niche language. If there's one area I'd like to see it succeed in it would be web application development, particularly for cloud computing applications. While I think Erlang's process model should make it immensely successful in the area of rendering web pages glued together from a variety of backend services (e.g. memcache, db, search index, queues) Erlang has struggled to succeed in this area. A number of frameworks are available but none of them have gained widespread adoption. I don't think anyone sees Erlang as becoming a language recognized for web development any time in the near future.
If a web framework for Reia were to become as popular as Rails I'd certainly regard that as a success :)
No comments:
Post a Comment