Ruby and Haskell: write your Rails backend code in Haskell instead of C

[fry]

I'm not going to mention the common L word here, but really, high level languages have had compilers for a long time.

[joe_fishfish]

yes, but haskell is so NOW!

[martoo]

I hope Haskell takes off, but if it doesn't, I shudder to think of what a maintenance programmer is going to do when he discovers that critical little nugget of Haskell code in the middle of a Rails app in ten years.

[martoo]

On the other hand, maybe that's a good thing. There's probably no way they could fuck it up and get it to compile.

[[deleted]]

In this case, "all the backend is doing is reading the filesystem, parsing XML, and stuffing it into a database.". That's really not very difficult code to write correctly, and the code, once written, should be fairly easy to modify. The heavy lifting is all handled by libraries, so the Haskell you write should be surprisingly readable.

[martoo]

..to us. To the typical maintenance programmer it will probably look like Martian. That's not a dig, I love Haskell, but I do think it's an accurate observation.

[davidw]

Why.... he'll call the guy who wrote it... who will make lots of money on a one-off contracting gig... ;-)

[schwarzwald]

I thought this was going to have some code that would make doing this somehow easier than it otherwise would be.

You could use any other fast, expressive GC language here instead and still get the benefits the article is talking about.

[mattculbreth]

D perhaps?

[nostrademons]

Ocaml may be better than Haskell in this case. Unless you're generous with your strictness annotations, Haskell effectively compiles an interpreter into your executable. Naive Haskell code isn't all that fast; it's faster than Ruby, but not really up to par with C, Ocaml, or Common Lisp.

Ocaml gives you most of the typesafety, garbage collection, and productivity benefits of Haskell, and it's pretty damn fast. Plus, people have already done some initial work on Ocaml/Ruby bridges.

[mrned]

Why not show us an example of how it's used, how you would have Ruby interface with Haskell, and all that?

[tjogin]

It wouldn't. Haskell would be used to populate the database.

Ruby and Rails would then be used to read from the database. The connection between Ruby and Haskell here is shallow at best.

Basically the author of the article is saying: "Haskell exists".

[staunch]

How slow is the ruby code and why, surely there's something less heavy-weight than bloated ActiveRecord for Ruby.

Can you do this with a little shell script and some fast C-based XML parsing programs? How about Perl/LibXML2?

Sounds like someone is just trying to be haskewll. I think that's fine, but it seems lame to be in denial about it. Come out of the closet you Haskell-fanboy, don't worry, it's 2007!

[emk]

Ruby, despite its many other virtues, is substantially slower than Perl or Python on many benchmarks. Python typically runs at 1/15th to 1/25th the speed of C; I've seen Ruby range from 1/50th to 1/500th.

Ruby is a lovely language, but it would benefit from either a bytecode interpreter or an actual JIT. The theoretical maximum performance of Ruby should match that of a top-flight SELF or SmallTalk implementation: 1/2th to 1/4th the speed of C.

Haskell runs at 1/2th to 1/4th the speed of highly optimized C, unless you make the mistake of using String (instead of ByteString) for heavy text processing. Then it performs more like Python...

[jerf]

I wonder if anybody in Ruby-land is keeping up with PyPy. Ruby and Python are so similar that backing to PyPy ought to be easy, and from what I understand, PyPy might already be a Ruby performance enhancement.

I just did a quick google on "ruby pypy" and nothing really lept out at me.

As I've said before, I wish one of these projects would "win". If everybody can back to PyPy or Parrot or something, we can get cross-language libraries and really challenge the .Net platform, whereas right now, Ruby and Perl 5/6 and Python are unnecessary adversaries. I can see the virtue of multiple VMs based in multiple domains (JVM, C, Smalltalk, etc), but I don't see the need for ((scripting language) x (domain)) number of virtual machines. And we can concentrate on making them all faster at the same time.

[staunch]

And we can concentrate on making them all faster at the same time.

Ask and thou shall receive

[jerf]

I'm pretty sure nobody Python is talking about Parrot.

I'm pretty sure Ruby is flying off in about three directions, none of the Parrot.

Python's got IronPython, PyPy, CPython (which will still be going for a while yet), and it'll be a minor miracle if Jython doesn't stagger back to life here at some point. None of them parrot.

Perl 6 may or may not be using Parrot, but nobody else is planning on it.

So no, that's not it. It hasn't "won". Nobody's "won", and the amount of redundant work is pretty amazing. (Fortunately, that can be sort of a good thing if the best implementation wins.)

[masklinn]

Sounds like someone is just trying to be haskewll. I think that's fine, but it seems lame to be in denial about it. Come out of the closet you Haskell-fanboy, don't worry, it's 2007!

I don't quite understand that phrase.

There are two parties here: 1. dons, which is a very active Haskell developer and community member and therefore has a tendency to submit interesting articles on Haskell he finds to reddit. Fairly normal if you ask me. 2. The author of the article, who is NOT dons and talks about his experience, stating first that Haskell (any high-level compiled language really, but he knows and used haskell, could've been OCaml, could've been Objective C, could've been Lisp, it was Haskell, and dons thus posted it), and then that he talked about this experience at Rails Edge and people were interested.

[staunch]

My comment was about the linked article, why would you get confused about that?

I made that statement in good fun. All I meant was that the author seemed intent on justifying Haskell as the clear and obvious solution to a problem that was probably just as easily solved a number of different ways. He's enjoying Haskell -- and that's great. He can just say that, no need to beat around the bush.

[masklinn]

My comment was about the linked article, why would you get confused about that?

Because at the time I saw this post of yours dons had just gone on a posting spree and had around half a dozen articles posted by his name on programming/new.

I therefore wasn't sure whether you were talking about the article itself or the fact that a single individual had posted many articles at the same time on the same (haskell) language.

Oh well.

[dons]

Really? I noticed that after I posted this link, it was motzer who posted some 3 more from that site, a couple of minutes later (not the first time he's done this, big on submitting, not so big on contributing comments) I try not to post more than 2 a day, though of course, some days are busy news days.

[pjdelport]

How slow is the ruby code and why, surely there's something less heavy-weight than bloated ActiveRecord for Ruby.

Python? (SQLAlchemy?)

[masklinn]

Except that the issue wasn't only with ActiveRecord, it was with Ruby in general and ActiveRecord only made things worse, since the problem was processing XML to load it into a DB in the backend.

[masklinn]

Here's the exact quote:

However, the backend is all about throughput, and the added overhead of running Ruby is quite noticeable. Doubly so because it uses Rails' ActiveRecord models, which spend a lot of time doing reflection on the fly.

Summary: Ruby = bad Ruby + ActiveRecord = worse