Reia: Friendly, Ruby-style syntax on the Erlang VM

by nathanwdavis • 16 years ago

69 46 16 years ago

This is still very alpha, but I'm submitting this because I really hope this succeeds. Erlang is really powerful and provides more modern paradigms for concurrent programming that just are not easily implemented in other VMs. However, Erlang's prolog inspired syntax is a big turnoff to many programmers. This could be a breakthrough.

gurraman• 16 years ago

I guess I'm weird but I actually like Erlang's syntax. To me it's part of the language's personality.

nathanwdavis4• 16 years ago

Yeah, I don't mind it either. Syntax is not a big deal to me, I care more about the unique capabilities of a language are. But I have heard other developers say they hate it.

rlander• 16 years ago

Me too. i actually miss the syntax when i'm doing something in python now .

bradfordw• 16 years ago

Don't cheat yourself...Erlang itself is not that hard once you understand the core principles. I will say that OTP can be overwhelming, but with tools like rebar taking care of the bulk of it for you now, it's much more accessible to beginners. The learnyousomeerlang.com guide as well as the "Erlang and OTP in Action" book are really great resources for starting out. Stick with it, you'll be glad you did.

moe3• 16 years ago

Voting you back up to 1, after you had predictably been downvoted...

You're not alone here.

I gave erlang more than one shot and really, really wanted to like it. It promises to simplify and robustify some of the most thorny distributed programming problems that I'm dealing with nearly every day, in ruby and python.

But, just like you, I couldn't get over the syntax. It's ugly. It's error-prone. It's ugly.

And that's a dealbreaker. The most powerful VM doesn't help when you have to work uphill against arcane syntax all day long. Nobody wants to do that. That's why ruby is so popular, despite the trainwreck that is MRI.

CitizenKane• 16 years ago

While the Erlang syntax is certainly a bit unusual I suspect that the greater adoption of Erlang is hampered more by other things.

For instance, there is tool support. As with any language that isn't very widely used there aren't that many tools for the language. It makes it more difficult to get up and going in a short manner. This is especially true if you're on Windows since many Erlang projects don't work on Windows (even though the VM itself has Windows support).

Beyond that, Erlang uses a model of programming and concurrency that isn't commonly used elsewhere. While you can get many of the features of Erlang in other systems, you are generally making an intentional effort to do so. Things like messaging passing, processes and hot code swapping are at the core of the language and getting used to things like this can be a bit overwhelming.

On top of that many of the Erlang projects I've worked with have extremely sparse documentation. There are many cool projects out there like Mochiweb, Nitrogen, etc. but getting up and going with them can at times be an exercise in frustration.

I think these things combine to make a barrier to entry that is much larger than people's syntax preferences.

nivertech3• 16 years ago

I think Efene/Ifene is better for this task (just different syntax for Erlang, without changing Erlang semantics). No performance overhead.

Reia has completely new semantics and run in interpreted mode over BEAM (Erlang VM).

I personally think, that if programmer can't adapt to new syntax, it will be much harder to her/him to adapt to new semantics.

Erlang's syntax is ugly comparing to modern languages like Ruby. The simple things are hard to do in Erlang and simple in Ruby, but complex thing are easy in Erlang and impossible in Ruby.

Erlang is pragmatic choice for today. Maybe in 5-10 years Erjang,Scala,Go,Rust or some other new language will be a better choice, but until then use Erlang/OTP.

bascule6• 16 years ago

Reia isn't "interpreted" in any manner different from the Erlang language itself. It's somewhat similar to CoffeeScript in that it uses parse transforms to produce Erlang parse trees which are then compiled by the Erlang compiler just like any other Erlang source code. However, it's a bit more like JRuby in that it ships a runtime, core types, and a standard library.

It's slower than Erlang, not because it's executed in a different manner than Erlang, but because it supplies a separate late binding mechanism for dispatching methods to their receivers.

daleharvey• 16 years ago

This is a cool and fun project, but a lot of people in the thread are pretty confused about erlang syntax so I wanted to post this.

erlang's syntax is not some arcane afterthought, it may look strange or even "ugly" to people not familiar with it, but it has been very well thought out and purposeful, every time there is a choice between a beautiful construct that can add confusion, or a less elegant solution that is crystal clear, erlang chooses less elegant every time.

I have been doing javascript since I started programming and still get confused by its object model + prototypal inheritance, the same is true for pretty much every language, python, ruby, c++ etc going back to erlang is a refreshing break.

moe3• 16 years ago

I'll stick with Damien Katz on this:

   Erlang is based originally on Prolog, a logic programming     
   language that was briefly hot in the 80's. Surely you've 
   seen other languages based on Prolog, right? No? Why not? 
   Because Prolog sucks ass for building entire 
   applications. But that hasn't deterred Erlang from 
   stealing it's dynamite syntax.

