An open letter to my congressman and the candidates for his seat in November

Here's the text of an email I just sent to my congressman and to the candidates for his office in this November's election. I hope it does some good.

Representative Cannon, Mr. Chaffetz, and Mr. Spencer,
I am very sad to see that you voted in support of the bailout, deciding that putting vast sums of money into the hands of the already too-powerful fat-cats on Wall Street.
I believe that it is time we expected people and corporations to accept responsibility for their choices — even when the consequences are painful. As a nation, we are too quick to turn to the government to relieve us from unpleasant situations we have put ourselves in. If we can not turn ourselves from the trough, I fear for our future.
A final example of responsibility and consequences is easy to find. Continued Republican support of Wall Street over Main Street will certainly drive me, and others like me, to support other candidates in November.
Remember, there's no bailout like no bailout.

Concurrent Programming with Erlang/OTP - an early look

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.

New Improved MySQL library

MySQLPlus is a new, non-blocking MySQL driver for Ruby 1.8 and 1.9 (anyone know if it will run on Rubinius?) from eSpace, the folks who created NeverBlock. (They also talk about NeverBlockPG, a postgreSQL driver, but it seems to have been deleted.) To quote eSpace's announcement:

[MySQLPlus does] IO operations concurrently and in a transparent manner, thanks to NeverBlock. An interesting side effect emerged during the development of this driver. We were required to update the current MySQL driver to be able to do async operations. Once those were done, we discovered that the basic foundation for threaded support was there. Hence we went forward and implemented it (with help from Ruby gurus like Aman Gupta and Roger Pack). What we have now is a new general purpose MySQL driver that supports threaded access and async operations. This means that you can send queries to a MySQL server in a concurrent manner from Ruby applications. This is big news for those waiting for Rails thread safety. Finally there is a MySQL driver that can help them achieve that concurrency.

I'd love to see what alternative ORMs like Sequel and DataMapper will do with this kind of library underneath them.

Ruby and V8

Summer is drawing to a close and many of the things which have distracted me from my blog are becoming less pressing, so it's about time for me to crank this back up — we'll have to see how well I keep up with it. Of course, there are a lot of exciting things on the horizon that are prompting me to write. One of the biggest is the release of V8, the JavaScript VM that's part of Google's Chrome. Over on the Strongtalk list, David Griswold wrote:

I still think it or some derivative will quickly become the dominant dynamic language VM, for the following reasons:

• Given who the developers are, and with Google behind it, it will be the fastest JavaScript VM for a long time to come.
• For the same reason, it will be reliable and secure (as much as it can be, anyway; nothing is perfect).
• It will be supported on the three major platforms (Windows, Linux, Mac).
• It can be used with other browsers, so I'm sure it will be ported to Firefox (if only as an option). Some or all of the other browsers may also adopt it, given that it will have a very hard-to-overcome performance advantage (these sorts of VMs can't be pulled out of a hat). Although MS and maybe Safari may have too much of a Not Invented Here problem with it, as well as standards war issues.
• those things, plus the other architectural advantages it brings, will make it a primary target for serious web app development, esp. Google apps.
• So it will be ubiquitous

So it will be an irresistible platform for other dynamic languages, even if they could theoretically run a bit faster on a custom VM. Remember it will still be a lot easier to run other dynamic languages on JavaScript than it is to run them on Java, since at least JavaScript is fully dynamic, unlike Java.

I'm not the language guru that David is, but I not ready agree with him yet. While JRuby is showing good progress at creating a fast, stable Ruby implementation on top of a non-native VM, I don't think we've seen what a native, tuned VM for Ruby can really do. I'm also not sure we'll ever see Ruby's community turn away from their own VM (be it Rubinius or the 1.9 VM) for the 'standard implementation'. This doesn't mean that V8 is without value to the Ruby community though. Again, David Griswold:

The V8 development team has multiple members of the original Animorphic team; it is headed by Lars Bak, who was the technical lead for both Strongtalk and the HotSpot Java VM (as well as a huge contributor to the original Self VM). I think that you will find that V8 has a lot of the creamy goodness of the Strongtalk and Self VMs, with many big architectural improvements:

• open source
• will run (eventually) on Windows, Linux, and Mac
• dynamically JITs to native code
• can run completely independently from the browser
• generates hidden classes behind the scenes, since javascript doesn't have them (very reminiscent of the 'maps' used in the Self VM).
• is multi-threaded from the ground up, with the ability to share VM overhead between different OS processes.
• has even smaller object headers than in Strongtalk, making small object overhead even smaller
• kick-ass compacting, non-conservative garbage collector

Whether Ruby ends up on V8 or not, I'm guessing that some of V8 will end up in Ruby.