Thoughts on Erlang
Over the weekend, I've been playing around with Erlang. I started off with Joe Armstrong's excellent book and then descended into a text editor. As has been my habit for the last few weeks, I started off by trying to write a client library for Windows Azure (which you can see in its current non-working state here.
- First of, I'm blocked from completing my library because Erlang doesn't seem to have sha 256 support built-in. Or rather, it seems to be commented out and though there are a couple of questions on the mailing list, there is no clear indication for why this is the case. Since Windows Azure uses HMAC-SHA-256 for its authentication, I'm hosed. Of course, I could try and implement sha 256 support but that really isn't my cup of tea :-)
- Every language has a culture surrounding it, a purpose it shines at. For Perl, this is text processing. For VB, it was business applications. Erlang shines in concurrency and writing fault-tolerant and distributed applications. In fact, I wish I had discovered Erlang when I was trying to high performance networking code a while back - it makes things very, very elegant
- Erlang's abstractions for concurrent and distributed programming are to be marvelled at. I was blown away by how easy it is to launch a process in a remote machine and play with it easily. There's a section in the book where Armstrong talks about how he launches erlang nodes on machines without having made up his mind on how he's going to use them. That's very, very remarkable and I would love something similar in the managed family of languages.
- The language seems awkward and dated. I still can't intuitively remember where to place a semi-colon, a comma or a period. The language doesn't 'feel' modern
- The documentation is sorely lacking. I've been spoilt by my time in Python, Ruby and C# where searching on the web will almost always get you the right result while you hit a one-line method documentation in Erlang.
Comments:
<< Home
As an small aside, working w/ Azure Storage would be easier if it supported standard HTTP Authentication (i.e. Basic and Digest). This would require support for MD5 encryption, but that is easier to handle than SHA 256 (see http://sacharya.com/?p=22 for a straight forward implementation).
Actually, I've found the Erlang documentation to be both plentiful and generally excellent; you just need to coax Google into cooperation by augmenting queries with e.g. "site:erlang.org inurl:doc".
Once you have the basics down, the library man pages (also accessible via erl -man [page]) are very useful.
http://www.erlang.org/doc/man_index.html
Fortunately it's easy enough to construct the URLs by hand:
http://www.erlang.org/doc/man/[module].html
http://www.erlang.org/doc/man/lists.html
Once you have the basics down, the library man pages (also accessible via erl -man [page]) are very useful.
http://www.erlang.org/doc/man_index.html
Fortunately it's easy enough to construct the URLs by hand:
http://www.erlang.org/doc/man/[module].html
http://www.erlang.org/doc/man/lists.html
Maybe these old SHA patches will help you?
I also agree with the comment that Erlang documentation is plentiful. Just keep a tab open to the Erlang man pages and you're golden.
Finally, many n00bs complain about the syntax being old or crufty, but in actuality it's simple. There are so few syntactical variations in the language that the syntax quickly becomes trivial as you write more code. I'd take Erlang syntax over just about anything.
I also agree with the comment that Erlang documentation is plentiful. Just keep a tab open to the Erlang man pages and you're golden.
Finally, many n00bs complain about the syntax being old or crufty, but in actuality it's simple. There are so few syntactical variations in the language that the syntax quickly becomes trivial as you write more code. I'd take Erlang syntax over just about anything.
@Steve - thanks, I saw these patches too ( i referred to them in my mail to erlang-questions). However, they make it hard for me to distribute my code (since this is essentially a client library for others to use). I think I'm starting to agree with you on the syntax - I'm actually beginning to enjoy it more now
@Christian - thanks for the tip! Actually, I was talking not of the straight doc/man pages but about blog posts, mailing list questions et. al. I find things a lot easier in more 'mainstream' languages. However, I'm sure this is just a function of time - I remember Python and Ruby being the same a few years ago
@mamund - I'm not sure how secure that would be (since md5 is pretty weak and conflicts are known to exist). Also, both would require the use of SSL which is also a problem
@Christian - thanks for the tip! Actually, I was talking not of the straight doc/man pages but about blog posts, mailing list questions et. al. I find things a lot easier in more 'mainstream' languages. However, I'm sure this is just a function of time - I remember Python and Ruby being the same a few years ago
@mamund - I'm not sure how secure that would be (since md5 is pretty weak and conflicts are known to exist). Also, both would require the use of SSL which is also a problem
@Steve - btw, I'm a big fan of your blog and learnt quite a bit of Erlang from it. I'm super thrilled to see you here :)
I understand about collision issues w/ MD5. SHA-1 is not w/o problems and is still in use, too. Its good to see the use of SHA-2 gaining ground. While fixing HTTP Auth is out-of-scope for Azure Storage, I think building a service which has the greatest reach should be a primary goal. Custom authentication bound up w/ request-signing is, IMO, not a positive response to the limits of MD5.
Also, I appreciate the Azure team's efforts to secure content. I think request-signing is an excellent way to protect *servers* from attacks. I suggest the best way to accomplish data security is through TLS.
Finally, thanks again for continuing to post your examples. They are very instructive and an excellent way to test out the 'portability' of Azure storage.
Also, I appreciate the Azure team's efforts to secure content. I think request-signing is an excellent way to protect *servers* from attacks. I suggest the best way to accomplish data security is through TLS.
Finally, thanks again for continuing to post your examples. They are very instructive and an excellent way to test out the 'portability' of Azure storage.
@Steve - wonderful! I took your code and implemented hmac on top of it. I'll clean this up and post it tomorrow. I hope you don't mind your module lyring around in my github repo
@Sriram: I'm glad you can use the code, do with it whatever you like. If there are any changes you'd like to see, let me know. For example, I wasn't sure what the best type to return from digest/1 would be, so if you'd prefer a different type I can change it.
@Steve - Working implementation at http://github.com/sriramk/winazureerl/tree/master/src. Will blob about it tonight. Thanks a ton - couldn't have done it if you hadn't pushed me with that sha module. I was feeling lazy but with your code, I had no excuses :-)
Post a Comment
<< Home
Archives
November 2004 January 2006 June 2006 July 2006 August 2006 September 2006 October 2006 November 2006 December 2006 January 2007 February 2007 March 2007 April 2007 May 2007 June 2007 July 2007 August 2007 September 2007 October 2007 December 2007 January 2008 February 2008 March 2008 April 2008 May 2008 June 2008 July 2008 August 2008 September 2008 October 2008 November 2008 December 2008 January 2009 April 2009 May 2009


