shortrounddev2 on Pain Points of OCaml

My main gripe with ML variants is the poor syntax around async (F#). For networked (web) applications, you begin to find that many or most of your functions are async, and wrapping them in computation blocks which come with their own internal syntax that eliminates a lot of the elegance of ML and makes your code look more imperative often feels like it defeats the purpose of the language.

In F#

    let Foo =
        async {
            let! data = getData() |> Async.AwaitTask
            return data.value
        }

Is this the best they can do? C# just has

    async Task<Data> Foo() =>
        (await getData()).value;

Ive always wanted ML syntax like this:

    let async Foo =
        let data = await getData
        data.value

I just dont write a ton of pure functions which have no I/O dependencies

sasmithjr 10mo

You can write a helper method (or use FsToolkit.ErrorHandling[0]) to simplify the F# example to:

    let Foo () = getData() |> Task.map _.value

And it'll be easier to work with the .NET ecosystem if you use the task computation expression[1] over the async one.

[0]: https://github.com/demystifyfp/FsToolkit.ErrorHandling

[1]: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

shortrounddev2 10mo

Isn't that a synchronous call?

yawaramin 10mo

We have exactly that in OCaml. Check out Eio.

neonsunset 10mo

This is outdated.

    let foo = task {
        let! data = getData()
        return data.value
    }

In F#, you interoperate with Task<T> transparently, and there is a number of community libraries to further enhance the experience. It also supports nice combinators like and! out of box.

Comments