Haskell for real - Joy & frustration of putting 38,000 lines in production

schedule Nov 18th 04:00 PM - 04:45 PM place Edinburgh people 6 Attending

We have spent the better part of a year introducing Haskell, typed languages, and functional programming, at Vacation Labs. After writing 250,000+ lines of code in dynamically typed languages (Rails & Javascript), we wanted more from our tech-stack:

  • The ability to fearlessly refactor as our market and our code evolved.
  • The ability to write only meaningful tests, and to increase coverage without increasing dev effort.
  • To share data structures across the backend & frontend.
  • And finally, the ability to continue developing features at speed - something that we take for granted in Rails.

In this talk, we will share our experience of using Haskell, with the focus on what the ecosystem enables us to do today, pragmatically. By the end of this talk, you will know the pros and cons of using Haskell in a real-world setting, and how to contribute in making the ecosystem better. (An aside, we aren’t using Haskell on the frontend, but Typescript, which also gives us quite a few abilities mentioned above).

 
3 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Why Haskell in the first place? (5 mins)
  • Current state-of-the-art along with pros & cons for common web app requirements:
    • Logging & instrumentation (5 min)
    • Editor tooling (2 min)
    • Rapid coding cycles - The “hit refresh” development workflow (2 min)
    • Database library (5 min)
    • Migrations (5 min)
    • ORM, validation, & the “records problem” (10 min)
    • JSON parsing & generation (2 min)
    • HTML generation (2 min)
    • Testing (5 min)
    • Web/app server (2 min)
    • Emails (5 min)
    • Job queue (5 min)
    • UI Code-gen (5 min)
    • Deployment (5 min)

Learning Outcome

  • Real-world experience report of using Haskell to build web-apps
  • Haskell ecosystem and availability of essential libraries
  • Gotchas and things to watch out for
  • A moderately battle-tested development workflow

Target Audience

Developers and Architects building Web Apps

Prerequisite

The talk should be accessible to almost anyone. You will appreciate it more if you've dabbled with Haskell in the past.

