Full-Stack Haskell: From Prototype to Production • Ryan Trinkle • YOW! 2018

This presentation was recorded at YOW! 2018. #GOTOcon #YOW
yowcon.com
Ryan Trinkle - Founding Partner of Obsidian Systems
ABSTRACT
In 2015 I quit my job to bet everything on the proposition that #Haskell could excel not just for specialized, high-assurance software, but for the kinds of software that millions of engineers work on every day. I had previously built backends with Haskell, with the wonderful experience of code that works reliably, a team that doesn't step on each others' toes, and an ease of refactoring that let us keep the codebase clean without risking regressions. But now, #GHCJS and #FRP had finally become reliable enough to trust in the real world. It was a game changer: Haskell could now build world-class graphical user interfaces, too, and deploy them as single page web apps - in theory.
In practice, there were many obstacles along the way. However, I found that even with the need to blaze new trails from time to time, our overall pace was far faster than anything I had seen in the imperative tech stacks I'd worked with before. Strong types and pure values decreased bug counts and made code much more readable. Some former backend developers who had scrupulously avoided frontend development told me that they now enjoyed working on the frontend, too.
Since then, I've worked with the community to continue building infrastructure to expand the areas where we can use Haskell to get real work done. Enabling mobile development required bug fixes to #GHC, a rearchitected approach to cross-compilation in #Nixpkgs, and bindings to native #APIs. To scale up to larger projects, we've improved existing tools and created new tools that make developer workflows simpler, faster, and more discoverable. And to make Haskell app development more accessible to beginners and professionals without Haskell experience, we've made more and more functionality available out of the box.
In this talk, I'll show you the tools that are available today and the challenges that lie ahead. I hope you'll come away with a broadened understanding of how Haskell can be applied in your own professional projects - and how the theory of functional programming can be a potent practical tool. [...]
RECOMMENDED BOOKS
Vitaly Bragilevsky • Haskell in Depth • amzn.to/3EXpmbe
Rebecca Skinner • Effective Haskell • amzn.to/3VgUKsh
Graham Hutton • Programming in Haskell • amzn.to/3Fi8rBC
John Whitington • Haskell from the Very Beginning • amzn.to/3VmX68R
/ gotocon
/ goto-
/ gotoconferences
#Haskell #ProgrammingLanguage #FunctionalProgramming #RyanTrinkle #YOWcon
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf...

[@hfislwpa]

Glad you all got your channel back!

[@ocaswiz]

Aside from being fun and cool, what are the benefits of developing apps using Haskell vs Java?

[@havocindustries3078]

You write like 1/5th the amount of code by choosing the right level of abstractions which in turn allows you to focus on quality.
Fun fact: the amount of bugs correlates with the amount of lines not the complexity of the code.

[@gdargdar91]

You have significantly more control over your software codebase and there are almost no bugs. But it requires more brainpower to think about solutions mathematically.

[@FilosSofo]

Nothing. There's no evidence that the functional paradigm gives a real project in real life any practical advantage.

[@gdargdar91]

@@FilosSofo Don't take those mainstream statistics seriously, they are only accurate for very specific configurations. We use functional programming and we see a day and night difference. You have to do it right BTW.

[@aoeu256]

@@FilosSofo I think there is evidence though that interactive REPL based development like Smalltalk Pharo or LISP images helps productivity. If you ignore the complex Haskell types maybe it might be a good prototype language, the complex types are good for mission critical software but not always for simple software.