This year I had an opportunity at my job to design a fairly large system under some (what seemed to me at least) pretty ideal circumstances: 1.) We didn't have

This year I had an opportunity at my job to design a fairly large system under some (what seemed to me at least) pretty ideal circumstances: 1.) We didn't have any existing infrastructure, so there were no requirements around language, environment, or tooling. 2.) I was the only person who would be developing the system. 3.) I was predominantly the only person who would be interacting with the system once it was deployed. 4.) Existing solutions to the problem I'm trying to solve are generally very expensive (either directly through the cost of the software, or indirectly through having to have professional services consultants do the integration), so it was pretty easy for this project to prove it's worth. 5.) I'm not actually paid to be a developer, so if the whole thing turned out to be a dismal failure, my boss doesn't care. So I used this project as an opportunity to try out Haskell and Racket, two languages I didn't have any prior experience with (I had learned Scheme in school through SICP but hadn't touched it in 15 years). I settled on Haskell for the parts of the system that were going to be deployed out in our environment. So far, that's been a server that collects events, parses them, and then forwards them along. I liked that Haskell compiled to native code (I didn't want the additional complexity of dealing with deploying an interpreter or virtual machine). I looked at using C and Go as well, as they both met all my criteria. Go doesn't really do anything for me, which admittedly isn't a great reason for not using it, but as I didn't have to sell anyone else on my decisions, that was enough. C is actually a more conventional fit for the type of server I built, and the only reason I didn't go with C is that I honestly don't trust myself to write performant, safe, C that I'd be comfortable deploying all around my enterprise. That's not an indictment of C, it's an indictment of my abilities as a programmer. Thankfully, I'm not really a programmer, so I can still sleep at night. In writing the server piece in Haskell, I discovered that most of my worries about it being an esoteric academic language were unfounded. I think most of that reputation comes from the fact that a large portion of the community using it is academic, so they use it for academic things, and tend to talk about it using "computer science-y" terminology. The Haskell planet blog aggregator, for instance, I've almost never found to be comprehensible. That's not their fault though, it just doesn't seem like muggles are writing blog posts about using Haskell to solve real problems. Hopefully that'll change over time as the language becomes more wide-spread. I was very impressed with using Haskell to parse events though; I think I'm ruined on ever going back to a language that only lets you use RegEx's. I was worried about how usable Haskell would be for really cookie-cutter systems type programming, as there isn't a lot of material online to help you do that type of stuff. Real World Haskell turned out to be a super good book though, as it was much more closely aligned with what I was doing. I was also worried about the small number of libraries compared to 1st-tier languages, but for what it's worth, that hasn't really been an issue. If I were a good Haskell programmer, I'd have no qualms about using it for everything, but I'm not (at least not yet), so I'm doing all the application logic and web UI stuff in Racket. Obviously, people use Haskell for web programming, and it seems like Yesod is getting much better, but it was much easier for me to get a simple web application thrown together with Racket, so that's at least what I'll be doing for the time being. My experience with Racket has been similar: not many resources on people actually using it to solve real problems, not many libraries; but for doing a really simple CRUD web app that talks to Postgres, it wasn't too bad to get working. The community is really great, maybe as a testament to its size, but I've been impressed by how helpful they are. Deciding to use Racket over Clojure was a tough decision. Ultimately it came down to the fact that there was less cognitive load for me in how Racket worked when I didn't also have any of the Java infrastructure underneath. I think one of Clojure's greatest strengths is that it gives you all the interoperability with the Java ecosystem (which I think is one reason for it's adoption); but I've never programmed in Java, so all of that familiarity isn't present for me; it just seems like an albatross. Even all the tooling around builds and deployment seemed like a lot to get acclimated to, although I'm sure if I had just gone ahead and used Clojure, I'd have figured all that stuff out. I'm envious of the fact that a lot of Clojure's libraries seem to be created by people solving concrete problems, and in general I like the pragmatism of that community. Maybe eventually I'll move from Racket to Clojure, but I haven't yet tried to do anything in Racket that makes me regret having chosen it.