Testimonials and Quotes

Historically, our code base has been written in a mix of C# and VB.net. F#’s excellent interoperability with the rest of .NET allows us to use it for components where it’s particular strength’s shine without having to discard or rewrite our existing code.

Whether it’s driving the build and continuous integration system (due to scripting being a first class citizen in the F# world) or writing rock solid infrastructure components (due to the easy use of functional paradigms via features such as computational expressions, type inference and discriminated unions) we have found our F# code to be concise, easy to write and reliable to use. It is a perfect fit for many components within our messaging based architecture.

We would recommend it as an additional tool in the kit of any company building software on the .NET stack.

I did a public records request in my town of Cary, North Carolina. The dataset included appx 25,000 traffic stop records for 2012. Using F#, I did some basic statistical calculations to determine that when you are driving is much more important than where you are driving in terms of getting stopped. In fact, the term ‘speed trap’ is a misnomer. In addition, the data supports the notion that there is a monthly quota of tickets being given. You can read the entire analysis here

Also, I created a KNN classifier using the date/time of the stop and determined that when you get stopped impacts weather you get a verbal warning versus an actual ticket. You can read the entire analysis here

Finally, I did a public records request in the county in which I live: Wake County North Carolina. The dataset included appx 5,000 health inspection scores for 2012. Using F#, I did some basic statistical calculations to determine that there is little variance of when a restaurant gets inspected and their final score. An interesting offshoot is that some particular restaurants scored lower across all inspectors - except when head inspector did the inspection, then they actually scored better. There might an inherent cultural bias by the inspectors. You can read the entire analysis here

F# was great because I spent less time figuring out how to answer my question and more time actually answering the question. The type providers made consuming and integrating hetrogenous datasets a snap and the pattern matching feature reduced the complexity of the code by an order of magnitude (compared to C#). Finally, by using unit tests and immutable data types, I have a bug-resistant code base that can be extended to other scenarios.

Around 95% of the code in these projects has been developed in F#. F# allowed for rapid development of prototypes, and thus also rapid verification or falsification of the underlying mathematical models. Complex algorithms, for example to compute Nash equilibria in game theory, can be expressed succinctly. Units of measure reduced the chance of errors dramatically: Prices, probabilities, derivatives, etc. can already be kept apart at compile time.

When starting to work with Microsoft’s “Modern” WinRT apps, I started by taking the obvious route and used C#. This worked, and I wrote good, functional apps. Despite this, modern programming with C# has problems. I encountered these when writing my BitTorrent app, Surge, and eventually rewrote the app using F#. Doing this gave me better performance, fewer bugs and better user satisfaction.

Users expect performant software with an always responsive UI, and frequently expect the apps to work with and display large amounts of data. This leads to us, as developers, working with complex data structures, detailed lists, and to use techniques like parallelism and asynchrony. C# has gained support for these over time, through things like Linq and async/await, but these are poor imitations of the original F# implementations and have flaws.

Using a modern, functional language that provides first-class support for things we need in modern development is a no-brainer. Immutability-first as a programming technique has fixed more bugs and bad code in my applications than almost anything else I’ve ever looked at, and it’s something C# will never gain.

It’s not just C#, either. Many languages are evolving to be ready for the future, adding features that support the needs of a modern programming language, but F# is already there.

I lead the Biological Computation group at Microsoft Research, where we are developing methods and software for modelling and analysis of biological systems. We have been using F# in our group for the past 7 years, and it’s the language of choice for all of our software development. In particular it forms the basis of our software for programming computational circuits made of DNA, for programming genetic devices that operate inside cells, and for programming complex biological processes in a modular way.

The functional data structures and static type-checking that F# provides are ideally suited for developing these domain-specific languages, and the Visual Studio integration is superb for debugging and source control. The integration with .Net is seamless, and allows us to incorporate efficient numerical and visualisation libraries written in C#. It also allows us to take advantage of the full suite of .Net UI components.

Our languages are specified with a formal syntax and semantics, which are rigorously analysed prior to their implementation. Programming in a functional language like F# brings the implementation much closer to the formal specification, which is important for ensuring accurate simulation and probabilistic analysis. Correct implementation of the semantics is critical, since even small coding errors can give rise to divergent predictions, which can in turn compromise biological experiments. F# is a great language for writing clean, concise code, which is statically typed within a professional development environment that supports a wealth of libraries. It will continue to be our language of choice for scientific computing.

I evaluated F# and found that for certain tasks it was better than C# in terms of performance while maintaining suitable readability and for certain tasks, it leant itself better to certain algorithms (OctTree based color quantization stands out). …we were able to heavily leverage inline functions in F#……Since each of these are inlines, the F# optimizer can actually do something useful with the code. By using F#, we were able to address this cost by using inlining, code profiling, scanline caching, memoization and other techniques. In many cases we ended up with code that ran in equivalent time to C++ code or in some cases faster.

One of the world’s largest insurance companies have F# code in production, are starting several more projects in F#. We are currently consulting for this company (£2.5bn profit) who have migrated some of their number crunching and business logic to F# and are so happy with the results (10x faster and 10x less code vs their Visual C++ 6) that they are proposing to migrate 1,600,000 lines of code to F#. In particular, their developers found F# easy to learn and use.

… my predecessor developed an entire pension quote calculator (typically scheduled to take 300-400 man days) entirely in F# in under 100 days with no prior F# experience at all. Performance is 10× better than the C++ that it replaces because the new code avoids unnecessary copying and exploits multicore parallelism. Part of my job here will be to give basic F# training to around 20 people and bring a few people up to expert level.

In answer to “Can you give any evidence for 10x performance gain over C++?”. The insurer’s C++ code is a simple manual translation from very inefficient Mathematica code that suffers from several pathological performance problems mainly centered around excessive copying. The F# rewrite does not have these problem. The 10x performance gain was verified by the client.

At Bayard Rock we work hard every day in the pursuit of new approaches towards anti-money-laundering. Before adopting F# there were often months of turnaround time between development of an idea and actually testing it on real data in our production environment. F#’s succinctness and composability allows us to rapidly iterate on ideas while the type system acts as a safety net. On top of this, it has the advantage of being a first class member of the .NET ecosystem and so integrates seamlessly with our Microsoft stack systems. This means that instead of months we can often see our ideas come to life in just days.

The benefits of functional programming in F# have given us a great advantage over our slow moving competitors. After three years of using F# our products have consistently gotten significantly better each year without sacrificing stability. Our clients often are amazed by how we can quickly adapt to unique challenges and how we can find the bad guys hiding in their data much more effectively than anyone else. Little do they know that it’s largely thanks to our secret weapon, F#.

Bohdan Szymanik, CTO at Kiwibank, is keen to show how he’s been using F# for analysis tasks within the bank. He’ll provide an intro to the language then show its use for performing aggregations over large datasets, taking advantage of CPU and IO parallelism, and data presentation through charting and image generation.

We are using F# because it considerably increases speed of software development which is crucial for a small company with limited development resources. The most enjoyable feature of this language is that the developer can reason about the code instead of relying only on unit tests. I would say the language encourages Reason Driven Development methodology which leads to virtually bug-free code. F# as strongly typed functional language ideally fits for tasks our software solves – Fixed Income securities trading optimization. It is also very important that F# computation engine could be seamlessly integrated with other parts of .NET-based software product.

I’m one of the first users of F#, since 2004. In my work (e.g. SLAM, Terminator, Zapato, T2, etc) I find that F# is the night vision goggles I need when I go into the dark and attempt to solve previously unsolved problems. Everything becomes simple and clear when expressed in F#.

TimeRocket is a service for attendance time tracking and absence- and shift-planning provided by Calitime AG. The system runs on Azure, and we use F# on the ASP.NET backend and Azure Functions to program the business logic. We like F# because discriminated unions, pattern matching, computation expressions and out-of-the-box equality allow us to keep the code simple even in complicated business cases.

Vector code is a code generator for iOS and OsX generating code in Objective C, Swift and C#. It works with vector graphics, parses and runs SVG. It is developed with F# on a Mac.

F# is a first class language for Mac OsX. Thanks to the open source compiler, I was able to build a vector drawing, code generator software with F#. It is really amazing experience! The tooling is great and keeps improving. The compiler and the language are basically the same which is fantastic!

F# is a powerful language and it is great to do cross platform development with it. I used heavily quotations for generating code in different languages on vector code. Powerful type system and static compilation meant that, once the application compiled without errors and warnings, it will just work and generate complete code. It did, and now at the App Store.

The expressiveness and power of F# has resulted in shorter build cycles, simpler business logic (with fewer bugs!) and the ability to quickly evolve the product.

Type Providers have let us add support for a lot of data formats (Government formats, Excel files, third party sources) very quickly. Pattern matching has made it possible to simplify complex business logic. F# has been a joy to work with, and we’re using it more and more throughout our products now.

The credit markets have varying pockets of liquidity. Market participants would like to understand how the liquidity of their set of entities changes relative to the overall market. A liquidity scoring model is needed to provide these metrics across the entire CDS universe. Functional programming and specifically F# was used in order to provide the market with a fast and accurate solution. … The research and development cycle was made faster and more efficient by the effective use of functional programming.

The efficient use of functional programming throughout the R&D cycle helped make the cycle faster and more efficient. Less time was spent on translating requirements, miscommunications etc and more on producing a fast and accurate solution quickly.

Since programmers can understand your quant code they can focus on their core competency – developing fast and reliable production code. The development exercise becomes catered towards optimization, performance tuning and error handling (i.e. making the code reliable) Functionality is not lost from the prototype due to miscommunication or rather crude documentation/requirements, which saves time in testing. Mass regression testing is easy with precise precision level differences between the prototype and the production system.

As a consultancy geared towards delivering solutions to customers in a variety of sectors, we rely on F# for all of our solutions, whether it’s a rules engine, a distributed and scalable data transformation system on Azure or a customer-facing web application. I love the fact that we have confidence in our deliverables thanks in no small part to the pit of success that F# leads us down; we very, very rarely encounted bugs that we saw time and again with other languages and frameworks. At the same time, we’re able to consistently deliver to our customers much more quickly than we might have done otherwise - a key value proposition for many of our customers who often need a short time to market.

Building valuation models for derivative trades requires rapid development of mathematical models, made possible by composition of lower-level model components. We have found that F#, with the associated toolset, provides a unique combination of features that make it very well suited to this kind of development. In this talk, I will explain how we are using F# and show why it is a good match. I will also talk about the problems we have had, and outline future enhancements that would benefit this kind of work.

The abstract to a talk at the Commercial Users of Functional Programming workshop

You can formulate many problems much easier, closer to their definition and more concise in a functional programming language like F# and your code is less error-prone (immutability, more powerful type system, intuitive recurive algorithms). You can code what you mean instead of what the computer wants you to say ;-) Furthermore you can have F# and C# together in one solution, so you can combine the benefits of both languages and use them where they’re needed.

With F#… we have written a complete genome re-sequencing pipeline with interface, algorithms, reporting in ~5K lines and it has been incredibly reliable, fast and easy to maintain.

F# rocks - we’re building out various algorithms for DNA processing here and it’s like a drug. Just implemented a suffix tree in 150 lines that can index 200,000 bases a second ;) We have probably 10-20K lines of code for many scientific applications ranging from a full genome sequencing pipeline that reconstructs and annotated yeast strains, to simulators for various processes and design tools for building DNA sequences/constructs. There are lab located apps that grab robot log files and move them to databases and a tool for viewing a huge collection of DNA sequencing data.

F# has been phenomenally useful. I would be writing a lot of this in Python otherwise and F# is more robust, 20x - 100x faster to run and for anything but the most trivial programs, faster to develop.

The UI work is especially gratifying, because state of the art for a lot of genomic data display is still PNG images embedded in JavaScript and with F# I can render half a million data points on a web page without jumping through hoops.

With Units of Measure I started labelling the coordinates as one or zero based and immediately found a bug where I’d casually mixed the two systems. Yay F#!

Our graduate course on Parallelism this Fall is full, even though it assumes no experience with functional programming or F#. The students are preparing the courseware themselves, and one of the topics we are studying is functional reactive programming (FRP) with continuous, time-varying behaviors. F#, with its rich graphics libraries, made it trivial to construct a super-fun assignment involving purely functional and interactive animation of a mock solar system.

A couple of years ago we started a greenfield project with backend (microservices) 100% written in F#. The language allowed/allows us to deliver a lot with a very small team, resulting in a concise and easily maintainable codebase.

We are solely focusing on the basics - functions and records, and shying away from OOP or any other complicated constructs. Among the “exotic” features of F# we use are only a few computational expressions - Async, AsyncResult, Result, as well as the units of measures for strongly-typing GUIDs and other domain attributes. Even Dependency Injections we with straightforward partial application unstead of using the sophisticated Reader monad or similar.

Being a member of the .NET family F# still gives us access to .NET BCL and any (performance) improvements of it, as well as to all 3rd-party libraries written in C# (e.g. Azure SDKs, sftp, email clients and many others).

Onboarding of new team members (usually with C# background) has been pretty easy and quick.

I do some samples in F# for the lectures and the book, but all that is within a single-user VS 2010 Pro installation. Right now we have a set of slides on functional programming with F# in Russian in the curriculum repository, and the video-course of functional programming using F# available in the largest Russian Internet-University (intuit.ru). The course is being taught in 2 universities. There is a noticeable interest in the developer community in Russia towards F#.

The Doctors Laboratory is the largest independent provider of clinical laboratory diagnostic services in the UK. We use F# for the majority of our in house development, from ETL tasks, via reporting scripts to full web applications.

F#’s idiomatic development style, starting with a script in the REPL, before moving functions into a more structured project, makes it trivial to explore different approaches, refactor &c. before committing to a particular approach. It also makes developing more enjoyable and direct – there’s no need to get all the boiler plate/plumbing in place; you can just create a script and start coding. The compiler’s type inference system also means quicker coding, with less ‘cruft’. Features such as pattern matching and discriminated unions also lead to leaner, more expressive and transparent code.

Type providers mean data can be accessed in a few lines, and there are a wealth of community driven OSS projects available here for a heterogeneous range of data sources. If you need to access a data source not supported by existing providers, then the community positively encourages getting involved to provide one yourself, as in fact we did with the MSACCESS provider for the SQLProvider type provider. The community is first rate in terms of providing support in forums like Stack Overflow, gitter, etc. Other community projects such as Paket (dependency management) and FAKE (build too) make build automation a breeze, too.

F# was used on Microsoft’s AdPredict project for adCenter. This was a 4 week project with 4 machine learning experts involving a model with 100 million probabilistic variables and processing 6TB of training data in real-time. 2 weeks of CPU time were used during training. Benefits included Quick Coding - F#’s powerful type inference means less typing, more thinking, Agile Coding - Type-inferred code is easily refactored, Scripting - “Hands-on” exploration, Performance - Immediate scaling to massive data sets, Memory-Faithful - Mega-data structures on 16GB machines, Succinctness - Live in the domain, not the language, Symbolic - Schema compilation and “Schedules” and .NET Integration - Especially Excel, SQL Server

With an idea for a new domain specific language, my team chose F# for its functional paradigm, maturity, and ease of interoperation with the .NET framework. I wrote the language primitives in F#’s arsenal of data types (records, discriminated unions, a couple classes at the top level), implemented operations on the types using its hierarchy of modules, and turned our operations into a working demo in F# Interactive, all in about 10 days.

I jumped for joy each time my code executed correctly on the first pass, and in the few cases it did not, debugging through Visual Studio felt natural and quick. As for .NET, integrating with Microsoft Excel was easy by importing the necessary DLLs, though Excel posed challenges beyond F#’s reach. Finally, I can verify that F# delivers a sense of correctness and safety, stronger than other languages I worked with in the past. It is reassuring to know your code will execute exactly as you intend.

Early Warning Indicators is a standalone dashboard application to monitor real-time market movements and highlight potential risk for further analysis. EWI subscribed to real-time equity, Forex and commodity prices and needed to calculate Red/Amber/Green status in real-time for tolerance breaches and to generate dashboard reports as needed.

The business wanted the flexibility to define formulas using Excel expressions, but spreadsheet components could not cope with the data-rate without conflation and management didn’t want a solution that relied on an Excel template and IT change control to add new indicators.

F# was chosen for development productivity, performance of a cell framework implemented using computation expressions; ease with which Excel expressions could be parsed as a DSL and .NET integration with QALib, Market and timer-series data.

Post implementation review highlighted that (given resource and time constraints) functionality would have been sacrificed without F# and its associated tooling.

We develop security product to protect critical infrastructure (e.g. Oil Refinery, Airport, etc) for countries across the globe…. In core of our product there are prediction algorithms. We use different modeling and theorems (Monte Carlo, Action, etc) to implement the prediction components. … Since we are rewriting our next generation product using .NET, we have decided to use F# as functional language to have automatic integration with rest of the system. … We also have advanced machine learning components (Artificial Intelligence) and functional languages are the best fit to write AI stuff. We are planning to use F# as the primary programming language in this area because of its interoperability with .NET.

A large financial services firm in Europe sought new development tools that could cut costs, boost productivity, and improve the quality of its mathematical models. To address its needs, the bank deployed F#, the .NET Framework, and Visual Studio. It will soon upgrade to Visual Studio 2010 and then integrated F#. With its new tools, the bank can speed development by 50 percent or more, improve quality, and reduce costs.

I am the lead developer of Galaxy Wars, and I can tell you, F# really saved us a ton of effort. Monadic coroutines alone I believe are the reason why we manage to ship the thing on time…

In recent years many Architects have discovered that they can greatly enlarge their design repertoire by the use of parametric design, programming or scripting. Architects can now quickly and easily explore new geometries previously unseen in Architecture. Besides being designed in a novel way these geometries can also be exactly represented and reasoned about in terms of structural feasibility and manufacturing constraints. These facts take new geometries out of the dreams of Architects and make them real candidates for construction.

One such project is the Louvre Abu Dhabi by Jean Nouvel. Waagner-Biro was awarded the construction contract for the Dome. For the cladding of this dome more than 450´000 individual cutting and drilling patterns of custom aluminium extrusions had to be described and automated. The sheer scale and complexity of the cladding on the dome required us to re-evaluate our parametric design approach. I developed an F# application to represent and organize all cladding elements of the dome. It includes a small geometry kernel and an adapted version of the Half Edge Data Structure to efficiently query the neighbourhood of each element. I used Rhino and its .NET API to host the F# DLL for drawing and visualisation. This application enabled us to have an integrated workflow from the main geometry setout all the way down to the manufacturing data in a single parametric model. This project was the first use of F# at Waagner-Biro for a large scale project. The switch to F# from dynamic scripting languages helped to reduce development time and execution time. The strongly typed environment, algebraic data types and immutable data helped to avoid a whole range of bugs and fits well the domain of generating static 3d geometry. I see great potential for F# to be used as scripting languages in CAD, especially since most big CAD packages already offer a .NET API.

(Image credits: Jean Nouvel Architects)

For nearly 75 years, Grange Insurance has offered competitive products and services to policyholders in more than a dozen U.S. states. To maintain its well-earned reputation and standing, the company decided to enhance its rating engine—a software tool for rating policies and performing what-if modeling, impact analyses, and other vital activities. Working with the Sophic Group and using the Microsoft Visual Studio Team System development environment and F# programming language, Grange Insurance parallelized its rating engine to take better advantage of multicore server hardware, and in so doing garnered significant performance benefits. Processes that used to require hours now take just minutes, enabling the company to trim time-to-market by weeks and making it far easier for independent agents to sell and service Grange products.

At Green Eagle Solutions, we develop control systems for renewable energy plants. Thus, it’s crucial for us to test our software in a real-time environment where are all the other actors (protocols, weather conditions, legacy software) come into play.

Beforehand, we used Python to quickly build simulators to test our components. With F# we have now all the advantages of a dynamic language, while keeping the static typing safety we are used to. The fact that we don’t need to leave Visual Studio and being able to seamlessly use all the APIs we have developed in C# are also a big plus.

We have also started to use F# directly in our components to implementing the core logic, while leaving C# to networking tasks. We’ve taking advantage of this language mix to create a dependency injector which recompiles the F# logic at runtime whenever the script changes for quick development iterations, but loads a precompiled .dll when deployed in production. The double nature of F# as a scripting and a compiled language really shines here.

F#’s terse syntax made the final code look really similar to the algorithm we wrote at first in formal language. Also, we’ve come to really appreciate the numerous metaprogramming libraries in the F# ecosystem: we particularly like FSharp.Formatting and have started to adopt the literate programming style to integrate as much as possible the code and the documentation and prevent them losing sync.

I first evaluated F# back in 2006 - 2007 for the purpose of math oriented high performance applications within Financial Risk. I got in spring 2009 a mission to implement a new Real-time Counter-party Risk system covering all possible present and future deal types within the entire bank. The effort was started with only three resources, me as architect and lead developer and two colleagues – one risk expert and one high performing developer. Our first intention was to use C#, but I did a quick proof-of-concept with F# implementing a low level TCP/IP-communication to an existing risk-system. This showed us and our management that F# could give us a real productivity boost due to its support for multiple paradigms and functional concepts together with an impressive support for multi-threading.

Our first delivery is approaching rapidly and F# has proved itself as a real life-saver. We started off using C# in many places but have since then moved almost entirely into F# due to its ability to reduce the amount of code required and its simplicity when developing massive parallel computations. The performance is phenomenal. We can now re-calculate the entire bank portfolio from scratch in less than a second and the response-time for single deal verification calculation is far below 100 milliseconds(the original demand was 200 milliseconds to make the application usable for electronic markets). Although some gains are to be attributed to how we have built our calculation models, F# made it possible for us to implement our algorithms and techniques with very little code and with a huge similarity to the original mathematical models and regulations (which is important for verification of correctness). We have also been able to use the support for Async-workflows producing code that is simple and clear and easy to understand but still runs in parallel when required.

The present application contains 35 to 40.000 lines of F#-code and an equal amount of C#-code. However, our estimate is that the F# code contains at least 80% of the functionality (which is pretty amazing!). Our experience shows us that the number of code lines shrinks with a ratio of 1/2 to 1/4 by just porting functionality from C# to F# (not counting single character or empty lines in the C#-code). We have by remodeling increased the ratio to the area of 1/5 to 1/8, where the remodeling involves replacing object oriented constructs with functional ones (and actually removing mutable states). One example from last week was a limit-utilization module written in F# but using an object-oriented approach containing +300 lines of code. I rewrote it to below 70 lines of code just by shifting paradigm (and the rewrite made it much easier to understand and verify)!

I was approached by my former colleague Michael (Michael R. Hansen) in autumn 2010 where he proposed that we should write a new textbook on functional programming - now using the F# programming language. To begin with I was quite sceptical about using a programming language appearing as part of a Microsoft program package. Solving a number of programming problems using the language convinced me, however, of the supreme qualities of F# - and we embarked on the project of getting acquainted with F# and writing the textbook.

Michael and I spent considerable time solving traditional programming problems in F#. A combination of functional and imperative F# with an occasional pinch of OO gives a very pleasing platform for program development - once you have found your way through the wilderness of MSDN documentation (newcomers to the MSDN world may benefit from the MSDN library documentation found on the web-site of the book. All of Chapter 10 and part of Chapter 11 present program examples using this programming style.

Computation expressions look esoteric to begin with, but they are actually rather useful. We spent much time trying to get this concept down to earth, with the purpose of making it accessible to simple-minded people like ourselves. The reader may judge how far we succeeded by studying Chapter 12 of the book.

Writing this textbook with Michael has been an exciting experience.

F# programs tend to be much shorter than their equivalents in other languages. The fewer lines of code required, of course, the higher the productivity. When F# is combined with Visual Studio, which provides help with remembering the methods attached to different data types and how to use those methods, productivity goes through the roof!

At Insurello, F# lets us model complicated business data with a lightweight syntax in a way that feels closer to reality. The type system helps us avoid creating impossible states and enables us to focus on the business problems. The compiler and the use of exhaustive pattern matching have saved us from what could’ve been many mistakes in production. F# is “just the right amount of FP” which helps us write simple and maintainable code and makes it easy to onboard people, even those with no background in Functional Programming.

We wanted to develop our Android and iOS applications using as much shared code as possible. We built a reactive architecture using F# actors (aka mailbox processors) to build a very robust multithreaded system that was easily portable between Android and iOS.

Our F# actors (shared across iOS and Android) expose .Net IObservables that are consumed by UI systems written for the native platforms. Dividing the system in that way allowed for testable multithreaded code that would have been difficult to write in other .Net languages.

Over the last 6 or so months, I’ve been working on a Vim emulation layer. This is the first major project I’ve ever done with F# and I have to say I love the language. In many ways I used this project as a method of learning F# (and this learning curve is very much evident if you look through the history of the project). What I find the most amazing about F# is just how concise of a language it is. The Vim engine comprises the bulk of the logic yet it only comprises 30% of the overall code base.

Every day we analyze data for hundreds of thousand of properties, sourced from XML and JSON feeds. Features such as Options and Type Providers have given us incredibly concise, expressive, and testable code with which to handle them, freeing us to focus on business value.

As a developer moving from C#, some of the concepts you read about functional programming can be difficult to grasp and the barrier to entry appears high. However, with just a basic understanding and a helpful and welcoming community, F# has proven to be very productive and has quickly become my language of choice.

The site amancai.com.au was built combining F#, Domain-Driven Desing, Asp.Net MVC and Azure. F# was an excellent choice as it allowed us to keep the code lean and very functional while having full access to the BCL, Azure and third party libraries.

Using F# Type Providers also helped us to improve our productivity and find problems early during the development process.

I personally enjoyed the experience of building the entire system using F#, I believe its “functional-first” approach is excellent for building a wide range of applications.

I first ventured into F# while working at a US-based startup where one of our servers handling PnL calculations was performing sub-optimally. I decided to re-write that in F# as a test. I was surprised that without requiring any special libraries (unlike the Python version that relied on pandas and numpy) the F# code was similarly concise yet significantly more performant.

When I started CryptoQuant, which allows backtesting and live testing of trading strategies on cryptocurrencies, I started writing just the trading rule parser in F#.

The illustration of the first version of the parser can be found on my public git repo. It parses subset of Typescript into F# interpretable AST, which can later be evaluated against data to calculate entry/exit signals.

Because parsing with Fparsec went so well I later gradually migrated entire project into F# (from C#). The beauty of this approach is that I don’t need any specialized F# libraries - I can stay very close to the original (C#) dotnet server, avoiding dependency on specialized F# third-party packages. I can still use great dotnet server features like background jobs or dependency injection.

At Kaggle we initially chose F# for our core data analysis algorithms because of its expressiveness. We’ve been so happy with the choice that we’ve found ourselves moving more and more of our application out of C# and into F#. The F# code is consistently shorter, easier to read, easier to refactor, and, because of the strong typing, contains far fewer bugs.

As our data analysis tools have developed, we’ve seen domain-specific constructs emerge very naturally; as our codebase gets larger, we become more productive.

The fact that F# targets the CLR was also critical - even though we have a large existing code base in C#, getting started with F# was an easy decision because we knew we could use new modules right away.

As a business we actively seek improvement every single day. This is the same for our IT systems, so we have been searching for a means to do that in our in-house software systems.

The F# type system has allowed us to do this - by eliminating null references, increasing type safety and creating rich domain models that help us express hard-and-fast business rules in a way that we can really lean on the compiler; while actually reducing our total lines of code (and noise!). Doing so has reduced both our requirement for expensive bug hunts in our production systems, and the overall cost of maintaining unnecessary code complexity.

We have been evaluating F# for a year now, and have components in our production systems that have been bug-free since deployment. The results speak for themselves.

We have set up a complete risk management system that combines several data sources, presents them in a … WPF user interface, and does a LOT of calculation behind the scenes. When the calculation requires a proper algorithm (i.e. anything that is more complex than a simple for loop), our choice has been F#. I have to say I keep being surprised by how compact it is and, nonetheless, how readable it is even when I’m reading code that I hadn’t looked at or thought about for six months.

At Lula, we have found F# to be an excellent choice for building domain-driven APIs to service the insurance industry. The sensible defaults (immutability, non-nullability, algebraic data types, etc.) along with the power of the F# compiler enables our team to quickly and concisely develop systems. The developer experience and tooling is top-tier and the ecosystem is rich and vast, thanks to F# targeting the .NET platform. In addition, the nature of the type system moves an entire class of errors from being runtime errors to compile-time errors.

I would recommend any software engineer that cares about their craft to take the time and learn F#…not only will it make you a better developer, you will have some fun along the way!

Since I started programming, I tested a lot of languages. I used PHP, JavaScript, C#, Elm, Lua, etc. And now I am using F# for all my projects. Since I discovered F# I’ve just found the language that I searched for so long as it has a lot of possibilities.

The tooling for the language is great and also this language is really supported by is community and I love that.

And finally, F# is a language with which I’ve become really efficient and I find that if I write a code the type inference assures me correctness. I am still waiting for the first bug to appear in my production app.

When I started working on the T2 temporal logic prover, I knew little about termination analysis and formal verification. F# made it easy to dive into these concepts and boosted my productivity by allowing me to write clean, concise, and accurate programs. Its functional nature, clear syntax and type inference is combined with the flexibility to write in an imperative style and use the .NET framework. This combination powerfully bridges the gap between thinking about a concept and implementing it. Programming in F# feels like writing out ideas rather than code.

I have been a Microsoft Student Partner (MSP) for three years, which offered me the opportunity to be in touch with most portuguese faculties and their students, getting the change to be a bit of an evangelist for Microsoft technologies. I chose to spent my MSP experience giving introductory seminars to F# and functional programming using F#. So far, I have given these presentations on most portuguese faculties and also at Microsoft portuguese headquarters. The result is always the same: everyone gets really amazed when they try F# and experience its immense expressive power, its delightful syntax and realize they can do functional programming (which is oftenly taken as something boring and complicated) on a familiar and confortable environment. Currently, along with a fellow portuguese MSP, (following the success of previous presentations and in response to the many requests for new sessions on F#) I’m preparing an hands-on session on the use of F# for Cryptography, to be presented on a future event at Microsoft Portugal.

Personally, F# offers me a solid and trustable ground to develop reliable and complex applications on a confortable and succinct way, impossible to achieve with other languages and paradigms. With no doubt, I can say I’m a huge fan of F# and I’m always eager to get in touch with every new feature the language has to offer.

I’ve been using F# libraries in otherwise mostly C# / VB.NET web applications. Thanks to the conciseness of F#, I can develop these libraries in a fraction of the time, then I consume them from C# and VB.NET just like any other library.

Furthermore, F#’s succinct syntax and REPL make it an excellent scripting language and good for data exploration. Thanks to F#’s interoperability the scripts can easily use domains and libraries written in C#. You never need to start from scratch or have to reinvent things.

Language features like record types, discriminated unions and type inference also make F# a great language for prototyping. I often prototype new business domains in F# with a few simplified use cases to refine it. The simple syntax allows me to focus on developing the domain and iterate more quickly. Then, when company policy requires it, I translate it to C# which is usually a straightforward process that ends up with many times more lines of code (yet still perfectly maintainable).

In our internal engineering group at Microsoft, F# is used for several important tools:

• analyzing feedback on the web to look for compatibility-related issues,
• a static code analyzer to detect compatibility regressions in a product,
• a delta-debugging tool to help root cause regression analysis in product builds.

Producing an F#-based book on functional programming has been a fantastic experience.

Using this material in an F#-based course introducing the fundamental concepts of functional programming has been a delightful experience as well. The simple, well-designed, yet powerful, core of the language was perfect for that purpose and, to our surprise, the transition from using SML to using F# actually made the tooling easier for students no matter which platforms they used.

Furthermore, F# with it rich runtime environment has proved to be an excellent programming platform in research applications and in a more advanced course aiming at showing the role of functional programming in a broad variety of applications ranging from computer science applications to more real-life applications. In the first version of this course, given together with Anh-Dung Phan, the students completed three projects in three weeks: One being an interpreter for a rich imperative programming language, another being implementation, application and analysis of a functional pearl, and the last being a curriculum planning system for studies at the Technical University of Denmark.

We use F# in oceanographic research to connect multiple visualizations together in time and space, which is map-plane location and depth. We began by building our Narwhal Developers Library for Layerscape in C# with emphasis on visualizing flow lines and understanding drift experiment data. These data are quite complex, involving physical ocean state and measurement of microbial metabolic processes, consolidating remote sensing and passive drifters, and adding to all this current measurements with the tracks of autonomous robots. Our technical term for the visualization challenge is ‘horrible’.

To cope with the horrible we began adding F# scripts; and this has been extremely productive, particularly in morphing ideas about data exploration into real tools quickly. Our most interesting achievement to date is to wire a chart into a 4D visual environment. The set-up is like this: The scientist sees two views of the data: First color coded structure in a curtain plot of time versus depth (chlorophyll coded as color for example), and second this same data time-boxed in the dynamic Worldwide Telescope (WWT) visualization engine. F# is used to wire them together: Left click (and drag) in the chart to scroll the WWT clock back and forth. Right-click + drag in the chart to select a subset of the data which is then used to construct a new (small) advection visualization. Because the selected pieces are small and chosen interactively we get around the horrible problem of seeing everything at once. It is like seeing an entire forest and making all but a few curious trees vanish. So F# has been a great way to make rapid progress, and fun to learn as well.

F# is central to Microsoft’s quantum algorithm research. The LIQUi|⟩ simulator (Language Integrated Quantum Operations) presents an extension of F# that presents a seamless integration of classical and quantum operations. The scale and efficiency of the simulator allows it to handle among the largest entangled systems of qubits (quantum bits) ever modeled utilizing a targeted linear algebra package written entirely in F#. In addition, the modular architecture allows users to easily extend the system in any desired research direction. The base library is well over 20,000 lines of code and implements a wide range of modules including circuits, molecular modeling, spin-glass systems, quantum error correction, machine learning, factoring and many others. The system runs in client, server and cloud environments. It is also designed to be used as an educational tool and we have found that bringing new users up to speed is a quick and painless process.

I’ve written two commercial apps in F#, WcfStorm.Rest and WcfStorm.Server.
The UI part was in C# and the library part was in F#. In my experience it is fun language to code in.

As an experiment to evaluate functional programming as a production tool we developed a new multi level caching system for our website in F#. Because F# can use existing C# libaries so easily we were able to proceed rapidly using popular packages such as StackExchange.Redis and ProtoBuf-Net. In less than a week we had a flexible caching system in production, complete with an administration page and performance statistics tracking.

We also found that it was straightforward to use our new F# module from within our existing C# code, and that the F# code deployed to and ran as an Azure app service without any special configuration. Adding F# to the code base was completely painless.

The developers on our team are all intrigued by F# and eager to learn more. As well, we find that at college recruiting events, prospective students are very excited to hear that we are using a functional language in production

Path of Go is powered by three technologies…: an AI capable of playing Go, the F# language, and TrueSkill to match online players. The AI is implemented in F# and meets the challenge of running efficiently in the .net compact framework on Xbox 360. This game places you in a number of visually stunning 3D scenes. It was fully developed in managed code using the XNA environment.

F# has a beautiful, simple but expressive language at its core, and many powerful features built around that core language. It can draw on all the power of the .NET libraries, and runs on Windows, MacOS and Linux. That’s the reason we have chosen F# for our undergraduate functional programming class as well as our undergraduate programming language class (link)

Prolucid delivers solutions to customers in markets ranging from Medical Devices, Aerospace & Defence, Nuclear & Energy, Transportation to Advanced Manufacturing.

Our E2C reference architecture has been developed around small F# core and offers platform independence, linear scalability and easy of customization. F# allowed us to leverage the .NET expertise many of us had and combine it with the elegance of functional programming to provide real-time connectivity, event processing and complex analytics solutions for out customers.

We have open-sourced some of this work and you can find it on GitHub.

All of our back-end data processing and parsing is done in F#. The power and flexibility of the language lets us ship features faster, with fewer bugs. Regressions are virtually nonexistent, and the functional nature of the language makes it easy to ensure that our code is testable.

Our first iterations were written in C#, but after switching to F#, we saw a drastic reduction in code size, along with an increase in readability. We’ll definitely be sticking with F# for all of our future projects.

I am involved in bioinformatics and computational genomics as a faculty member at the University of Nebraska Medical Center (UNMC). In an academic medical center like UNMC there are heavy demands on my time and a wide range of different types of research projects that I can end up working on. I have used the F# programming language for several of these projects, including one that involved a very productive collaboration with IntelliFactory and the use of WebSharper.
You can visit the resulting web site and read the freely available peer-reviewed scientific publication that describes the important infectious disease research that this F# software development project facilitates. I am always interested in opportunities to work with professional software development enterprises whose teams include developers with F# expertise, because I believe that many attributes of the F# programming language make it an ideal choice for the development of software solutions that integrate Electronic Health Record (EHR) data and the exponentially growing volumes of molecular analysis data that can now be obtained from individual patients (e.g., personal genome DNA sequencing data).

There’s an exciting future for F# in this huge, emerging, data-rich health care market.

I teach and use OCaml and F# in my lectures (Theory of Computation, Formal Languages and Compiler Design, Formal Methods, Applied Cryptography), and F# is very popular among my students for the programming projects. Most of the students that are supervised by me (undergraduate, master but also PhD) use F# as the underlying programming language. This is even more the case now since part of our research directions includes working on cloud/distributed systems.

F# and its programming environment leverage with no doubt the ability and the productivity of my students. This is, in my opinion, for two main reasons. First, F# allows the student, but also the researcher like me, to focus on the key aspects of his creation, while, secondly, enhancing
technologically the work done in a so remarkable and facilitated way. Once drawn in paper and pencil, an algorithm is naturally implemented in F# and easily deployed in whatever is its execution context.

I am definitively a strong believer of F# and amazed by the language and its community.

I wrote the first prototype of the click prediction system deployed in Microsoft AdCenter in F# in a few days.

For a machine learning scientist, speed of experimentation is the critical factor to optimize. Compiling is fast but loading large amounts of data in memory takes a long time. With F#’s REPL, you only need to load the data once and you can then code and explore in the interactive environment. Unlike C# and C++, F# was designed for this mode of interaction. It has the ease of use of Matlab or Python, both of which I have used extensively in the past. One problem with Matlab and Python is that they are not strongly typed. No compile-time type checking hurts speed of experimentation because of bugs, lack of reusability, high cost of refactoring, no intellisense, and slow execution. Switching to F# was liberating and exhilarating. 2 caveats: Not every problem fits that model. With a bit of discipline, such as avoiding massive parallelism for as long as possible, the model goes a long way. The second caveat is that the cost of learning F# is steep. For me, it was 2 weeks of decreased productivity. It has proven a worthwhile investment.

As a machine learning practitioner programming in F#, I constantly switch between two activities: 1) writing prototype code (highly interactive ugly code with throw away results, functions, and visualizations) and 2) upgrading prototype code to library standard (fast, generic, reusable). When I go back to writing prototypes, I build on top of the newly upgraded functions. In F#, the cost of switching between these two modes is minimal: often nothing needs to be done other than adding comments and deleting deprecated functions.
This means that most of the time is dedicated to experimenting and the majority of the code is close to shipping quality. Some people can do this in C# or Matlab, but I find that F# excels at it.

I started F# with deep suspicions regarding efficiency. My first test was to link F# with C++/CLI and check performance of calling SSE/AVX optimized code. As hoped, F# is comparable to C# when it comes to speed. You have the same flexibility to link with well optimized code. The inline generics are truly magical: same IL in the linked DLLs, but the functions expand to specialized fast code when you instantiate them. Compromises between intuitive code and efficient code still need to be made. I found that “for” loop, “tail recursive” loop, or Parallel.For with ThreadLocal loops, are faster than a succession of piped IEnumerables (seq in F#). F# does not hamper one’s ability to write ugly fast code. Rest assured.

Several people in the machine learning group in Microsoft Research have switched to F# for the reasons above. The world is slowly moving toward functional programming with good justifications: the code is cleaner and easier to debug in a distributed environment. Among the available functional languages, F# is a compelling option.

I have written an application to balance the national power generation schedule for a portfolio of power stations to a trading position for an energy company. The client and server components were in C# but the calculation engine was written in F#.

The use of F# to address the complexity at the heart of this application clearly demonstrates a sweet spot for the language within enterprise software, namely algorithmically complex analysis of large data sets. My experience has been a very positive one.

I am both a C# dev and an F# dev. I can only offer subjective anecdotal evidence based on my experience of delivering projects in both languages (I am too busy delivering software to do anything else).

That said, the one stat in the summary that I find most compelling is the defect rate. I have now delivered three business critical projects written in F#. I am still waiting for the first bug to come in. This is not the case with the C# projects I have delivered. I will continue to monitor and report on this. It might be that I am just on a lucky streak, but I suspect that the clarity and concision of F# code contributes greatly to its correctness.

Covid-19 Tracker Slovenia is a community-driven open source project that collects, curates and publishes Covid-19 data for Slovenia. It was launched in March 2020 and server up to a million daily users.

We use F#/Fable/Feliz for front-end visualization, and F# has proven to be a very good choice for this fast-moving, decentralized project. The majority of people contributing code have never used a functional programming language or even heard of F#. Nevertheless, most contributors were able to quickly navigate the code and develop their own visualizations with little or no orientation and very few bugs or runtime issues.

By using F# and its strong type system, we were able to keep the code base consistent and easily adaptable to this ever-evolving and growing project. And the excellent Fable and Feliz projects allowed easy and smooth integration into the JavaScript ecosystem.

I was consulting at engagement for a large multi-national organization that produces financial software where the need to rewrite the component that deals with importing data from various flat-file formats was identified. The component needed to handle complex business logic and user defined mapping.

F# was chosen over C# as it provided a large number of language features related to mapping out of the box. Code quotations, discriminated unions, partial application, matching, and active patterns were used extensively. Having objects immutable by default made the logic very deterministic and easy to maintain / follow.

I was incredibly happy with the results, particularly with the declarative nature I could use to describe the various mappings, and their relationship with other mappings. This should make it much easier for other developers and the business analysts to figure out what logic is executed when a particular mapping occurs. The core logic saw a big reduction in code size, however, the real saving was in the entity specific mapping logic which saw the lines of code required go down by more than 90 percent!

F# is definitely a language I will be recommending to clients going forward.

Functional languages are ideal for teaching clear thinking, for solving problems amenable to code solutions and it levels the playing field between beginners and experienced programmers. The first programming language taught has a substantial influence on what language students use when they have a free choice. F#, once it is platform independent, has the potential to become the first programming language.

We felt our C# Sync.Today 2013 started to become a huge monster with all the C# scripting, hooks etc. At the same time it was not really providing us with the flexibility we needed to fulfil our customers’ requirements. Instead of just another round of refactoring we decided to start moving to F# with Sync.Today 2015. Since both languages share the same common CLR, we did not throw everything away. We just started to simplify more and more because the F# code has much less lines (we had 146831x “{ or }”, 56555x “Blank”, 2770x “Null checks”, 56194x “Comments” and finally 223502 “Useful lines” and now we have 30602 lines with an order of magnitude more features and benefits ) Since we are processing a lot of information, but without complex computations etc., Orleans became the distributed computing library we build the solution on. It is using mixed C# + F# code now, which is perfect for us and allow us to run both on-premise and in Azure.

Yellow blue soft is a truly international Micro-ISV: We are a small, dynamic and international team who is wondering why file-management is lagging 30 years behind and no one seems to care or even notice. We do. We love what we’re doing and most importantly we love listening to you! Visit our blog to know more about us and join our forum to become part of our sparkling community.

The tabbles are special containers that you can use to categorize any kind of file and document as well as folders and bookmarks. Using Tabbles you can quickly categorize, find, sort and share your documents, in a totally new way.

At the University of Pisa we use F# for teaching UI programming, a fundamental course in the third year curriculum. In 2014 two more courses (Programming I & II) will use F# and Try F#.

We use F# for teaching because it fits teaching both fundamentals and technology thanks to rich programming environment and libraries to access all system resources (such as UIs). Moreover, F# feels like a dynamic language thanks to F# interactive even if it is a statically typed language. Our students use F# on Windows, Mac and Linux. Try F# is a particularly valuable tool for teaching because it has a quite sophisticated editor with interactive evaluation and the ability of sharing saved files with students.

I’ve also used F# for teaching programming for scientists at Scuola Normale Superiore, a PhD course at ITU Copenhagen and to graduate students in biomedical engineering.

We recommend teaching F# because it is an extraordinary and flexible tool for teaching different areas of Computer Science. The language is rich and its functional nature allows to easily define the appropriate subset for teaching particular concepts. I use it to teach entire classes by typing code and evaluate interactively discussing the results of a single evaluation. It is also a great tool for teaching programming to scientists and engineers: I found that its mathematical roots in lambda calculus are more readily grasped by non-programmers, and interactive evaluation recalls environments such as Matlab and Mathematica very popular in these communities.

I am currently using F# to develop my undergraduate final project. The project consists in developing an Application Programming Interface that allows one to encrypt data using fully homomorphic encryption and I found in F# the ideal programming language to develop it.

Besides all the benefits of the functional paradigm for this type of work, F# interoperability with the .NET platform allows the construction of powerful implementations that other functional languages do not allow so easily.

I really hope that, in the future, I keep working in Cryptography using F# as the main programming language for my projects. I am also preparing a hands-on presentation about F# and Cryptography to be presented at an event in Microsoft Portugal, which I will surely enjoy!

We developed a ClickOnce F# / WPF application that scores and ranks thousands of models of part-supplier combinations using Microsoft Solver Foundation (MSF). Agents can chose from the highest scoring combinations to optimize purchasing decisions. F# proved ideal for the complex data machinations required to build the models from raw Excel input. Also, the MSF supplied F# functional wrapper is a great way of using Solver Foundation from F#.

F# is becoming an increasingly important part of our server side infrastructure that supports our mobile and web-based social games with millions of active users. F# first came to prominence in our technology stack in the implementation of the rules engine for our social slots games which by now serve over 700,000 unique players and 150,000,000 requests per day at peaks of several thousand requests per second. The F# solution offers us an order of magnitude increase in productivity and allows one developer to perform the work that are performed by a team of dedicated developers on an existing Java-based solution, and is critical in supporting our agile approach and bi-weekly release cycles.

The agent-based programming model offered by F#’s MailboxProcessor allows us to build thread-safe components with high-concurrency requirements effortlessly, without using locks and sacrificing maintainability and complexity. These agent-based solutions also offer much improved efficiency and latency whilst running at scale. Indeed our agent-based stateful server for our MMORPG has proved a big success and great cost saver that we’re in the process of rolling it out across all of our social games!