Hacker News Reader

Comment by 29athrowaway | Hacker News Reader

F# is a great language, but the .NET community never embraced it.

It's a real shame, but not unexpected. The vast majority of programmers I meet in the wild simply do not have training in FP and by the time they decide to learn it (if they do), it's hard to unlearn "traditional" thinking.

If we want to steer programming in that direction, we should teach functional programming before "traditional" programming. However, even if we manage to do that I'm not convinced that it will make a different. People think procedural and it seems that the abstraction of first order functions is hard.

As a .NET developer I don't see any reason to use F# professionally. C#/CPP are tools just like a hammer, F# is a different hammer, it doesn't seem to offer advantages in my field other than being different...

The functional hammer can be a little easier to reason about. So you can understand your application a little more.

It's possible to write functional C# code, as well.

It’s possible but it’s just not the same.

Yeah you can. I find it a little more clunky. Many of the things I prefer are just syntactic sugar. But if I'm honest I really like syntactic sugar.

On top of that I find functional first languages are great for forcing you to learn functional styles that you can later user in languages like C#.

C# is a brilliant language and I wouldn't knock it. I'd use that as a first option at work but on a hobby project I'm going to play with F#.

Ehh, not really. It depends on how you define functional programming. C# supports first class functions, tuples, some form of pattern matching and LINQ extensions support basic FP collection operations like map (Select), filter (Where) and fold (Aggregate). But I think that's just scratching the surface compared to a "real" FP language:

- F# has function composition operators

- F# functions are curried and support automatic partial application

- F# variables and data structures are immutable by default

- F# has powerful global HM type inference

- F# uses option & result monads over exceptions and null

- F# has algebraic data types with exhaustiveness checking

These capabilities make writing code in F# a very different experience from C#. Some of these can be added to C# as features, but many things are fundamental parts of language design that are hard to change afterwards.

That stinks of microallocations from enormous stacks of closures, boxing and similar.

It allows you to envision your application as a series of data transforms, instead of a list of steps. This allows much more proximal abstractions for tasks involving data manipulation.

You can treat your application as a series of data transforms with C#, as well.

It's.. not as nice. LINQ gets halfway, but, you end up getting back to procedural modeling soon. With sufficient discipline and structure, and liberal use of LINQ and lambdas, you can mostly get there, but it lacks the purity of pure functional.

And in the process you've incurred a devastating amount of micro-allocations. When using Unity with an older version that doesn't have incremental GC this is a serious problem.

Does F# avoid that?

Oh, god no. Performance even on fairly trivial number crunching tasks is half of C#, nevermind anything where GC is important or you'd consider writing it native. It's not a performant language, that's not the point.

That's not a fundamental limitation, though. Implementations of SML (f# is effectively an ML implementation), OCaml, and Haskell are all quite performant.

F# generates weird, verbose, opinionated IL code that is often JIT-unfriendly and rather focused on reference types. JIT is tailored to C# patterns and JIT is rather simple in .NET (e.g. vs JVM), so it's easy to break or miss some optimizations.

Yes, it's not a fundamental limitation of the language itself. But considering the amount of hypothetical efforts required to fix all that vs investments from MSFT in F#, it is fundamental. F# lags by several years behind JIT and TPL improvements, the issues are mostly known. But it feels like it's not that important for F#. It's is not for writing fast libraries, but for Python-like use cases, explorative programming, or writing code fast when performance is not important (no hot loops in F# code) but strict typing discipline makes code less buggy and more maintainable from the first attempt. They used to say that "if F# code compiles, it's probably correct" - that is close to the truth, but do not expect top performance without fighting with the F# compiler. Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling.

> Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling.

To be more specific, it has a C# library so it can use _unsafe {}_ blocks to perform manual memory management. This is one key performance-oriented feature that F# lacks.

Other than that, you _can_ write F# that's about as fast as non-unsafe C#, although it means giving up most of the nicer and safer features of F#. Use mutable structs and classes instead of immutable records, for/while loops instead of higher-order functions, magic values instead of option/result types, etc... I've done it in a couple of hot paths where it made sense, but quite reluctantly.

Inline functions are still fine though for writing zero-cost helpers, and I don't think C# has them (there's an <AggressiveInlining> attribute but IIRC it's just a hint, the compiler isn't required to actually obey).

Ironically, F# _could_ become the best language for high-performance .NET programming, because it supports directly inlining IL instructions intermixed with regular code (whereas C# has to go through the ILGenerator class). Unfortunately it's considered such a niche case that it's not planned to be expanded beyond the standard library, and to use it in your code you have to enable an undocumented / unsupported compiler flag.

> Inline functions are still fine though for writing zero-cost helpers, and I don't think C# has them (there's an <AggressiveInlining> attribute but IIRC it's just a hint, the compiler isn't required to actually obey).

In F#, you cannot disable inlining of small functions. It does IL source code inlining, like copy-paste, not machine code inlining. That increases generated dll/exe size a lot for generics. And sometimes you do not want to do that because it's worse for performance. There is an issue for that: https://github.com/fsharp/fslang-suggestions/issues/838

