On Ruby

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 Referencefrom the Pragmatic Programmers was what got me started with language development, although I no longer use ANTLR.

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 :)

Click here to Tweet this article

What's this? A page about Functional Programming languages at On Ruby? Well, I've written about a number of non Ruby topics here, and there's enough FP stuff to warrant it's own page.

At one point, I also ran the On Erlang blog. I've decided to merge all of my computer related posts into On Ruby to keep myself sane.

I've looked mostly at Scala, Haskell and Erlang, with news, book reviews, and interviews about both. There's some OCaml stuff coming as well.

If you're a Rubyist looking to expand your horizons, there's probably something here for you. If you don't care about Ruby at all, don't let the blog's name scare you away.

I've probably done the most work in the Erlang community. I'm a pure beginner when it comes to writing Erlang code, but I like a lot of what I've seen and read. The community itself is especially nice. Here are some of my best (or most popular) posts about Erlang:

• Getting to know erlang-mode
• Practical Erlang Programming Mini Interview is a bit old, but it's a good conversation with two of the authors of O'Reilly's upcoming book.
• Concurrent Programming with Erlang/OTP - an early look — this one covers the book Manning has in the works.
• Reia- A New Dynamic Language on the Erlang VM is an interview with Tony Arcieri about his new language.

I've spent a little time learning more Haskell. The language intrigues me and the community is pretty strong as well.:

• Book Review: Real World Haskell — just what it says.
• Author Interview: Real World Haskell is an interview with the three authors of this great book.

• Real World Haskell: Pre-Reading Survey — before I read the book, I did a quick survey to think about what I wanted to learn from it.

Scala is a nice looking language that lives on the JVM. I've done some interviews with Scala book authors. I think I'll be getting some additional posts here soon.:

• Beginning Scala -- Author Interview with David Pollak
• Dean Wampler and Alex Payne: Author Interview
• Author Interview: Venkat Subramaniam

O'Reilly is at it again, getting an open content book out there to cover an emerging technology. This time it's Relax with CouchDB by Chris Anderson (@jchris on twitter), Jan Lehnardt (@janl on twitter), and Noah Slater (@nslater on twitter) -- the book is also available as a rough cut, if you'd like to support O'Reilly and the book.

Last spring, Jan came out to MountainWest RubyConf to talk about CouchDB, and I've been interested ever since. Now that the book was on the way, I asked Chris, Jan, and Noah to sit down for a quick interview. Here's how it went:

---

I know this is the title of your first chapter, but I feel like we should start things out with it here too: Why CouchDB?

Noah I'm a bit of a hypertext fetishist. Serving up documents via HTTP is great, but I became interested in CouchDB because it lets me serve up documents, and then lets me edit them too! There are a few other technologies, like WebDAV, that let you do that over HTTP, but here is this amazingly elegant solution that doesn't require protocol extensions or any other annoying cruft.

Of course, CouchDB also happens to be a very powerful database! A document database isn't for everyone, but if your application revolves around organising and serving up documents, CouchDB hits a real sweet spot.

