I'm using different languages for different parts of the system.
While I could probably do everything in one language, I'm not sold on the idea that that's actually a good idea (aside from developer convenience, which considering I'm the only developer I don't rate very highly). I also don't feel qualified enough as a language person to really hold defensible opinions about their relative strengths and weaknesses yet.
For example, part of the system is a network service that runs deployed on servers in our environment. All that code is Haskell. I didn't want to have to deploy and manage an interpreter or JVM on those systems, and I don't trust myself to write C that I feel confident deploying in production. Haskell seemed like a good win there (other folks might use Go, or whatever). It turned out to be really easy to write a network server in Haskell that receives the messages that the service needs to receive. Also, it was the first time I used a language that had good (or really, any) pattern matching, and I'm sold on it.
The "business" logic of the system is all currently in Racket. It could certainly have been written in Haskell, but I'm still getting up to speed in it, whereas I was able to get pretty minimal functionality up and running with Racket very easily.
Right now only the web interface is Clojure. I briefly considered using Yesod for the web piece, but it seemed really complicated. And although Racket has a nice web server, it requires buying into the "continuations" style that they advocate (or rolling your own web libraries, which seemed like a bad idea for this project).
I think the continuation-based approach for web servers is certainly valid, and maybe even technically better, but they're swimming against the tide with that approach, and as web programming is so far my least favorite part of building this system, I wasn't willing to buy into that enterprise.
Thankfully, I was able to get a Clojure web app up and running very quickly (basically just Ring and Compojure).
The system is designed where there's pretty hard boundaries between all the parts, so by the time all is said and done, it might all be written in the same language; but that's not necessarily a design-goal. I figure different languages seem to have different strengths, and there's not really a good reason for me to try and shoehorn everything into one.
If you want to try out Haskell for web development again one day ping me (email in profile) and I'll send you a copy of Snap for Beginners[1]. I'm releasing it at the end of the week and it should make getting started in web dev with Haskell easier.
Yeah, I pre-ordered your book, I look forward to reading it.
When I originally looked at using Yesod, it seemed fairly complicated for what I needed (which is basically just the crud-iest of crud apps). I'd only been using Haskell for a couple of months, and I'd never done any web programming; so I figured I should try to use something that wouldn't require quite so much "stuff".
I finally decided to try out Clojure because I'm planning on using Datomic for the main datastore (because it looks like I can have it backed by Cassandra, which lets me store all of our data in an HDFS cluster.) and the "Web Programming with Clojure" book just came out. I figured I could probably figure out a very basic database-driven view web app just by going through the book. That turned out to be true, actually, and it wasn't that hard to get my app up and running.
What dawned on me going through the book was that what seemed complicated to me really wasn't a function of the language, but the way almost all mvc web libraries seem to be laid out; and that actually once I understood how they worked, I could probably implement the same thing very similarly in almost any language that has a similar library.
So I might eventually look into making a REST api using Snap to handle the requests, and sort of encapsulating all input and output in the system with Haskell.
Have you had the opportunity to try out the GHC 7.8 release candidate yet? For network io work loads the new io manager has some great scalability. I'm actually planning on writing some distributed systems tooling in Haskell once I get my first release of numerical Haskell out, which is soon!
Happy hacking and best of luck on the business side
" Many sites are replacing inetd with tcpserver, for several reasons:
* inetd is unreliable under high loads. It cuts off service for 10 minutes if it receives ``too many'' connections in 1 minute.
* inetd does not provide effective resource management. It will happily use up all your memory if you are running a popular service.
* inetd has trouble with sudden bursts of activity. Its listen() backlog is typically only 5 or 10 and cannot be raised.
"
Personally I use tcpserver. I have an SMTP server I wrote in awk - http://www.proweb.co.uk/~matt/awk/smtpd.awk
I ran this as the main SMTP server for production web site for about 5 years.
amusingly I've just spotted a bug in the smtp code. a missing _ for logging unexpected EOF reading from the client. Not fatal but maybe useful for spotting spammers.
I've inspired myself to resurrect using this instead of Postfix for incoming mail. See if I can get it hooked up with spamassassin.
While I could probably do everything in one language, I'm not sold on the idea that that's actually a good idea (aside from developer convenience, which considering I'm the only developer I don't rate very highly). I also don't feel qualified enough as a language person to really hold defensible opinions about their relative strengths and weaknesses yet.
For example, part of the system is a network service that runs deployed on servers in our environment. All that code is Haskell. I didn't want to have to deploy and manage an interpreter or JVM on those systems, and I don't trust myself to write C that I feel confident deploying in production. Haskell seemed like a good win there (other folks might use Go, or whatever). It turned out to be really easy to write a network server in Haskell that receives the messages that the service needs to receive. Also, it was the first time I used a language that had good (or really, any) pattern matching, and I'm sold on it.
The "business" logic of the system is all currently in Racket. It could certainly have been written in Haskell, but I'm still getting up to speed in it, whereas I was able to get pretty minimal functionality up and running with Racket very easily.
Right now only the web interface is Clojure. I briefly considered using Yesod for the web piece, but it seemed really complicated. And although Racket has a nice web server, it requires buying into the "continuations" style that they advocate (or rolling your own web libraries, which seemed like a bad idea for this project).
I think the continuation-based approach for web servers is certainly valid, and maybe even technically better, but they're swimming against the tide with that approach, and as web programming is so far my least favorite part of building this system, I wasn't willing to buy into that enterprise.
Thankfully, I was able to get a Clojure web app up and running very quickly (basically just Ring and Compojure).
The system is designed where there's pretty hard boundaries between all the parts, so by the time all is said and done, it might all be written in the same language; but that's not necessarily a design-goal. I figure different languages seem to have different strengths, and there's not really a good reason for me to try and shoehorn everything into one.