Mitigating risks when developing with non-mainstream programming languages

(This is specific to Haskell, but can be applied in other settings)

 

Here are some problems I could imagine encountering: 

  1. not having a supported, stable library that interfaces with a specific system that become important to connect with (e.g. new database systems, important new web services, ...). 
  2. complex performance problems within a given library used at scale, and a slow or reluctant maintainer
  3. training time for new developers, recruiting experienced developers fast/easy
  4. lack of platforms/PAAS that automate various building/testing/devops necessities specific to Haskell like Heroku
  5. Cabal hell or reacting to conflicts in dependencies over time
  6. extra time needed to understand complex, albeit useful libraries and abstractions
  7. missing platform features or libraries to support emerging concurrent or distributed programming needs

Some ways I have imagined addressing them:

 

1.

  • Having either staff developer or consultant who becomes well-versed in the C FFI and throwing together quick wrappers around C libraries when crucial. Later revisit and fund development of pure Haskell implementations.
  • Having staff developers be very sharp in major web service API standards
  • Be in contact with important and emerging vendors and put in early requests for a maintained Haskell client library

2

  • Do very simple tests for scale early, report concerns to library maintainers
  • Be familiar with and in communication with support forums for key libraries used
  • Develop strong abilities to profile and isolate performance problems in sequential, concurrent, and distributed settings

3

  • Attend FP meetups and conferences
  • Give talks about anything on occasion to attract ongoing stream of interested candidates in being at your company
  • Stay on lookout for curious, sharp developers
  • Be in contact with Haskell consultants and trainers
  • use FunctionalJobs website

4

  • Ask major PAAS vendors for Haskell support, offer to pay to help get some of it initiated
  • Actively know APIs and build tools for Haskell on major platforms

5

  • Continually practice cloning and locally building any library you depend on
  • Be well-versed in Github pull requests for submitting patches you develop
  • Be familiar with and in communication with support forums for key libraries used (repeated)
  • Having a build server continually running builds with a set of current and emerging version constraints. Report failures to maintainers quickly.
  • Study internals of libraries you use

6

  • continue to master Haskell, attend meetups and conferences
  • have expert consultants available to train when need to learn fast
  • learn libraries and abstractions you may not use currently preemptively. write small practice programs with them
  • request (and write) more documentation and tutorials for libraries that need them

7

  • request these early and often
  • commission them from experts

Jane Street might be good people to talk as well, for anticipating problems that one might encounter when outside of the mainstream.