Comment by shortrounddev2

3 days ago

I like F#'s syntax when all you're doing is pure logic. But when you have to interface with any IO like a database or REST call or something, you have to abandon the elegance of ML syntax and use these ugly computation blocks. In C# you can do something like this:

    var post = await _postService.getById(id);

in F# the equivalent is basically

    let getPostById id = async {
        let! post = blogPostService.getPostById id
        return post
    }

    let post = getPostById 42 |> Async.RunSynchronously

But not really, because RunSynchronously isn't the same thing as `await`. Realistically if you wanted to handle the result of an async computation you would need to create continuations. F# isn't the only ML-family language to suffer from this; Ocaml does as well. It always seemed to me like the pattern with any asynchronous operations in F# is to either:

1. Do all logic in ML-syntax, then pass data into a computation block and handle I/O operations as the last part of your function, then return unit OR

2. Return a C#-style Task<> and handle all I/O in C#

Either way, ML-style languages don't seem like they're designed for the kind of commercial CRUD-style applications that 90% of us find ourselves paid to do.

31 comments

shortrounddev2

Reply
throw234234234  3 days ago

I find it personally better for CRUD applications than C# and I've written my share in both languages. Your syntax comparisons aren't exactly comparable in the sense that you haven't put in the wrapping/boilerplate around the C# code - you can't just await anywhere. You are also using an async which to run needs to know which context - this can be nice when you don't want to run the composed Task/Async on the current sync context. These days you stick to tasks if you want C# like behavior - and there's libraries to take away some SyncContext overload via custom F# CE's if you want.

The equivalent C# to your F# would be

  task { return! _postService.getById(id) }

Which is somewhat pointless anyway - just return the task from postService directly. There's also no need to run the async synchronously then - Async allow you to run the logic on task, thread, sync over and over - a very different model than tasks.

To make C# comparable to your F# code (tasks are not the same so not quite true) you would need to define a method around it, and find a way if you want to run the resulting Task synchronously to do that safely.

  public async Task<Post> GetPostById(id) => await blogPostService.getPostById(id);

  // This is not entirely eq - since tasks are hot
  this.GetPostById(42).Result

cjbgkagh  3 days ago

F# is a big language, it is a ML multi paradigm language that interoperates with C# so there is a lot of necessary complexity and many ways to do the same thing. A strong benefit of this is the ability to create a working functional paradigm prototype that can iteratively be refined to a faster version of itself by hot spot optimizing the slower parts with equivalent highly mutable functions while staying within the same language. Similar how one would use python and C++ and over time replace the python code with C++ code where performance is important.

For the specific case of C# use of await it is unfortunate that C# didn't design this feature with F# interop in mind so it does require extra steps. F# did add the task builder to help with this so the 'await' is replaced with a 'let!' within a task builder block.

  let getById(id:int) : Task<string> = failwith "never"
  let doWork(post:string) : unit = failwith "never"
  let doThing() = task { 
    let! post = getById(42); 
    doWork(post); }

Alternatively the task can be converted to a normal F# async with the Async.AwaitTask function.

  let getPostById1(id:int) : Async<string> = async { return! getById(id) |> Async.AwaitTask }
  let getPostById2(id:int) : Async<string> = getById(id) |> Async.AwaitTask 
  let getPostById3 : int -> Async<string> = getById >> Async.AwaitTask

  • neonsunset  3 days ago

    It is best to just use task CE full-time unless you need specific behavior of async CEs.

    The author of the original comment, however, does not know this nor tried verifying whether F# actually works seamlessly with this nowadays (it does).

    Writing asynchronous code in F# involves less syntax noise than in C#. None of that boilerplate is required, F# should not be written that way at all.

    • cjbgkagh  3 days ago

      F# is a big language so I think it is to be expected that beginners will not know these things. I don't think the fix is to simplify F# we should just understand that F# is not for everyone and that is ok.

      1 reply →

smoothdeveloper  3 days ago

In C#, you can't use the await keyword in a non async method, so I find the argument short sighted.

  • shortrounddev2  3 days ago

    I don't see how that changes things. You'd have to async it all the way to the top but the syntax is still cleaner than F#. If you're using an Asp.Net controller you just declare the handler as async Task<IActionResult> and it's fine. Even program main methods can be async these days

    • malakai521  3 days ago

      The syntax is exactly the same. You have `var x = await` in C# and `let! x =` in F#

      The controller handler is also the same. It will be marked with `async` keyword in C# and `task` CE in F#

      6 replies →

  • jayd16  3 days ago

    If your code base is already using async await it's really not an issue.

    • int_19h  3 days ago

      The point is that it's not actually different from C#, especially once you consider that F# also has task{} blocks that give you a .NET Task directly.