Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Migrate from F# to C# when possible #68
Existing F# code will mostly remain in Spreads, at least collections. Immutable collections are just perfect
Keep it here for the record, a post from my nuked blog that originated from this issue:
Functional programming is a tool for thought, imperative programming is a tool for hacking
"Why I am taking a pause with F# development (until tooling is fixed or I buy 32 core/64 Gb machine)"
TL;DR; F# is great for algorithms and analytics. It could work for libraries, interop and high-performance
I have been functional programming aficionado for a while. At some point, I took its advantages over
But lately, I started to dig even deeper and closer to the metal, to use unsafe code, to do many small
F# is probably the best choice for end product development, but not the one for libraries that require
Recently I have bought the very top model of MacBook Air with 8 Gb of RAM for development. Specifically,
Refactoring and simple edits take a very noticeable pause for type inference to finish and for IDE to become responsive, and this pause grows non-linearly with a project size. I understand
Project recompilation happens on every build, even if there are no changes in the code. And it is slow.
Each problem is minor in isolation, but when this happens very often, then most of the development time is spent on tooling,
Generated code performance
Generated code performance is also an issue: to get it right in F# one has to write really ugly
Native interop and unsafe could be done in F#, but this is ugly and clumsy. The Recent addition of
Task Parallel Library is the best thing since sliced bread in .NET universe. Async/await came from F#.
File and type ordering is an F# limitation that magically turns into blessing most of the times. But when it doesn't,
Implicit allocations and IL generation are almost fixed in latest versions and have proper attention from the core team,
One could say I should fix F# itself since it is open source, but for the same reasons above
Despite the issues above, there is nothing wrong with F# itself and there is still a way to write efficient code.
.NET Core interop
This is both tooling and language issue. I often feel that Microsoft almost said: "F^&k you, come back in a year".
When .NET Core was in alpha/beta, it was OK. Now it is 1.0 and there should be no excuses.
If you think this is just F# critics and rant - don't get me wrong. This is an open question and a call for action.
F# is very great and functional programming has many good parts. F# is still faster than Scala,
This post started this morning from an issue on GitHub