Ask HN: Too risky to bet company on a fringe language? (Clojure, Haskell, Etc)

What do you mean when you say "is it risky"?

* You risk that you won't be able to find developers at a salary that will help your company earn money * There is a risk that you may have to do lots of the work yourself and may not be able to pass it on if you write programs for these industries

In my opinion, you need to decide why you want to use a "fringe" languages over something with more available talent. Are you using it because it's what you know? Because it will be fun? Or is there a benefit of that language that you wouldn't have otherwise?

It won't be impossible, but it's hard to replace commodity software with something that would end up being more expensive without adding any innovation or new benefits.

I'm going to assume a couple of things while answering. Feel free to point out which of them is unwarranted.

1. You won't write the code (ref. hiring developers)

2. Webapp software, not desktop

3. You have time or developer constraints (basic economic choices to make)

If the industry does not need "innovation" that does not mean that the software itself will not be fairly complex. For example, a simple undo feature can be a complex thing to implement, regardless of how fossilized the industry the software is being written for is. Building software that scales, and especially software that contains lots of social linkages is a complex problem.

Risks are ever-present and must be balanced. You should consider:

A) Time to write the software

B) Hiring new developers

C) Buyout risk

D) Platform risk

E) Social risk.

IMHO, and speaking as a Clojure developer in a startup that uses it almost exclusively:

A) Platform risk is negligible. As someone who has done plenty of Common Lisp programming, I can confidently assert that the Clojure platform is way more accessible, and moving faster. It's the JVM after all.

B) Hiring: plenty of new blood. Apparently at ITA, it was quite easy to onboard newbies to Common Lisp. IMHO Clojure is easier. It even has fewer parens than idiomatic, equivalent Java.

C) Time: I believe time is highly correlated with LOC. Clojure clocks in with the lowest LOC, most elegant solutions I have yet seen. Haskell is no doubt similar, though it's sweet spot / domain is likely different.

D) Buyout risk: I believe perceptions will change. Several large companies are now Scala shops. They're like the early adopters who bought into 8088 PCs. The Mac-like era of Clojure is yet to come. We've already seen one or two buyouts of Clojure shops.

E) Social risk: lots and lots of new libraries, access to all the old java libraries. Almost no risk here, imho.

Now, a lot of your risks may actually fall into the class of "good problems to have". While I cannot speak to Haskell or other languages as much, my feeling is that Clojure is a better bet in comparison.

Of course, if the use of niche languages is not your choice, you should ask your developers why they want to use it. They should be able to explain their reasoning.

Also, at least in the webapp domain, a lot of complexity arises from the interplay between webservers, javascript, backend code, hosting providers etc. Clojure has a lot of nice features here which help, but it's rather more the interplay which contains the complexity. IOW, this aspect of complexity is outside the domain of the backend language. Clojure has a secret weapon here too, clojurescript, but its implications are not yet well understood. It has a lot of potential though.

hth, and btw, if this is my boss trolling me, well, /me starts scheme-ing

I don't agree that Haskell is fringe. Haskell is more than 20 years old. It is commonly used in finance, science and in complex projects (like pugs). The ability to program in a strict typed functional language is often a good indicator of programming skill.

Clojure in comparison is much younger. It does however leverage the JVM so I suppose it stands on the shoulders of giants. Again, the ability to develop with Lisp is a good indicator of programming skill as well.

That the industry has not innovated does not mean that your code base will lack innovations. a data-centric approach will more than likely find hidden data points that will allow your systems to leverage some aspects of the market (innovation for free?).

In hiring, you may want to hire for a broader skill-set, but look for Haskell or Clojure skills. That developers get bored should lead you to consider more autonomous management structures.

Incidentally, I think the market you picked is excellent. Innovating in that space will be easier. Marketing to them, much harder. I'd hire developers that understand platform development or systematic design.

What do you expect to gain by using language XXX that you would not get from languages YYY, ZZZ, and so forth. To a very large extent, programming language is not important. Sometimes the choice of language can make a difference in the complexity of the programming task; but knowing that a priori usually means that you have a deep understanding of the task to be performed and that it requires something special.

There are secondary considerations which are related to language such as the availability of trained programmers, the availability of good documentation, whether the language is stable or under rapid development, whether the language you choose is proprietary or open source, and so forth, but they are secondary considerations.

I'm betting my startup on Clojure, but it doesn't feel like much of a "bet". It is probably one of the least risky choices I've had to make and as a bonus to the technical benefits it is also a nice way to differentiate yourself. It is integrated with the familiar, mature JVM-platform and not that hard to learn as an experienced developer. Integrating with existing Java or future JVM code (e.g. Scala, JRuby, Groovy) is a huge plus, because you can start thinking about the right tool for the job instead of troublesome integration with legacy code.

As to hiring: I think you will have a harder time finding good programmers to work on boring problems in a boring language (e.g. Java). Picking a niche language would make your project more interesting, but you can also do other things to make the working attractive to good people, e.g. actively developing and maintaining open source libraries related to your project or allow them to rethink the way problems are solved in your industry. Seemingly boring problems can have very interesting solutions. It also helps when you offer good working conditions (e.g. possibility to work remotely and all the "Aeron chair" kind of perks you keep reading about on HN). Not everyone is right for the typical startup or Googler lifestyle. Some very good hackers actually prefer e.g. working from home so they can take care of baby to pulling all-nighters at Facebook.

This is all assuming you're a technical founder. If you are: go with something that you're not only passionate about, but that is also the right tool for the job. In my case Clojure fits best, because I need the integration with Java libraries like Apache Lucene, but in your case it might be Haskell or something else entirely. If you aren't a programmer yourself you should find a technical co-founder or early employee to make this kind of decision.