A Fairy Tale of F# and Durable Functions

https://hackernoon.com/a-fairy-tale-of-f-and-durable-functions-975ccc4d46b8

by kiyanwang • 8 years ago

94 30 8 years ago

LandR• 8 years ago

Nice article.

F# can be so readable, e.g.:

   // WishList -> Async<Reservation>
   let workflow (wishlist: WishList) = async {

      // 1. Find matches for each wish 
       let! matches = 
           wishlist.Wishes
           |> List.map findMatchingGift
           |> Async.Parallel

       // 2. Pick one product from the combined list of matches
       let gift = pickGift (List.concat matches)
    
       // 3. Register and return the reservation
       let reservation = { Kid = wishlist.Kid; Product = gift }
       do! reserve reservation
       return reservation
   }
   view raw
   durable-fsharp

Could basically be how you would write pseudocode.

Side note: How do I stop sites like hackernoon blocking my back button? It's so annoying!

bunderbunder3• 8 years ago

What I think is most interesting is that the thing that enables F# code to be so readable is exactly the thing that I thought would be its biggest readability problem when I first encountered it: The function call syntax and semantics. Specifically, the fact that there's no requirement to place any brackets around an invocation or its argument list, and the currying by default.

But the same syntax is what makes partial application work so well, which is in turn what makes the pipeline operator (|>) work so well.

Also, the syntax does a good job of encouraging you to organize code for better readability. It's a lot like lisp's function call syntax, only it somehow makes me feel incentivized to capture intermediate values in let statements instead of nesting my function calls. I'm guessing it's because there's something vaguely pleasing about getting to skip the parens.

I also like that F#'s version of do blocks requires you to explicitly state what kind of computation expression you're using.

dvlsg• 8 years ago

I agree. The first time I saw F#, I was immediately concerned about single spaces without any braces/brackets/parens indicating function executions.

I stuck it out with F#, though, and now I miss that syntax greatly when I have to use other languages. It's surprisingly wonderful (at least in my opinion). Or at least in languages where partial application / currying / composition is easily-available. I suspect that syntax wouldn't be very helpful with languages where that isn't the case.

tombert3• 8 years ago

I actually completely disagree about the explicit `do` blocks; as a consequence of that decision, you can't write functions that abstract over all monads, at least not easily. I like F#, but that has always been my main gripe for the two years that I did F# full-time.

I realize that for business code that that isn't a super big deal, but it becomes an issue if you want to write generic libraries; the closest thing that you can do is to exploit static-resolved types with member constraints and do explicit binds.

For example, if I wanted to have a monad transformer for Async<Option>, I could define the custom monad, but then I end up having to wrap every regular Async function manually (or do a lot of manual unboxing) to make it work. A lot of the time, my logic in the async blocks isn't specific to async, and I feel that when you're forced to write custom unboxing everywhere, that's a good way to make a lot of mistakes.

EDIT: Just an FYI, despite this complaint, I do really like F#...I find it an incredibly practical language, and one of the best of the Hindley-Milner-style functional languages.

arwhatever• 8 years ago

I went through a phase where I tried making the entry point of each project or major module read like nothing more than:

inputs |> step1 |> step2 |> step3 |> etc

... and it seemed mostly doable, although I would wind up needing a layer of parameter rearrangement functions to make it read quite that cleanly. I don't know if I have a concrete opinion on how it worked out - I suppose I need to get back into doing this some more.

I suspect that if I were to try to hide an async workflow behind such an arrangement that the parameter-rearrangement layer might create a greater cost than a benefit.

But still, it's really neat that the language allows for this sort of attempt.

Tarean• 8 years ago

With some combinators you can indeed do this for any expressions, haskell has a tool that does this transformation automatically http://pointfree.io

This can quickly become unreadable but used well it can hide some noise and meaningless variable names.

jcmoscon• 8 years ago

This is why I love Haskell. You can easily define your own "|>" operator:

(|>) :: a -> (a -> b) -> b x |> f = apply x f

bunderbunder3• 8 years ago

I've been wondering if there's any value in having a syntax for partial application that works more like:

  fun(arg1, _, arg3)

