Erlang and perl - my favorite tools (erlperl? perlang?)
The two languages I am most comfortable with nowadays are erlang/OTP and perl - which, strangely enough, makes me quite remarkably non-conflicted. The key, I guess, is that they are so different, with the core use-cases being so fundamentally distinctive, that there really isn't that much of a context switch for me to move from one to the other. And, of course, given their radically different natures, I rarely (never?) ever use one when I should have used the other.
Erlang/OTP, of course, is your classic massively concurrent fault-tolerant distributed infrastructure language, which pretty much gives you all the aforesaid buzz-word properties by default. You have to work, and quite hard at that, at making your system behave badly.
I could go on and on about why its the greatest thing ever, but others have done it far better (e.g. John Bender here or Alex here), but I will say that once you have tested the beauty of the built-in concurrency, supervision and hot-code-loading, it is really, really difficult to go back to, well, anything else.
Perl, on the other hand, is pretty much guaranteed to die if you do anything huge. It'll find new, interesting, and fascinating ways to crap out, and if you are writing any kind of long-lived code in it, you will end up
(a) writing mad-defensive code, and
(b) finding new ways for stuff to crash over the first few months that your code is live.
All that said, however, if you want do get some rapid string manipulation done - parse a file, transform some data, etc. - you can't beat perl.
Really.
In fact, they call 'em perl style regex for a reason :-)
(As a side note, one pretty much never writes defensively in erlang, you really want your processes to die, quickly, expeditiously, and gloriously. )
Which naturally brings up this old xkcd
of course, s/lisp/erlang/i; :-)
On an interesting side-note, one of the under-represented advantages of erlang is efficiency. Because of its built-in concurrent/loosely-coupled nature, you will end up being able to access swathes of your CPU capacity that were heretofore off-limits with the sheer number of simultaneous "things" that you can be doing is somewhat astounding.
I know, I know, your Java code pegs all your cores too, but do you really want to get into a discussion of what exactly is going on in your system there? Seriously?
Which obviously leads me to perl - in many ways you are at the exact opposite end of the spectrum here. I've got perl daemons that I've written that have been up for years, but as you might imagine, the sheer amount of defensive cruft that is embedded in these daemons makes them one of the most frightfully inefficient pieces of code that I've ever had the privilege of being around. Then again, it has been up for years, so thats worth something, right?
Which, in a round-about way, gets me back to my original point, i.e., why erlang and perl. The thing is, writing massively scalable systems is hard. If you are going after concurrency - and odds are that for massive scalability, you will be going after concurrency - it is a right-royal PITA to do.
Oh of course, you can do it - here is a nice tutorial on getting there with Java - but frankly, you could be coding in assembler too if you so wanted.
Erlang/OTP, however, gives you this concurrency by default! You don't need to screw around with mutexes, semaphores, synchronized, thread safety, and all the associated insanity - It Just Works.
Given this, and given that I have just so many hours in my day, I'd much rather spend my time doing actual stuff, as compared to building and testing concurrency scaffolding.
Perl, on the other hand, can be used to do pretty damn much anything (including concurrent programming) - after all, the perl mantra is There is a library for that. That said, with the exception of people who have way too much time on their hands - or don't know better :-) - the sweet spot is short simple programs and one-liners that you use to just Get Things Done. Because, again, whatever it is that you want to do, there is a library for that.
And it works pretty damn well, even if it looks like something the cat barfed up.
Erlang and Perl - the two main components of my programming toolbox...
(It will never be cool)
I could go on and on about why its the greatest thing ever, but others have done it far better (e.g. John Bender here or Alex here), but I will say that once you have tested the beauty of the built-in concurrency, supervision and hot-code-loading, it is really, really difficult to go back to, well, anything else.
(a) writing mad-defensive code, and
(b) finding new ways for stuff to crash over the first few months that your code is live.
All that said, however, if you want do get some rapid string manipulation done - parse a file, transform some data, etc. - you can't beat perl.
Really.
In fact, they call 'em perl style regex for a reason :-)
(As a side note, one pretty much never writes defensively in erlang, you really want your processes to die, quickly, expeditiously, and gloriously. )
Which naturally brings up this old xkcd
of course, s/lisp/erlang/i; :-)
On an interesting side-note, one of the under-represented advantages of erlang is efficiency. Because of its built-in concurrent/loosely-coupled nature, you will end up being able to access swathes of your CPU capacity that were heretofore off-limits with the sheer number of simultaneous "things" that you can be doing is somewhat astounding.
I know, I know, your Java code pegs all your cores too, but do you really want to get into a discussion of what exactly is going on in your system there? Seriously?
Which obviously leads me to perl - in many ways you are at the exact opposite end of the spectrum here. I've got perl daemons that I've written that have been up for years, but as you might imagine, the sheer amount of defensive cruft that is embedded in these daemons makes them one of the most frightfully inefficient pieces of code that I've ever had the privilege of being around. Then again, it has been up for years, so thats worth something, right?
Oh of course, you can do it - here is a nice tutorial on getting there with Java - but frankly, you could be coding in assembler too if you so wanted.
Erlang/OTP, however, gives you this concurrency by default! You don't need to screw around with mutexes, semaphores, synchronized, thread safety, and all the associated insanity - It Just Works.
Given this, and given that I have just so many hours in my day, I'd much rather spend my time doing actual stuff, as compared to building and testing concurrency scaffolding.
Perl, on the other hand, can be used to do pretty damn much anything (including concurrent programming) - after all, the perl mantra is There is a library for that. That said, with the exception of people who have way too much time on their hands - or don't know better :-) - the sweet spot is short simple programs and one-liners that you use to just Get Things Done. Because, again, whatever it is that you want to do, there is a library for that.
And it works pretty damn well, even if it looks like something the cat barfed up.
Erlang and Perl - the two main components of my programming toolbox...
Comments