←back to thread

Why F#?

(batsov.com)
438 points bozhidar | 8 comments | 01 Apr 25 12:34 UTC | HN request time: 0.001s | source | bottom
Show context
rockyj ◴[01 Apr 25 13:08 UTC] No.43546371[source]▶
I did try F#, but I was new to .NET ecosystem. For 1 "hello world" I was quite surprised by how many project files and boilerplate was generated by .NET, which put me off.

I am all for FP, immutable, and modern languages. But then where are the jobs and which companies care if you write good code?

Now everyone wants languages which are easy to use with AI, while reducing workforce and "increased productivity". I have been programming for 20 years and know 4-5 languages, in India it was worse but in EU at-least I can make a sustainable living by writing Java / TypeScript. I cannot even find jobs with Kotlin + TypeScript which pay well, forget getting jobs in Elixir / Clojure / F# (there maybe a handful of opportunities if I will relocate for around 70K/year). That is why I have mostly given up on learning niche languages.

replies(11): >>43546449 #>>43546522 #>>43546629 #>>43546648 #>>43546914 #>>43546918 #>>43547243 #>>43547274 #>>43547691 #>>43548828 #>>43553311 #
shortrounddev2 ◴[01 Apr 25 14:34 UTC] No.43547274[source]▶
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.

replies(4): >>43547546 #>>43547687 #>>43548815 #>>43552613 #
cjbgkagh ◴[01 Apr 25 16:38 UTC] No.43548815[source]▶
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
replies(1): >>43548876 #
neonsunset ◴[01 Apr 25 16:43 UTC] No.43548876[source]▶
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.

replies(2): >>43549020 #>>43551121 #
shortrounddev2 ◴[01 Apr 25 20:42 UTC] No.43551121[source]▶
I understand that you CAN do this, I'm saying that it makes your code look like shit and takes away some of the elegance of ML
replies(3): >>43551302 #>>43551470 #>>43551479 #
1. cjbgkagh ◴[01 Apr 25 21:22 UTC] No.43551479[source]▶
Are you saying you prefer Ocaml to F# or C# to F#? Your example was indeed inelegant but it is also poorly designed as you take 4 lines to reproduce a function that is already built in, people can poorly design code in any language.
replies(1): >>43556410 #
2. shortrounddev2 ◴[02 Apr 25 13:24 UTC] No.43556410[source]▶
I'm saying that I wish computation blocks looked better in F#. Instead of:

    let foo id = async {
      let! bar = getBar id
      return bar
    }
I would prefer

    let async foo id =
      let! bar = getBar id
      bar
or even something like

    let async foo id =
        getBar! id
So that computation blocks don't feel like you're switching to an entirely different language. Just wrap the ugliness in the same syntactic sugar that C# does. As it is, C# can achieve arrow syntax with async methods more elegantly than F# can:

    async Task<string> foo(int id) => await getBar(id);
This, to me, is also part of a larger problem of F# introducing unique keywords for specific language functions instead of reusing keywords, like

    member this.Foo = ...
and

    member val Foo = ...
replies(1): >>43558250 #
3. cjbgkagh ◴[02 Apr 25 16:08 UTC] No.43558250[source]▶
Your criticism is rather incoherent and it is difficult for me to make sense of it.

You don't even have to use the computation block for that and can use the built in functions as I mentioned earlier and gave 3 examples of.

You're both complaining about extra keywords while trying to make the case of adding yet another one. Thus your complaint boils down to F# not picking the exact keywords that you like - that the language is not specialized to exactly how you want to use it. In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case.

Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after. It's better than C# in that you can create your own as a first class concept in addition to using the built in ones. It's there for the exact purpose of creating mini-embedded DSLs, the very thing you're complaining about is the exact point of it.

F# is not for everyone, nor should it be.

replies(1): >>43558582 #
4. shortrounddev2 ◴[02 Apr 25 16:40 UTC] No.43558582{3}[source]▶
> You're both complaining about extra keywords while trying to make the case of adding yet another one

I did no such thing. async is already a keyword in F#, I'm just saying they should drop the brackets and remove the required return statement.

> In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case

It would make the language easier to read, for one, and would reduce the amount of specialized syntax needed for specific features. It would preserve the original ML-style syntax for an extremely common operation and not force users into wrapping anything upstream of an async call in a computation block, which is the ugliest syntax feature of F#

> Computation expressions are a generalized concept which are there to add the exact kind of syntactic sugar that you're after

I understand that, and my argument is they failed to do so. The syntax looks bad. They could keep it for all I care, but they should add even more sugar on top to make it not look so bad.

replies(1): >>43558917 #
5. cjbgkagh ◴[02 Apr 25 17:12 UTC] No.43558917{4}[source]▶
'async' is not a keyword in F#, it's a builder instance no different to the ones that you can create. It's just built in to the standard library.

The return statement is only required if you want to return something form the computation expression. In your example you use async { let! x = f(); return x}, which can be reduced to async { return! f()}, which can be reduced to f().

The rest is your opinion that I don't agree with.

replies(1): >>43559651 #
6. shortrounddev2 ◴[02 Apr 25 18:18 UTC] No.43559651{5}[source]▶
The distinction in this case is utterly meaningless. This is about the ergonomics of the language. Which are lacking the minute to break out of pure functional land
replies(2): >>43560391 #>>43560987 #
7. cjbgkagh ◴[02 Apr 25 19:13 UTC] No.43560391{6}[source]▶
I disagree with both of your statements
8. neonsunset ◴[02 Apr 25 20:13 UTC] No.43560987{6}[source]▶
Read this first: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

There are multiple alternate asynchronous computation expression implementations which give different ergonomics and behavior (like https://github.com/TheAngryByrd/IcedTasks). There's an entire CE extension to specifically enable this kind of convenience and flexibility too: https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0...

None of this is possible in C#, at least without jumping through many hoops and ending up with extra boilerplate (and this is okay, C# has enough of its own complexity). As cjbgkagh noted, providing this type of control is the whole point and what makes F# so powerful.