←back to thread

Why F#?

(batsov.com)
447 points bozhidar | 3 comments | | HN request time: 1.93s | source
1. phplovesong ◴[] No.43546650[source]
Last time i tried F# i got bit by the weird concurrency story. There was async/task and somwhow they did not play well together. Also the dev tooling (for vim) was subpar, compared to ocaml (lsp). Compile times also was on the slower side.
replies(2): >>43546681 #>>43550617 #
2. neonsunset ◴[] No.43546681[source]
If you use task { } CE's you will get really good UX (it is recommended to use them over async CE's). They were introduced in F# 6.0 to address outstanding interoperability issues. As of now, writing asynchronous code is more convenient than C# (which is more convenient than Go or other languages which are less expressive w.r.t. writing highly concurrent code).
3. 110bpm ◴[] No.43550617[source]
`async` is F#'s original implementation of async programming. It is the precursor to C#'s await/async.

`task` targets the .NET TPL instead, which is also what C#'s await/async and all of .NET *Async methods use.

While the `async` implementation still offers some benefits over `task` (cold vs. hot starts [0]), my advice is - if you're doing backend code on .NET, you should use task. The tigher integration with the .NET ecosystem & runtime results in better exception stack traces, easier debugging and faster performance.

[0] https://github.com/TheAngryByrd/IcedTasks?tab=readme-ov-file...