In C#, the AggressiveInlining attribute works well, in predictable manner. Non-inlineable cases are well known (`throw\switch\fixed\try..catch\calling delegates` and some more https://github.com/dotnet/runtime/blob/master/src/coreclr/ji...).

> because it supports directly inlining IL instructions intermixed with regular code

This works for very simple things only. And using InlineIL.Fody, Sigil, raw IL.Emit or just raw IL code as text is not that more difficult if you already know IL.

> you _can_ write F# that's about as fast as non-unsafe C#

I tried this several times. It always ends with fighting the compiler more than just rewriting in C#, even without the `unsafe` keyword. In most cases due to generated IL that I cannot control from F#.

F# does a good job with tail-recursion, though - you can make the for/while loop safer this way. https://www.gresearch.co.uk/article/in-favour-of-recursive-f...

But it adds .tail prefix before every callvirt instruction and this breaks some JIT optimizations. E.g. generic type specialization 'if(typeof(T) == typeof(...))' breaks, I had to dig into compiler source code to find out that it doesn't add .tail before ctors, used a struct wrapper and called a method in the struct ctor to avoid .tail prefix, but it adds its own overhead.

Also, most simple tail calls are rewritten by a compiler to a loop, but if you look at the generated IL, there are multiple temp variables, locals, needless assignments. Maybe JIT is able to eliminate those, or maybe not... In C# I could get IL that reflects what I write, without surprises.

Slight correction: .tail prefix prevents inlining by JIT, it's mentioned in the second link in my sibling comment as "explicit tail prefix in callee". So even if that type specialization JIT optimization worked, the small performance-critical method containing it was not inlined. But the point of the specialization was to make the call for primitives faster than a method call, and fallback to a default implementation via callvirt. And there is no way to disable adding the .tail prefix to the calls that do not need it.

This also means that a lot of F# functions that are not inlined by F# source-code inlining itself effectively have NoInlining attribute. E.g. some helper method `if x then y.call() else z.call()`, if not inlined by F#, will never be inlined by JIT due to .tail prefixes before the methods calls.

But F# isn't a pure functional language, is it? https://www.google.com/search?q=is+f%23+a+pure+functional+la...

You can use a teaspoon instead of a spoon to eat soup. That doesn't mean it's the best utensil for that specific task.

> proximal abstractions

Proximal? Maybe you mean appropriate? Or incremental?

Without the Visual Studio tools for GUI and database modeling, so it ends up being just usable for writing general purpose libraries.

So, we just carry on using VB.NET, C# and C++ instead.

Isn't 'writing general purpose libraries' most programming? I think GUIs and database modelling are pretty niche.

Code isn't written in isolation unless we are speaking about programming interviews.

Libraries spring to life as reusable parts from large scale projects.

So the ROI of context switching to F# in the middle of a project, isn't that much if the language is reduced to expressing algorithms.

https://ericsink.com/entries/fsharp_chasm.html

I think one problem is (was?) winforms is not available in f#. (which is c# unique selling point i. m. h. o.)

Are you thinking of something else than winforms?

I believe winforms and WPF has always been usable but not with the visual designer tooling in visual studio.

UWP has been trickier though to my knowledge.

I probaby meant the visual designer tooling. (Which is a big point in using Visual studio)

I'm a long-time Emacs user, Scheme fan, functional programming advocate ... Who uses C# in his day job.

For quite a long time F# simply wasn't ready, and by the time it was C# had already become an industry behemoth.

But more critically, it's not a language that's officially supported by Unity. That's enough for it not to be a wise choice to be betting a project on it where there are dozens of jobs on the line, and families that could be impacted.

I can't help but think that this concern isn't simply isolated to Unity software development; where else has the decision been made to not use F# on account of it not enjoying as much industry support as C#?

I can't say that I've ever known anyone who uses Unity professionally but if that's your line of work it would be a big factor.

Sitecore, SharePoint, all the GUI designers for Forms, WPF, UWP, WinUI, EF (Core), WCF, gRPC, upcoming Code Generators.

I've done FP (several years of Erlang), and I use FP daily in my work (since most languages support FP to varying degrees).

I see no point in F# other than "well, it's a nice-ish ML for .NET", and the article does nothing to help with that (file order? really? that's what you're going for as the first point to make about a language?) .

Well, now it's also a "nice-ish ML" for javascript, thanks to Fable.

Yep, wish JVM had it too, and no Scala doesn't count.

Frege? (https://github.com/Frege/frege)

Oh yes it does count. Scala can be a nice functional language, with a powerful module system.

Although I miss type providers, enforced lack of cycles and other nice things, like syntax:

https://contributors.scala-lang.org/t/scala-3-very-impressiv...

When the mothership makes all the shiny toys only for VB.NET, C# and C++, that is bound to happen.

Agree, although C# is constantly evolving.

That certainly is playing a huge part in it. C# is importing more and more F# features so people aren't really inclined to switch.

Reply on news.ycombinator.com