schedule Submitted 3 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Manuel Chakravarty
    keyboard_arrow_down

    Manuel Chakravarty - Haskell SpriteKit - a Purely Functional API for a Stateful Animation System and Physics Engine

    45 Mins
    Demonstration
    Intermediate

    Graphics, animation, and games programming in Haskell faces a dilemma. We can either use existing frameworks with their highly imperative APIs (such as OpenGL, Cocos2D, or SpriteKit) or we waste a lot of energy trying to re-engineer those rather complex systems from scratch. Or, maybe, we can escape the dilemma. Instead of a Haskell program directly manipulating the mutable object-graph of existing high-level frameworks, we provide an API for purely functional transformations of a Haskell data structure, together with an adaptation layer that transcribes those transformations into edits of the mutable object-graph.

    I this talk, I will explain how I used this approach to architect a Haskell binding to the animation system and physics engine of Apple’s SpriteKit framework. I will discuss both how the binding is structured and how it achieves the translation of Haskell side changes to SpriteKit and vice versa, such that it is sufficiently efficient. Moreover, I will demonstrate by example how to use the Haskell library to implement a simple game.

  • Liked Rahul Muttineni
    keyboard_arrow_down

    Rahul Muttineni - Eta Fibers: Towards Better Concurrency on the JVM

    Rahul Muttineni
    Rahul Muttineni
    Co-Founder
    TypeLead
    schedule 3 weeks ago
    Sold Out!
    45 Mins
    Demonstration
    Intermediate

    In order to handle modern, real-time demands, companies are moving to reactive microservice architectures. These architectures are much more flexible but must be programmed asynchronously to minimize latency and handle as many concurrent requests as possible. However, asynchronous programs are hard to read, maintain, and debug. We solve this in Eta with Fibers.

    Eta is a pure, lazy, statically-typed language on the JVM that gives you the power of Haskell on the JVM. By definition, Eta is well-designed to handle the problems of concurrent & distributed systems with abstractions that are simple to use and reason about.

    One of these abstractions is the concept of Fibers which are lightweight, cooperative, and non-blocking threads that allow you to handle concurrency with ease. This contrasts with green threads, which are pre-emptive and cannot be controlled in a fine-grained manner by the developer. Moreover, we have developed a sequenceable (monadic) API for Fibers to unify asynchronous and synchronous code, solving the notorious "callback hell" problem.

  • Liked Gyanendra Aggarwal
    keyboard_arrow_down

    Gyanendra Aggarwal - A practical guide to GenStage with a real-life use case.

    45 Mins
    Case Study
    Beginner

    Elixir GenStage is a very interesting abstraction (behavior) and can be used very effectively to solve many complex problems that fall under supply-demand/back-pressure scenarios. One can solve such problems by writing minimal amount of code by using GenStage. Come and learn in detail about the wonders of this abstraction with a real-life use case in Warehouse automation.

  • Debasish Ghosh
    Debasish Ghosh
    Consultant
    IRadix Inc
    schedule 5 months ago
    Sold Out!
    45 Mins
    Experience Report
    Intermediate

    Using a programming language that supports first class functional programming doesn’t necessarily imply that the code you write is functional. Functional programming has the nice properties of being compositional - you design smaller abstractions and then reuse them to build larger ones. You use the power of algebraic properties that these abstractions offer to build larger elements of your model out of smaller ones.

     However often we find that many code bases designed in a functional programming language are inherently imperative, especially when you are using a multi-paradigm language like Scala or Java. There’s nothing wrong with imperative code, but it lacks the niceties of expression based composition that makes reasoning about your code so much easier. Also assignments used in imperative code are inherent side-effects that are best avoided (or at least minimized) in an expression oriented language.

     In this session I will discuss some of my experiences of mining imperative code and refactoring them into functional patterns. You will be surprised to see how much functional goodness can be derived through functional thinking. Algebraic structures like Monoids, Monads and Kleislis are just buried within the reams of imperative statements crying to come out. In an exercise of half an hour we will liberate them and see how the code quality improves from the point of view of modularity, compositionality and simplicity.

  • Liked Ravi Mohan
    keyboard_arrow_down

    Ravi Mohan - Predator: A Framework for Developing Programmatic Players for Complex Board Games

    Ravi Mohan
    Ravi Mohan
    CEO
    AxiomChoice
    schedule 6 months ago
    Sold Out!
    45 Mins
    Experience Report
    Beginner

    Summary: An Experience Report on How a very time constrained Haskeller learned Erlang and PureScript "in small pieces" to create programmatic opponents aka 'bots' for complex boardgames

    Every experience report tells a story - the story of a project, unvarnished and without artifice, programmer to programmer, out of the sight and hearing of the manager folks, often involving one or more of comedy, tragedy, farce etc. This report is no exception.

    I have a fulltime 'dayjob' and my standard 'language toolkit' is Haskell + C + Lua. My co-founder is a bit of an Erlang maniac, and challenged me to learn Erlang and actually building something in it and *then* go on about the superiority of Haskell.

    This is the story of my response to the challenge and how I learned and coded Erlang/Elixir in very small chunks of time (about 10 - 20 )minutes a day max) and attacked an interesting problem. This severe time constraint (and lack of any previous knowledge of Erlang) shaped the nature of the (still evolving) system.

    The problem:

    The number of boardgames that you can whip out at a gathering and expect people to want play is very small.. Monopoly, Snakes and Ladders, and maybe, if you are *very* lucky, Settlers of Catan. And that's about it.


    Getting people to play these games is relatively easy.

    However the world of boardgames is *much* wider.

    There are literally tens of thousands of boardgames that simulate everything from very abstract geometry puzzles to ones that simulate complex economies and political situations.

    Some of the latter are used in very unexpected ways, e.g to train spies and military officers.

    Here is an example of an interesting game.

    A Distant Plain (by GMT Games) is a boardgame for 4 players that put them in the roles of the US military forces, the Afghan government, the Taliban, and Warlords/drug dealers, all competing for power in Afghanistan.

    ADP

    adpcards

    Here is another
    The War of the Ring, a game for 2 players.

    "In War of the Ring, one player takes control of the Free Peoples (FP), the other player controls Shadow Armies (SA). Initially, the Free People Nations are reluctant to take arms against Sauron, so they must be attacked by Sauron or persuaded by Gandalf or other Companions, before they start to fight properly ...."

    WarOfRings1

    And one more

    "The battle of Sekigahara, fought in 1600 at a crossroads in Japan, unified that nation under the Tokugawa family for more than 250 years.

    Sekigahara allows you to re-contest that war as Ishida Mitsunari, defender of a child heir, or Tokugawa Ieyasu, Japan's most powerful daimyo (feudal lord)."

    ."

    What these games have in common
    1. They are wonderful games, immersing you into their respective worlds.
    2. They have (relative to Snakes and Ladders or Monopoly) complex rulesets, which take effort and time to master.
    3. They are rarely played in India.
    4. Even when people own them, opponents are almost impossible to find and schedule.

    Which means that if you own these games and live in India, getting to actually play these games is close to impossible.

    Which is a problem.

    The (incomplete, but ongoing) solution

    Being a programmer, I solve this problem by writing programmatic opponents (aka 'bots') to take the place of other players. This involves all kinds of interesting sub problems - game representation, logic processing for rules, building AI 'smarts' for your opponents, gui and event handling etc.

    Since I am doing this in my non existent spare time, and this being a response to an Erlang user's challenge, I learned (am sill learning) Erlang and Elixir (and some minimal PureScript), and built ( am still building) the system at the same time..

    This talk is about the many challenges I faced in building automated game players (and extracting common frameworks/libraries) from them, while simultaneously learning two FP languages.

    Since this is an experience report, it is basically a highly subjective list of lessons learned, victories *and defeats*, what worked *and more importantly what didn't work*.

    If you can't use FP at work, but are considering doing so on a personal project, or want to learn how to get going on an FP learning effort, you might benefit from my experience - both successes and failures. I also talk about how to go about learning Erlang/Elixir in the shortest possible time.

  • Liked Aloïs Cochard
    keyboard_arrow_down

    Aloïs Cochard - The Tale of Troy

    45 Mins
    Demonstration
    Beginner

    In recent years, the impact of functional programming on mainstream languages has grown significantly.

    After conquering server applications and distributed systems,
    the paradigm is now conquering the fields of web development and data analytics.

    So what remains? The land of system programming.

    When Mozilla did release the language Rust in 2012,
    it did immediately striked interest from functional programming enthusiasts due to it's strong emphasis on safety.

    Even though it currently lacks some advanced features like higher kinded types,
    it is built with functional programming principles as it's core.

    Like a Trojan horse (or the parasite mushroom after the language is named),
    Rust looks like the next C on the outside... while it might actually be closer to Haskell on the inside!

    Let's take a tour and discover an other side of system programming by learning together how to do functional programming in Rust.

  • Liked Naresh Jain
    keyboard_arrow_down

    Naresh Jain - Array-Oriented Functional Programming in PHP

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 7 months ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    Array-oriented Programming (AoP) dates back to 1960s.The fundamental idea behind AoP is that operations apply at once to an entire set of values. This allows the programmer to think and operate on whole aggregates of data, without having to resort to explicit loops of individual scalar operations. At ConfEngine.com, a platform for organising and managing technical conferences/events, we've been heavily influenced by the APL style of AoP. In our context, this means each function focuses on applying one transformation to an immutable array (ordered-map) and then spitting out a new array, which can be piped to another function thus achieving functional composition. This has allowed us to build a very modular, decoupled design, which is extremely simple to reason about.

    If you think of typical web-apps, they are generally CRUD applications. Data comes in, you apply a set of transformation and you pass it to someone else via an API or you save/query a data store. And on the way out, you get data from somewhere (data-store, API, etc.), apply a set of transformations and render the transformed data as HTML or JSON. Now we can visualise most web-apps using standard Pipe-and-Filter Architecture. With this, applying some of the functional programming concepts becomes more intuitive.

    At ConfEngine.com, we use the standard LAMP stack. We've used PHP's philosophy of shared-nothing-architecture to address concurrency and scalability concerns. PHP itself has all the basic ingredients required for Functional Programming - first-class, higher-order functions, lambda, closures, partial functions, recursion and so on. We use array (ordered-map) to hold the data. PHP provides 79 array functions that allows you to do pretty much everything you need to in terms of transforming arrays including map, reduce, filter, merge and so on. One needs to be careful, but most of these are pure, higher-order functions.

    If you are interested to learn more about AoP, I'll give a walk through of our design. Also I'll take a couple of problems to explain how to think in terms of AoP and how its really helps with functional programming.

  • Liked Emil Soman
    keyboard_arrow_down

    Emil Soman - Turn Hours into Seconds - Concurrent Event Processing

    Emil Soman
    Emil Soman
    Software Consultant
    Codemancers
    schedule 4 months ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    For programmers who have been using locks for synchronizing threads to solve all concurrency problems, embracing message passing and creating concurrent data flows is an enlightening experience. This talk is a case study of a real world concurrency problem where the developer started with a slow non-thread-safe solution and refactored it step by step into a fast yet simple concurrent solution making use of Elixir's concurrent computation library called Flow.

  • Liked Calascibetta Romain
    keyboard_arrow_down

    Calascibetta Romain - Git under the hood with OCaml

    Calascibetta Romain
    Calascibetta Romain
    Independent
    OCaml Labs
    schedule 5 months ago
    Sold Out!
    45 Mins
    Demonstration
    Intermediate

    Git is one of the most popular tool for a developper and a part of the power of Git is come from some functional concepts. So, it's obvious to implement the Git format with OCaml!

    This talk will present the functionnal concepts of Git (like the immutable tree) and show a practical implementation with OCaml step by step. Then, we will explain how can scale an OCaml code to compute a huge Git repository and understand by this way the power of OCaml (and the mix between the functionnal and the imperative way).

    At the end, we will show an example of the usability of Git with OCaml with a concrete application.