Over the last seven years I’ve primarily been working in Ruby on Rails. I’ve spent time working at startups and large enterprises on some of the most significant Rails apps in production. The consulting company that I lead as CTO, Stack Builders, spends more time writing code in Ruby than in any other language, and we know that our clients are happy with the way that we’re able to meet their needs with the code that we produce.

Even so, when we launched the new version of our company’s web site, we decided to do so in Haskell rather than in Ruby. After the launch of the site (which didn’t take much longer than it would have using Ruby), we’re happy with our decision. Furthermore, we’re excited that 2014 is going to be a year where we put a substantial amount of our resources into both open-source and client project development in Haskell.

Since I started writing software, the developers who influenced my own perspectives and craft the most were the ones who chose tools and processes that allowed them to best deliver products to meet their clients’ needs. I have Ruby projects in git from before GitHub was founded, and I adopted TDD and BDD as a core part of my development practice along with the developers that I respected in the Ruby community. Along with the most effective Ruby programmers, I spent (and continue to spend) a lot of my time writing and teaching how to write effective tests to help assure that code is bug-free, while keeping productivity high.

The reality is that the practices that we spend so much time focusing on in the dynamic programming world have evolved to make up for essential shortcomings of our tools. It’s unfortunate that Ruby can’t help us to find the most glaring errors in our code until we run it, and even the most painstakingly created test suites often miss errors that would have been caught by type systems in languages such as Haskell. As programmers, we have a responsibility to pay heed to best practices, and when even these don’t give us the desired results, we must look to other tools that help us to more effectively meet the needs of those who depend on our products.

In the last few years a zeitgeist of the programming world has been the adoption of practices from the functional programming paradigm. This has led developers to use functional idioms in languages like Ruby and Javascript, and it has also led some developers to languages such as Clojure. I enjoyed (and still enjoy) creating code in Clojure. The tools that it provides, and especially its emphasis on immutability, certainly help to construct programs that better meet the needs of end-users by creating more stable programs in concurrent environments. Still, it lacks the built-in type safety offered by languages like Haskell, and for this reason the burden of creating a safety net in the form of comprehensive tests isn’t really reduced when compared to a language like Ruby.

As a top Ruby consultancy we’re dedicated to continuing to provide our clients with applications expertly written in Ruby. For many new applications, we think that it still makes sense to leverage the incredible amount of open-source code that allows us to construct elegant new web applications with blazing speed. At the same time, as smart programmers we’re also looking forward to the point where languages like Haskell have the same amount of supporting infrastructure for rapidly creating apps that come with more safety so that we can focus on implementing the core business logic rather than boilerplate tests. We’ve made small contributions in this direction by open-sourcing parts of this web site that make sense, such as the library that powers the Twitter feed at the bottom of this page.

Ruby and Rails have been exemplars in terms of best practices like testing and providing plug-and-play library extensions that have been expertly crafted by dedicated open-source contributors. Haskell is quickly catching up with a number of the cabal packages that can be found on Hackage, but there is a lot that can be learned and adapted from the open-source world in Ruby to supplement the offerings currently available to Haskell programmers in order to make creating Haskell apps approach the efficiency of creating certain kinds of programs in Ruby and Rails.

During the rest of 2014, I’m looking forward to continuing to make great Ruby apps, but also to supplement this with working on an increasing number of apps written in Haskell. For a growing variety of applications, the built-in safety of Haskell, along with the great and growing size of supporting libraries, make this the best choice for efficiently creating applications that really satisfy end-users.

When you look to write or commission the construction of your next application, if you haven’t considered Haskell yet I’d strongly consider you to do so. As it comes time to start building, get in touch with us to see how we can help you! Finally, if you’re an extremely talented developer and would like to work on the next generation of hugely successful web applications, let’s talk to see if you would be a fit for our team.

You can contact Justin at justin@stackbuilders.com and follow him on Twitter.