Hacker News new | ask | show | jobs
by imdoor 1650 days ago
I've seen a lot of praise for F# but trying it out left me somewhat disapointed. Overall, it was nice to program in but there was a constant feeling of awkwardness which, it seems, was caused by F#'s ties to the rest of the .NET world. I don't remember the details too well but some of the examples are:

- NULL values still are a problem because they can be introduced any time you interact with the .NET framework. I got hit by this almost right at the beginning when first using the language – i defined some data type with non-optional fields and used it as an argument to an ASP.NET Core controller method only to realize that my non-optional fields don't enforce anything and ASP.NET will happily set them to NULL when data aren't present.

- There are multiple slightly different ways to define data types – classes, records, discriminated unions – and it's not immediately clear what are the consequences of using which. I remember having to switch some of my datatype definitions to classes because otherwise i couldn't make ASP.NET Core automatically deserialize them.

- You still have to learn in detail how all of the C# and .NET concepts map into F# to work with .NET and other libraries, e.g., there is a weird duplication of collection types, sometimes you have to do a weird casting dance with the :> and :?> operators when working with interfaces, dealing with out parameters also took me quite some time to figure out.

- Namespaces, classes and modules also seem to have some confusing redundancy.

I've tried out F# only once for a single project so a lot my complaints are probably due to my inexperience with the language, but all in all it seems that a lot of the suffering is inflicted by the association with .NET and the language could have been a lot nicer if it wasn't tied to it (I'm not dismissing the benefits of it, though).
1 comments
mdm12 1650 days ago
Some of the issues (such as null values sneaking through the standard library) are a price to be paid for using a runtime such as .NET with a large ecosystem of existing libraries. This can be avoided to some degree by writing/using thin wrappers around the troublesome integration points that translate nullable values to option types. I agree, it is a source of friction. I believe other functional languages that target existing platforms (such as Scala) have similar issues.

Other points you mention (like being forced to upcast values to interfaces) have been resolved in recent versions of F#.[1] The language continues to evolve and improve with annual major releases. My biggest pain point is actually the tooling around the language, but that situation has been improving as well.

[1] https://docs.microsoft.com/en-us/dotnet/fsharp/whats-new/fsh...

link