Why F#?

Post by MrMcCall » Tue, Apr 01, 2025, 4:24 PM UTC

jasonthorsness wrote: post #64

munchler wrote: post #20

Earlier quoted context omitted.

F# is up to version 9 now, and has only improved over time, IMHO. Type providers are a very small part of the story and can be avoided entirely if you want.

I tried F# when it was first released and was not a fan, but it sounds like that impression is a little outdated. C# has come so far in that time it’s almost a new language. I’ll have to take another look.

Post by innocentoldguy » Tue, Apr 01, 2025, 4:27 PM UTC

raphinou wrote: post #152

innocentoldguy wrote: post #148

Earlier quoted context omitted.

I think Clojure is the better option if you want to do FP using the JVM ecosystem. The problem (for me, anyway) I've run into with Scala is that it supports both functional programming and object-oriented programming. Every code base I've worked on in Scala has ended up being a hodgepodge of both, which I find annoying. However, the best functional programming language is, of course, Elixir. :D

Elixir getting a strong type system is interesting, but watch out for gleam though But they still miss the computation expressions, which open interesting possibilities like https://github.com/CaptnCodr/Fli and https://github.com/fsprojects/FsHttp

Post by flakiness » Tue, Apr 01, 2025, 4:34 PM UTC

raphinou wrote: post #144

breadwinner wrote: post #130

Earlier quoted context omitted.

Apache Spark, Delta Lake are written Scala. Being JVM based, it has a large ecosystem. Scala seems like a better choice than F#.

I'm sure it can be the better choice, but for me it was not. It seems there was some incompatibility between me and Scala. I find it such a complex language and I never managed to wrap my head around it. As I said F# was my last choice at the start of my evaluation, and Scala was high on the list due to the Java ecosystem. But in the end it didn't work out for me. F# on the JVM would be great though!

Post by int_19h » Tue, Apr 01, 2025, 4:36 PM UTC

jayd16 wrote: post #119

smoothdeveloper wrote: post #108

Earlier quoted context omitted.

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

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

Post by cjbgkagh » Tue, Apr 01, 2025, 4:38 PM UTC

shortrounddev2 wrote: post #101

rockyj wrote: post #29

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…

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…

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

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