where the "_" indicates a skipped argument. My thought being that, in return for being a little bit more syntax-heavy, you'd get several potential advantages: No need for parameter rearrangement functions, easier overloading, and the more explicit syntax might help with maintainability.

brianberns• 8 years ago

That can be fun and is only one step away from "point-free style". Just leave out the inputs altogether and switch to direct function composition:

    let myFunc = step1 >> step2 >> step3 >> etc

Personally, I often find point-free to be a little too terse, but occasionally it's much clearer than "regular" code.

https://en.wikipedia.org/wiki/Tacit_programming

hacker_9• 8 years ago

I don't know, from this I can't really see the memory cost or GC impact. And the parallel statement doesn't tell me anything of the threading model. I know that I see a lot of intermediate states being created which is not so good. If this code were shown to compile to the imperative equivalent though, I'd definitely think about learning F#.

macca3213• 8 years ago

It is a nice article, but one thing I don't like is that it picks Event Driven Architecture without spelling out the reasons _why_.

"We used Azure Storage Queues to keep the whole flow asynchronous and more resilient to failures and load fluctuation."

That's not enough for me. I often encounter people building complex systems message queuing, despite failures being rare, retries being cheap and fast, and the hardware already being resilient to load.

In this article, a simple explanation of why each step actually _needs_ EDA/queues would be great - e.g. as the Product Matcher algorithm occasionally can't read a child's writing, an elf has to manually contact the child's parents to find out what they want so it can take a very long time.

bradford• 8 years ago

That's not enough for me. I often encounter people building complex systems message queuing, despite failures being rare, retries being cheap and fast, and the hardware already being resilient to load.

I'm a bit familiar with Azure Queues and Azure functions and I'll try to provide some more context here. But short answer: Using Azure Queues here actually makes things less complicated.

An Azure function (or any function) doesn't do much in isolation. Someone has to call it, so you've got to figure out: who's calling this function, when are they calling it, and what context do they have at call-time?

General purpose functions allow a wide range of possibilities to the above questions, and it's a lot easier to shoot yourself in the foot. So many people implement their own queue-like functionality that Azure decided to abstract it away into a general purpose model that roughly says: This function is called whenever there are unprocessed items remaining in the queue, and only information that's in the queue is passed to the function.

When you buy into that model, you get a whole bunch of stuff done for you: They've added common functionality like retry logic, expiry of queue items, security/permissions/tokens and https endpoints, logging that provides visibility into failures.

It's eliminated a lot of boilerplate code and it's also an architectural model that's easily understood. I'm a big fan myself.

[also, disclaimer, I'm an MS employee, but I don't work for Azure]

TrueTeller• 8 years ago

Hi, the author here. It's a good point and a valid concern, but I did an explicit choice here: I didn't want to make the article longer. I have a prequel post which describes my thinking of why durable functions make sense, including a primer for the event-driven approach: https://hackernoon.com/making-sense-of-azure-durable-functio...

macca3213• 8 years ago

Cool - so that article you link sets the context for the second.

I do think it does HTTP a disservice though - when you switch from HTTP to EDA you ditch the well known Uniform Interface and a lot of the benefits you get for free,(i.e. robust caching/proxying/routing, all the things a Service Mesh can do).

Instead of ditching HTTP, it would be nice to see people building async HTTP APIs, where the API responds with 201 Accepted (probably using a message queue behind the scenes) rather than the brittle systems you describe, where everything comes back under a 200.

philonoist• 8 years ago

If I may ask, which language is more functional feature wise, F# or OCaml?

daxfohl• 8 years ago

"More functional" is not a precise term. However OCaml would fit most everyone's idea of "functional" more than F#. F# has to be compatible with the underlying .Net runtime, so it cannot have features like abstraction over modules, which is a very powerful functional abstraction in OCaml. F# also builds mostly on libraries built in C#, so unless you want to build wrappers on top of everything, you'll be doing a lot of OOP in F# as well. (Which I think is fine, I think OOP fits well in lots of cases and it's nice to be able to mix and match).

A Fairy Tale of F# and Durable Functions

Related Stories