cf. http://damienkatz.net/2008/03/what_sucks_abou.html

troutwine2• 16 years ago

Until our species gets rather better at quantifying the effect of communication mediums' on cognition I take issue with Mr. Katz's assertion. The semantic meaning of Erlang and prolog code is such that ideas can be expressed rapidly, in my experience. Besides, taste in syntax is like taste in tea: you might prefer a light cup of Earl Grey, I might like mine over-brewed and bitter. Prolog's syntax--and by extension Erlang's--is an acquired taste, perhaps; I like them both.

Tea time!

bascule6• 16 years ago

Hi. I created Reia.

Erlang's semantics are so very different from most other languages that having an arcane Prolog-derived syntax is just insult to injury.

In addition to all the conceptual, semantic leaps that Erlang asks you to make, you also have to learn a syntax which is very different from the Algol/C-based languages most people are used to.

I buy the argument that maybe, if you get used to it, Erlang's syntax can be beautiful. But it's still very much a barrier to people who have never used the Prolog language "family" (which as noted earlier includes... Prolog and Erlang).

In my personal experience having used Erlang for some 3 years now, I still find its syntax ugly and obtrusive.

ams6110• 16 years ago

I found I adapted to Erlang's syntax in under a week. I'm far from proficient in Erlang, but it's not an issue of syntax, rather experience.

Erlang syntax is a bit different, and there are even (IMHO) internal inconsistencies, but I didn't find it any more of a roadblock than e.g. python's indentation conventions. Each person is different I guess.

knodi• 16 years ago

I really like Reia and have been following it for sometime now, I hope to use it onces it makes into beta.

pjscott3• 16 years ago

What would make this more attractive to me is a mechanism for local mutable state. Some algorithms are just easier to express if you're allowed to change the values of some local variables. Erlang has no shared mutable state, but as Haskell's State monad shows, it's perfectly possible (and often useful) to keep mutable state boxed off safely.

Since this can be transformed to tail-recursion, you should be able to implement it on the Erlang VM without too much trouble. Getting a convenient syntax and doing the transformation would be the hardest part.

hvs• 16 years ago

I'm a huge fan of Erlang (hot-swapping code for the win!), but this is probably my biggest peeve with it.

wnoise• 16 years ago

There is still the process dictionary, but it's a bit unwieldy.

http://www.erlang.org/course/advanced.html#dict

yosh• 16 years ago

I've also used private ETS tables for this.

gordonguthrie6• 16 years ago

Yes the process dictionary seems attractive, but you will come to regret it. It will always bit you in the bum, don't do it, don't do it, don't do it.

metabrew• 16 years ago

there are some hipe_bifs that let you do naughty and unpure things like destructive modification of arrays and what-not.

gordonguthrie6• 16 years ago

With all due respect metabrew, if you do that you are a nutter.

Non-mutability is not some crazy quick left there as an afterthought - it is at the core of Erlang - it is how you build reliable systems in the presence of errors.

elgenie• 16 years ago

And nifs can be made to do most anything you want to module-private data.

But if you're cheating on purity, there better be a darn good reason.

bascule6• 16 years ago

Hi, I created Reia.

I used to agree with you but now I don't. I was particularly moved by some of what Joe Armstrong, Erlang's creator, had to say in the book "Coders at Work". He noted that after attending several functional language conferences, immutable state was much more a common quality of truly functional languages than other things people typically associate like static typing or lazy evaluation.

Reia is an immutable state language, and I think it's primarily a functional language, but one with a lot of features that make it less painful to use than languages like Erlang or Haskell.

In a language like Erlang, immutable state allows you the potential to send zero copy messages between actors. This can be hugely beneficial for exchanging state in a shared nothing system like Erlang.

That said, the Erlang VM doesn't work this way. There have been experiments like the shared and hybrid heaps to enable this, but they've largely been failures, not because they're conceptually flawed, but because the garbage collection in Erlang is relatively simplistic. Erlang processes are independently garbage collected so they never needed to deal with concurrent garbage collection or a shared heap before.

Erjang (Erlang on the JVM) uses Java's shared heap and lets you use the wealth of pluggable garbage collectors available on the Java platform.

In a quick test of the "chameneos-redux" benchmark on Erlang BEAM vs. Erjang, a benchmark which generates lots of messages and can benefit immensely from sharing state, Erjang was about twice as fast as Erlang.

pjscott3• 16 years ago

I'm definitely not talking about mutable state that's shared between processes. I don't want global variables, or any such thing. I just want to be able to write little blocks of code where I can change local variables. To illustrate what I'm getting at, here's some code in JavaScript which will calculate the nth Fibonacci number:

    function fib(n) {
        var a = 0, b = 1;
    
        for (var i = 0; i < n; i++) {
            var temp = a + b;
            a = b; b = temp;
        }
    
        return 'fib(' + n + ') = ' + a;
    }

