
Ask HN: Most productive functional languages? - mbm
Which functional language are you most productive in?<p>We&#x27;re in the process of choosing a primary language for our backend systems at a new venture. A few we&#x27;re considering: Haskell, Clojure, OCaml, Elixir, F#, Scala.<p>What&#x27;s a reasonably productive choice for a new startup? What would you choose if you determined a functional language mapped well to the objectives you were trying to accomplish?
======
elviejo
I'm in the same boat as you.

Right now for the frontend we selected Elm.

Now for backend I've been playing with

Elixir and Haskell

Elixir has the nice syntax of ruby with all the performance of Erlang. So that
makes it a good candidate however what I don't like about it is: \- it isn't
strongly typed... and once you get used to types and all the bugs it catches
you can't go back. \- although variables are inmutable they behave as if they
look a lot like mutable state and I don't want to lose that warranty either.

Then there is Haskell. Haskell is great until you need to do IO. And 80% of
the webdevelopment is IO... either to the database, to an API or HTML... and
all the current options seem overly complicated. I tried haskell with Servant
which gives strong type to an API but the syntax is ugly Used Scotty (like
ruby's Sinatra) but then the URLs are strings and when definning APIs you
can't specify the types. Then I tried with Yesod I don't like such heavy
frameworks and try to avoid Template Hasell...

So I continue to search....

Next in my list consider is FSharp and OCaml

~~~
mbm
Very interesting! I've been using Elixir on a smaller project and have been
quite impressed. It just feels friendly and palatable, while also being quite
powerful for highly concurrent workloads.

Agreed on the typing, however.

~~~
qohen
_Agreed on the typing, however._

Have you guys looked into Dialyzer?

 _Dialyzer is a static analysis tool for Erlang and other languages that
compile to BEAM bytecode for the Erlang VM. It can analyze the BEAM files and
provide warnings about problems in your code including type mismatches and
other issues that are commonly detected by static language compilers. The
analysis can be improved by inclusion of type hints (called specs) but it can
be useful even without those. For more information I highly recommend the
Success Typings paper that describes the theory behind the tool._

That's from the Dialyxir (for using Dialyzer w/Elixir) github page:
[https://github.com/jeremyjh/dialyxir](https://github.com/jeremyjh/dialyxir)

More:
[http://learnyousomeerlang.com/dialyzer](http://learnyousomeerlang.com/dialyzer)

(Perhaps this should be read first: [http://learnyousomeerlang.com/types-or-
lack-thereof](http://learnyousomeerlang.com/types-or-lack-thereof) )

And this is the Success Types paper behind it (mentioned in the excerpt
above):

[https://www.it.uu.se/research/group/hipe/papers/succ_types.p...](https://www.it.uu.se/research/group/hipe/papers/succ_types.pdf)

~~~
mbm
I was just reading about it today. Awesome!

------
yawaramin
Interesting blog post describing the choice to go with OCaml:
[http://techblog.arena.io/2016-12-04_Risky_Libraries/](http://techblog.arena.io/2016-12-04_Risky_Libraries/)

To that post I would add that the OCaml -> JavaScript compiler, BuckleScript,
now gives you access to the entire npm package repository, so it's not such a
big risk any more as it was for them at the time.