Chris I'm pumped about CouchDB because it has the potential to make a bunch of new freedom. It's replication feature make offline databases at least as powerful as hosted data. Because everyone already knows the API (whether they've heard of it or not) writing apps on it is (will be) child's play. I say "will be" because right now we're on the edge of it. CouchDB is not yet 1.0 so we are still learning how to write apps against it. I am focussed on finding the simplest path from user to documents. Ajax seems to be the answer.

Jan I gave a few presentations on CouchDB. In the introduction, I usually ask who has built database-backed web applications. I usually get 80-90% hands. I follow up with "... and who likes it and doesn't have any issues with the database?". Most hands go down and I get a few laughs.

This is a nice skit to start a presentation with and win an audiences sympathies, but it is also giving RDBMSes a bad reputation, which they do not really deserve.

Today, relational databases are used everywhere on the web (where I'm coming from). For a long time they were the only sensible choice to solve a lot of the problems you get with concurrent access to your data in a high-traffic manner. But as demand grows, relational databases begin to be used in ways they were not intended to. JOINs are broken up, data is de-normalized. Disk space and insert-speed is sacrificed for concurrent read-speed etc. They are no longer the ideal technological choice.

CouchDB is built for the web scenario. Storing huge amounts of semi-structured data is the default case in CouchDB. It makes excellent use of modern multi-core machines and multi-machine setup. CouchDB views are built using Map/Reduce, the concept that made Google. Replication allows a user to take data offline and work with it locally, without a network connection; and it can be used to synchronize machines in a load-balanced or highly-available setup or both. And the HTTP REST API makes talking to CouchDB as easy as opening a browser.

And it is written in Erlang which gives us high concurrency (20k requests per second on a single machine?), fault tolerance and live code-upgrades. Erlang is worth an entire interview in itself.

Oh hey, that isn't exactly a concise answer and I didn't even tell you half of the good stuff :-)

You're approaching this book in a very open fashion (the book is online and available as you write it). How did you convince O'Reilly to go that way?

Jan We are developing CouchDB. Writing documentation comes with development. We figured that if we have to do the writing anyway, we don't want to do it twice.

O'Reilly is pretty open about (heh) open books. They have the Subversion book that everybody knows and recently released a book on Haskell. They have experience doing this kind of thing and they have seen good results in the past. When we asked about the possibilities, they just said "sure".

Chris As Jan says, it wasn't hard. O'Reilly understands the value of open information, and the value proposition around publishing, which is part of why they've done so much to enter the wider arena of sharing ideas.

JanNoah ultimately pushed us in the direction of writing the book in the open. Once decided, I couldn't see it done any other way and I am glad for the pushing.

Noah We had been talking about doing a book for a while and I was always very adamant that whatever we did would be released under a free license.

The biggest deficiency in free operating systems is not in the software—it is the lack of good free manuals that we can include in these systems. Many of our most important programs do not come with full manuals. Documentation is an essential part of any software package; when an important free software package does not come with a free manual, that is a major gap. We have many such gaps today.
—Free Software and Free Manuals, Richard Stallman

Since Stallman wrote this essay, the technology publishers have started to wake up a little bit. A growing number of manuals and books are being released under free licenses, and this is absolutely marvellous. O'Reilly is really leading the way on this, so we were very lucky to get a deal with them.

Our editor told us a surprising rule of thumb, that releasing a good book under a free license makes it sell more copies, and releasing a bad book under a free license makes it sell less copies. Let's hope that we are the former!

What benefits do you expect from this approach?

Chris For me, the hardest part is knowing what people just learning CouchDB will need to know. The authors mostly communicate with people who already understand and use CouchDB, but I'd like the book to be capable of drawing you in, even if you're new, so that you feel comfortable building Couch apps.

Noah I am very lucky to be writing the book with two people a lot smarter than me. When I make mistakes or write something a little silly, I get corrected. Similarly, when you develop something in the open, you get all these really bright people reading your stuff and picking you up on things that you've missed or didn't think about properly. Open collaboration is hugely beneficial like that.

Jan That the world fixes our typos. Oh wait, no! Actually, that's what our editor will take care of. You saw in my answer to the "Why CouchDB" question that it is not a one-liner. Add a very diverse potential readership and you get even more ways to put things We can't cater everybody, but we are trying make this book worth a read for a lot of people, from developers to administrators, system architects and hardcore RDBMS lovers.

By opening the writing process, we get decent feedback very early on and as a result will produce a much better book. Besides, we have been open source developers since forever, we just couldn't do it any other way. Release early, release often.

So far there's been a lot of feedback on the book's mailing list. How is that affecting your writing process?

Jan In early drafts you know that there are passages that try to explain an idea and that these passages don't make a good job. If you know the topic at hand pretty well, you might not notice immediately. Public feedback will tell you pretty quickly what works and what doesn't and that helps with the review proces. The writing process, at least mine, is not really affected.

Noah I think the most significant thing I have taken away from this process is the level of confusion caused when trying to compare CouchDB with traditional databases. I mean, fundamentally, this comparison makes about as much sense as comparing cheese and bread. Sure, you can eat both of them, and one may be applicable in one situation and not in the other, but they also taste really nice when you put them together. That's kind of how I see the CouchDB versus RDBMS debate. Meaningless, essentially. CouchDB isn't a panacea, nor are relational databases, and both of them have their uses. I think we're going to work on improving this clarification in the book.

Having said all that, we've only been taking comments for five days now and the response has been just overwhelming. Who knows what other issues, or points of confusion we're going to find along the journey? I'm pretty sure whatever happens, it's going to be just as rewarding. Thanks for the input everyone!

Chris I've been happy about how people are reacting to the figures. I basically hand-sketched some basic drafts of technical drawings for the book. I was thinking, "what's the simplest thing that could possibly work?" and some of the drawings were even captured with the iPhone built-in camera.

I was surprised because people seemed to like the hand-made feel. I've started refining that style, with the rough drafts for the code-example sections. I'm a big fan of the Head Rush books, so I'm hoping that when O'Reilly brings their artists in, they can approach it with the same playful style.

You've posted three chapters of the book already. What should we be looking for next, and how soon should we be seeing it?

Noah We're aiming to submit another six chapters to O'Reilly in early January, so you should see things trickle through to the website as we complete that process.

Jan We are aiming some time in January for the next batch. We are trying to do the book sequentially and the ToC is online already, so you can see what's coming :o)

Chris We're working on a description of the example blog application we'll be releasing. The app right now is pure-Ajax, but by the time CouchDB hits 1.0, we'll be able to do major portions of it without JavaScript at all. CouchDB it getting HTML generation capabilities so expect that to change some of how we build applications.

What kinds of projects should developers be looking at CouchDB for?

JanAfter my talks or in discussions with developers I often get asked what "niche" CouchDB fits in. I usually say "The Web" and that's me trying to be funny again because the web is nowhere near a niche.

Everything that stores messy data that users (no offence) submit (Facebook, flickr, YouTube etc.) and need efficient access to that data. Systems that handle document structures (CMSes, Blogs ... ). Situations where offline-work is preferable. The internet is available everywhere, except when the Wifi is not working or the hotel charges 5ドル a minute. Not using The Net to get to your data is usually faster, too.

Finally, database are a fairly boring topic (among non-database nerds). CouchDB makes databases fun again.

Chris Yes and +1 to that, Jan!

Look at replication, think about the new opportunities it opens up. Think about applications with the power of the desktop (and location) but written in the language of the web. HTML, JavaScript, REST, JSON, these have become essentially the lowest-common denominator for web services. When offline mode is not a service downgrade, and the source code is at the desktop, people have new affordances. I'm hoping Couch apps become the new Excel macro.

While CouchDB is written in Erlang, there are a lot of libraries to use it from other languages. Which ones have you dealt with? What's good and bad about them? Which ones will show up in your book?

Chris We're concentrating on the HTTP API for the book, so most of our examples are written in JavaScript or Curl. However, there are good libraries in most languages these days, so to the extent a language handles dynamic JSON-like objects well (and can access HTTP) it's a good fit for CouchDB.

Jan I think I wrote three PHP libraries and only one didn't completely suck, but that were the early days. There is the excellent (documented, unit-tested) PHPillow that has been extracted from a real-world project, which is always a good thing.

I used couchdb-python by our very own contributor Christopher Lenz for a number of projects now and it is very solid. If you are more of a Twisted person (heh), David Reid hosts Paisley.

Good and bad? CouchDB introduces new paradigms and we are still in the process of finding out what client-library abstractions work best (hint, ActiveRecord doesn't work well at all). Like all pioneering, this includes some stabbing in the dark. But in general, the libs I've seen are at least well suited for a single job or class of jobs. Maybe there is no one library to rule them all. We'll find out.

If you want to get into CouchDB (and Erlang) what's the best way to learn?

Jan For CouchDB, you don't need to know any Erlang. If you are familiar with the web, you are good to go. Start out by reading through the wiki and of course our book (*cough*). For more specific and tutorial style documentation, check Planet Couch, it aggregates CouchDB related blog posts and includes already a wealth of information.

If you still want to get into Erlang, there is Thinking in Erlang 30-page free PDF that gives you rough overview. For deeper diving, Joe Armstrong, Erlang's inventor, wrote an excellent book Programming Erlang which is a fun read and packed with all you need to set out writing your first (and second) applications.

Chris I learned Erlang by working my way into CouchDB's source code, based on my experience with the HTTP API. The HTTP callbacks are easy to find, and since you already know what they do, its a good way to learn Erlang. There are plenty of ways to get into CouchDB without touching Erlang — we're working on a feature that allows you to write arbitrary controller logic in JavaScript, so really, you can customize CouchDB, as well as use it, by programming any language that understands JSON.

I just got an early look of the first five chapters of "Concurrent Programming With Erlang/OTP" from Manning. At first glance, this looks like a great book to get started with. The book's home page claims:

This hands-on guide is perfect for readers just learning Erlang or for those who want to apply their theoretical knowledge of this powerful language. You'll delve into the Erlang language and OTP runtime by building several progressively more interesting real-world distributed applications. Once you are competent in the fundamentals of Erlang, the book takes you on a deep dive into the process of designing complex software systems in Erlang.

So far, the chapters I've seen are still in the shallow end of the pool, but I think they hold a great deal of promise. I can't wait to see the later chapters in the book. I've been talking with Manning about doing some interviews with the authors. Post your questions here, and I'll ask the best of them.

There are two conferences that I’m not going to be able to go to this summer that I really wish I could find a way to swing: The Erlang eXchange which will be in London on June 26-27 and The Ruby Hoedown in Huntsville, Alabama on August 8-9.

Erlang was a hot, swirling subcurrent at the 2008 MountainWest RubyConf. I get the feeling that there’s going to be a growing culture of cross-over between the Ruby and Erlang worlds. The Erlang eXchange is a two-track conference with a number of great looking talks covering topics like: Erlang D-Trace, Robotics and Erlang, Web programming and AJAX with Erlang, and Erlang Refactoring. The one shining light is that I’m hearing rumors of a Silicon Valley edition of this conference next April.

The Hoedown was a great success last year (check out the videos to see just how cool it was). And this year looks to be a great follow-up. With keynotes by David Black and Chris Wanstrath and talks about mocking, testing, and Ruby best practices, this should be a great way to improve everyone’s Ruby hacking skills.

Sorry I’ve not updated things in a bit, I’m hanging around the fringes of the flu and trying to play nurse for my family while they all suffer through it. In the meantime, I’ve let a lot of little things pile up and need to get them off my chest.

First, I’m really excited by Gregory Brown’s new status as a Ruby Mendicant. Even better is that Ruby Central is going to match donations up to 5,000ドル. Gregory will do a great job working for the Ruby Community. (Look for an article over on Linux Journal sometime soon with more details.)

Second, I’m very happy to announce that Ruby Central has been selected as a mentoring organization for the Google Summer of Code again in 2008. I’ll be acting as the coordinator again this year. We should have an idea page up by the end of the week, so if you’ve got ideas to share, or are interested in being a mentor or student, feel free to contact me. (If we’ve already traded email about this, look for an update from me in the next day or two.)

Third, MWRC 2008 is just around the corner. It’s bigger and better than last year, and I can’t wait. Registration has been held open until Wed. March 18th. If you’re not already signed up, this is the time.

Fourth, I’m really happy to announce that Engine Yard will be the first commercial sponsor of On Ruby. I’m a big fan of EY, and I love the things they’re doing in the community. They’re not going to have any editorial control of the blog, so don’t expect any changes unless it’s a bit more frequency in posting.

Fifth, I’ve been approached by a publisher to be a reviewer for a new book on Erlang. They’ve agreed to let me blog about the process and invite community feedback. I think this is a really cool opportunity, and I can’t wait to get things rolling. (Look for most of my posts about this to happen over at On Erlang though.)

Finally, I’m doing some reading and will be doing some reviews in the near future. The four books getting the most of my attention are:

• Building a Monitoring Infrastructure with Nagios
• Practice of System and Network Administration
• Ruby Programming for Medicine and Biology
• The Ruby Programming Language

The big question becomes which to do first. To help answer that, I’ve started a poll over in the column on the right. Let me know what you’d like to see.

Over on my On Erlang blog I’ve been writing about a book that O’Reilly will be publishing soon, “Practical Erlang Programming”. There’s still no official announcement, but both the editor and the authors have confirmed the book to me and have talked a bit about why they’re writing it.

Jan Henry Nystrom and Francesco Cesarini, the authors, have been kind enough to continue our discussion, and with the interest in Erlang within the Ruby community, I thought I’d post this discussion here.

---

One topic that a lot of people seem to be interested in is interfacing Erlang with other languages. Is this really a good idea?

Francesco Of course. You need to use the right tool for the right job. Erlang is good with server side applications, including concurrency, distribution and fault tolerance. There are, to mention but a few, instances where you need number crunching applications, layer 3 switching software, elegant graphical front-ends or client software… Then Erlang is not the right tool. Instances when we’ve interfaced Erlang to other languages in our line of work includes interfacing legacy code, third party protocol stacks and drivers.

How deeply will you be covering it?

Francesco We have a whole chapter dedicated to it, concentrating on C, Java and Ruby. It should be enough to get users started.

Henry But we will only cover the basics, and it is a topic worthy of a much larger exposure in another book. The “Hard core Erlang” book by Joel was supposed to give it much attention, which is but one of many reasons it is a pity his is not contuing the project.

Haskell has had pretty good representation at OSCon the last couple of years. Do you know if anyone submitted talks or tutorials for this year? Do you think Erlang will ever develop a presence there?

Henry I think that Erlang is one of the natural topics for OSCon. It has probably lagged a bit their since the USA is behind in the adoption of Erlang compared to Europe, a situation that I think will change dramatically over the next two years.

Francesco We submitted an Erlang tutorial proposal at OSCon, and really hope it will be accepted. I would not be at all surprised if other proposals show up, shows up as Erlang seems to be covered in all major conferences these days. Joe Armstrong is speaking at QCon in London next month, while Alexis Richardson, founder of one of the companies sponsoring RabbitMQ (An Erlang AMQP implementation) will be a track host. There will be an Erlang workshop in conjunction with ICFP in Victoria, BC in September, as well as an FP developer conference with tutorials covering most FP languages and tools, where Erlang is obviously included.

Most exciting of them all, however, is the Erlang Exchange which will take place in London the 26th and 27th of June this year. Two days filled with great Erlang presentations and tutorials. Last year, arranging something of this Magnitude anywhere other than Stockholm would not have been possible or viable.

I recently picked up a beta copy of Programming Erlang: Software for a Concurrent World to go along with my (paper) copy of Programming in Haskell. I figured if I had both books, I could make quick runs through them as I try to decide between Haskell and Erlang as the FP language I'm going to focus on this summer. What follows isn't really a review of either book, just a few first impressions.

[フレーム]

Programming Erlang: Software for a Concurrent World looks like to be a very accessible book, that also goes into enough depth to be worthwhile. The version I got yesterday had 279 pages in the PDF, but an update was released today and my new copy hasn't found it's way here yet. I like what I've read of Joe Armstrong's writing and examples, and have caught on quickly to the initial concepts.

[フレーム]

Programming in Haskell surprised me by being really small, only 171 pages (including the index). It on the scale of 'The C Programming Language', and so far it reminds me a lot of that book. I have to admit though, that I've always been put off by the seeming need of Haskell writers to use 'special Haskell characters' in their text, Programming Haskell even includes a table of 15 such symbols and how to represent them in ASCII. Bleargh!

So far, I'm leaning towards Erlang (mostly because of concurrency), but I'm not going to make up my mind for a while yet — too many other deadlines I need to deal with right now. As I get closer to the summer, I'll let you know which way I decide to go. (I'll also get real reviews of the two books up fairly soon.)