It uses a for loop. Of course, you could do the same thing with a tail recursive function, or probably some higher-order-function trickery, but a for loop is a very direct way of putting it.

But how do we implement this on the Erlang VM? It doesn't support any of this dangerous mucking around with the values of variables! As you rightly point out, there are good reasons for this. What we can do is convert this to, essentially, continuation-passing form. This looks awkward is JS, but it gives the same answer:

    function fib_cps(n) {
        function forloop(a, b, i, cont) {
            if (i < n) {
                return forloop(b, a + b, i + 1, cont);
            } else {
                return cont(a);
            }
        }
    
        return forloop(0, 1, 0, function(result) {
            return 'fib(' + n + ') = ' + result;
        });
    }

The for loop was converted to a tail-recursive function which takes the values of all the mutable local variables and tail-calls some function with (some subset of) these mutable local variables. Since Erlang has proper tail-call support, this should be no problem. And it doesn't require any modification to how heaps are handled, or Erlang's garbage collection scheme, or anything. It "just" takes some compiler work.

That's what I had in mind. Does it sound more reasonable?

grav1tas• 16 years ago

Here's a question. Does there exist a decent stand alone representation (BNF or otherwise) of the Ruby grammar? I see all this stuff that says Ruby-style, and it looks almost like straight up Ruby. Moreover, I Google around for a Ruby grammar and can't find much of anything substantial, but I haven't looked in awhile. I've tried cruising the Ruby YACC file, but that's kind of a disaster. Is there good one that exists as a reference for 3rd party Ruby implementations?

RickHull• 16 years ago

You might take a look at http://mirah.org, which is Charles Nutter's (creator of JRuby) forging of Ruby-like syntax with static typing that compiles to Java bytecode.

nivertech3• 16 years ago

Still using rake for build?

Please rebar-ify!

bascule6• 16 years ago

Perhaps. Rebar is cool. But I'd like for as much of Reia as possible to be accessible to Rubyists with little or no knowledge of Erlang.

jwecker2• 16 years ago

I too have been following Reia since he started it up and... well, I'm consistently disappointed. I'm putting this out there publicly because it's come up with co-workers. In the end, he's waffled with so many language design decisions that, in my opinion at least, it's turned into a language that on one end doesn't have the true syntactical flexibility of Ruby, and on the other side has buried a lot of what is most useful in Erlang. For alternatives I would suggest Lisp Flavored Erlang http://forum.trapexit.org/viewtopic.php?p=40268 or Efene / Ifene http://www.marianoguerra.com.ar/efene/ - both of which do much better at being Erlang-(but-with-better-syntax).

Edit: This is referring to its current state only- I reserve the right to change my mind in the future (:

bascule6• 16 years ago

Hi, Reia's my thing. My view on waffling on language design decisions:

If you're working on a language project, fuck it up, and don't do a rewrite, you get PHP.

That said, your other criticisms are valid: much of Erlang's functionality doesn't have first class Reia support (but is still directly callable through the presently undocumented Erlang interfacing syntax)

Many of Ruby's great features aren't available in Reia yet either. I'm shooting for a subset of Ruby's metaprogramming features which aren't incompatible with Erlang-style code loading.

I hope you'll continue to watch the project.

jwecker2• 16 years ago

The word waffling was too negative, and you're right. I apologize and I'll definitely keep watching. Erlang and Ruby are my two favorite languages as well, so if you do pull it off at some point, you'll have my support (:

ohyes• 16 years ago

I feel that we spend too much time worrying about the syntax of programming languages. I don't find switching between typing in erlang/lisp/java/ruby code any more difficult. All I do is switch IDEs (or plugins) and I'm at about the same level of productivity typing wise.

Semantics are much more interesting to talk about, but it seems we never do talk about them. We rarely have holy-wars over the semantic differences between (for example) c and lisp, or lisp and Erlang.

There are certain problems that are easier to solve when expressed as many concurrent processes. In this same way, there are certain problems that are easier to solve when expressed as self modifying code or a tower of objects, or low level bit bashing.

At a certain level, different syntaxes do absolutely nothing for me. No matter what I'm doing with code, I am manipulating a syntax tree. I'm never thinking about the syntax on the page as the 'code,' what is on the page is just a representation of the 'code' that is in my head and being run by the computer. And the semantics of that 'code' is what influences how I use the language.

Syntax on the page is almost a deception. Kind of an illusion that influences you into thinking about the code in a certain abstract way (a spatial 'on the page' arrangement of different parts), when really, the code was already abstract to begin with (runtime execution 'arrangement' of the different parts).

Reia: Friendly, Ruby-style syntax on the Erlang VM

Related Stories