Skip to content

Comment on Ask HN: Who is not betting on Elixir and why not?parent

Comments

The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...

I really have to say it’s been a joy writing the backend for a Bitcoin-related app[1] in Haskell. It took me a while to adapt to Haskell — probably a couple of years or so — but in the end it has left me with such strong compiler guarantees that I can literally grep through my codebase for “error|throw” and see where a 500-error may be thrown by the server.

The only somewhat laborious part is categorizing all the exceptions, that can be thrown when performing requests, into retryable and non-retryable ones, so requests that throw these intermittent, retryable errors are automatically retried (the retry package makes automatic retrying super easy).

This post[2] gets to the crux of how my coding has adapted over the years: getting rid of runtime-decisions (e.g. looking at a Maybe value at runtime to figure out what to), by moving the relevant parameters to the type level, such that program flow is determined at compile-time by which type an operation is parametized over. For example, the app is parametized over two types: DB implementation and Blockchain implementation[3], which makes the compiler construct a program for these specific implementations at compile-time, rather than making it a runtime-decision based on reading a config file at startup.

[1] https://github.com/runeksvendsen/rbpcp-handler

[2] http://www.parsonsmatt.org/2017/04/08/maybe_use_a_type_param...

[3] https://github.com/runeksvendsen/rbpcp-handler/blob/master/s...

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.