Those who develop with .NET probably do so with C#. But F#, in particular, has great potential to make daily work easier. Everything that C# can do can also be done with F#, and often in a more lightweight and less error-prone way. If you want to see where the differences are and why F# is a good programming language for normal software development, come to this session! And don't worry, the talk is free of functional programming jargon – I promise!

Despite being 10 times slower than most compiled languages, Python is still one of the top 3 popular languages in the world. Python is easy to use, and the low friction makes Python a popular choice for new developers. Python is also the de-facto language for data science with the SciPy stack consisting of libraries such as Pandas, NumPy, SciPy, Matplotlib, and Jupyter.

F# and Python look similar in many ways. Both languages use indentation instead of braces and semicolons. However, type annotations in Python sometimes make the language ugly and unreadable, and static type checkers like Mypy and Pyright break your codebase with every new release. F# with its superior type system and type inference, combined with pipelining, pattern matching, computational expressions, makes F# a better Python.

Interop with Python could open up yet a new world of new possibilities for F# developers. This talk will dive into the details of how Fable compiles F# to Python, and also how we can interop with the existing Python ecosystem. We will go through the current status, and what remains to be done.

I will use Rollup Risk to demonstrate how productive it is possible to be in F#, building real world apps, as a tiny team or even a team of one.

The application was built by one person (me!) in around 5 months, is running with real customers, and continues to evolve (in fact a major new feature is about to land).

We'll go through the big picture architecture, application and cloud, and take a look at some of the code, tools, and patterns used along the way with some of the key decisions (good and bad) made along the way.

Hedy is a gradual programming language to make learning programming easier. The core idea of Hedy is that it uses different language levels. In level 1, there is hardly any syntax at all, for example printing is done with:

print hello F# eXchange

In every level, new syntax and concepts are added, until kids are doing a subset of Python in level 22 with conditions, loops, variables and lists. The leveled approach means that learners do not have to learn all syntax rules at once. Hedy is aimed at children that want to get started with textual programming languages, but for whom starting with Python might still be too complex.

Hedy is open source, runs in the browser, is free to use, and available in fifteen different languages (Including English, Spanish, Chinese and Hindi). Hedy was launched in early 2020 and since then almost 1.5 million Hedy programs have been created by children worldwide. Try Hedy at www.hedycode.com.

In this talk, Felienne will dive into the pedagogy behind Hedy, but also expand on the technical aspects of Hedy. For example, a set of increasingly complex grammars, rather than one grammar, poses new challenges for language design.

In this talk, we will talk about GraphQL, what it is and why it is a great alternative to the traditional REST approach. Then I will present a tool called Snowflaqe which allows F# applications to communicate with any GraphQL web service.

Snowflaqe implements a type-safe functional approach to data access with GraphQL. It does so by taking GraphQL queries, type checking them and generating idiomatic F# code which sends the queries and handles the data transport.

I will demonstrate multiple practical real-world applications starting with generating Excel reports from GraphQL data, to building our own Excel functions in F# which generate reactive Excel tables from the GraphQL data (featuring ExcelDNA)

The "Why" of this talk:

Having worked with GraphQL for the past couple of years, I believe GraphQL to be a very powerful technology. However, in the F# community it is rarely talked about and it is heavily underused. Many moderns platforms today expose their data using GraphQL and so I built Snowflaqe to make it easier for F# developers to consumer and integrate with these platforms.

Microservice Architecture and the reasons why you should move to it, and the reasons you shouldn't, have been well discussed. If you have already decided to move over to microservices from monolithic development, then you may be finding the whole process a bit daunting. What aspects should you, a developer be concerned with? What does all the terminology mean? How do the services talk to each other? In this session, I will show you how to get started with microservices architecture, answering these questions and many more. We'll look at The Tanzu Tacos project, built with ASP.NET 5, and explore how the whole process fits together from a development point of view. Hopefully, you'll leave the session with the confidence to start your own microservices application development straight away!

Sitelets can model anything that has to do with the server side: from microservices and backends of client-server applications to statically generated websites. Using just a few sitelet combinators and some clever custom web controls, you can also build a full content management system (CMS) for your sitelet pages in just a couple hundred lines of F# code.

In this talk, I will go over some of the sitelet fundamentals, build the necessary web controls and their datastore, utilize external HTML templates instead of in-code HTML construction, and abstract the entire CMS capability as a single generic sitelet combinator. At the end, you can add a complete CMS subsystem to any sitelet you choose with not much more than a single function call. Not only that, but you can also embed the resulting CMS-enhanced pages in your Giraffe or Saturn applications, and enjoy the best of breed of F# web stacks.

Even though the F# community does an outstanding job at pointing out how awesome the language is, I have the feeling that many people in the broader "programming community" still don't know or consider F#. Customers don't know F#. At least not the ones I have spoken to the past three years. Time after time. I've had to explain what F# is, why we're using it, and why it's the best choice for their project. I figured that F# can use some extra experience reports and success stories.

Almost all of my coworkers learned F# from scratch. I learned F# from scratch. At some point, we hired someone who had never programmed before and taught him F#. All while delivering projects to customers. It was a lot of fun and we've had a lot of success. Needless to say, we also made a lot of mistakes. These mistakes make up interesting stories, experiences, and lessons learned.

My team works on several F# web services deployed on kubernetes with a PostgreSQL backend. In this talk I'll be sharing some of the methods we use to keep database operations automatic and smooth.

This talk is an interactive talk, including F# builds, docker builds and kubernetes deployments.

Code from the talk is built on the SAFE stack bookstore example, and is publicly available on a github fork.

The talk covers: * Connecting to a PostgreSQL database from the SAFE stack * Running database migrations on kubernetes automatically during rolling upgrades * Writing an F# console app used by a kubernetes cron jobs to clean up old database data

As well as (less F# related): * Building docker images (with F# code in them) * Running applications on kubernetes * Running a PostgreSQL database on kubernetes

The project started with my professor and I trying to build a database from web-scraping a website, mootleyfool.com. In this website, one can find all sorts of company specific related news, including various quarterly earnings calls transcripts. Our objective was then to scrape as many transcripts as we could from the website and form our database.

We were able to achieve this with ease using F# and I would love to share this experience. I used to web scrape using other languages like python but using F# for this task was surprisingly simple and effective. In the end, we were able to scrape close to 20,000 earning transcripts or approximately 1gb worth of text data. It is worth mentioning that F# asynchronous methods drastically improved the speed of which the transcripts were parsed.

Now that we had our dataset, we proceeded to explore it using standard NLP classification algorithms like naïve bayes. To guide us in this journey, we used Mathias Brandewinder’s F# textbook: Machine Learning projects for .NET developers.

https://aexsalomao.github.io/ConferenceCalls/TranscriptParsing

2021 has been a year of many programming languages for me. I initially wanted to explore one language a month to experience how they make me think. That came to a halt after I spent a weekend with F#.

By the time October arrives, I will have surpassed 100 days with F#. Though it is not a language I use at work, there wasn't a day I missed doing any F#. This talk will be a tour of the whys, hows and whats of my experience. Why did I decide to commit to F#? How did I learn? What did (or will) I make?

I would in particular focus on how F# influenced the way I think about solving problems and which of its features were challenging. I never worked with .NET nor did I have experience in a functional language that is statically typed — I hope this motivates folks in that same boat. There'll be code snippets, illustrations and screenshots. All in 10 minutes.

Software development is an asymptotic process. What developers often overlook is that the life expectation of lines of code exceeds the average duration of a developer's stay in the project or team. More often that not it's other programmers who will have to maintain our code, so we should strive to get a clear and consistent representation of our domain in code early, even though it will be continuously revised and improved.

This talk is about how we describe in F# the domain of media content distribution and why we believe F# is an excellent language for efficient collaboration in dynamic teams.

Uno is the only cross-platform framework that allows you to build pixel-perfect UIs and connect app implementations in a truly cross-device experience.

But what about F#? Uno is UWP and UWP does not support F#...

Until now.

WinUI 3 works with F# on .NET 5. And current UWP implementation can reference an F# library.

So how can I create an Uno app with F#? It's easy and my company prepared an enterprise-grade dotnet new template to get started.

This talk covers:

1. Brief Uno Platform introduction: what is, which platforms supports, design in Blend, limitations
2. What is Elmish.Uno: port of Elmish.WPF, enhancements, NuGet package, template
3. How to get started with Elmish.Uno: template name, samples
4. What's included in the template: template structure, built-in Elmish programs, propagating messages straight to the root program
5. How to structure your Elmish.Uno: one root program per app, multiple root programs, XAML visual states and model states, subscribe to UI event in Elmish program

WebSharper.Forms is a powerful form abstraction library to build concise web forms that integrate directly into WebSharper applications. In this session, I will demonstrate how these reactive forms can be combined, what advantages they bring, and how they can be embedded into HTML and client-server applications. I will also show how to enlist external form validation libraries using WebSharper Interface Generator (WIG), an F# eDSL that generates type-safe bindings to JavaScript code, with validation rules coming from both the client and backend side.

As functional .NET developers, we must avoid using exceptions at all costs and apply Result type everywhere instead, right? What if I told you there could be a better way of error handling without all the tiresome up-n-down mappings while keeping the benefits of both worlds?

Get ready for heretic talk attempting to destroy some of F# error handling dogmas, presenting different approaches used on previous projects with all the benefits and pitfalls, and maybe... offering a multiparadigm approach for a multiparadigm language.

In this talk, I'd like to share the vision of where Fantomas is going. The project had a rough start and has slowly become more stable over the years to the point where it can be used in every developer's daily workflow. Well, not entirely... one small team of indomitable devs still holds out against the formatter. Not because of willingness, no because of a terribly complex codebase. Yes, I'm talking about the F# compiler itself. I'd like to highlight what challenges lie ahead in formatting the compiler.

At the beginning of the talk, I illustrate how you can set up Fantomas in a project and I explain why you would do it in the first place. This first part is pretty universal for the entire F# community. However, when trying it out for the compiler, some roadblocks pop up. These will be addressed in the next major version and I want people to get excited about this.

The talk would be a great opportunity for the maintainers to share some perspective with end-users.

We started as a team of three in August 2019 building a greenfield product for a new start-up, supplying GPS data 24/7/365 for a new cloud-hosted efficient, fast, and accurate ETA calculator for trucks delivering goods across Europe. We wanted to use a functional programming language and after careful consideration, we chose F# and .NET Core. Today, we have grown to a team of eight, are offered as a product in our own right, and are processing nearly 8 million GPS signals per day.

In this session, you will discover why we adopted F#'s functional-first philosophy and the positive impact that decision has had on product development and the lives of our team. We will look at the language features that enable us to confidently connect to over 250 different sources of data with relative ease and minimise production issues. If you want to see why F# is such a great choice for building scalable Web APIs and services, then this is a session that you need to see!

F# is a functional programming language that allows for quick development of real life production ready applications. What sets it apart from other programming languages is a combination of factors that allows it to run everywhere, on every platform, server side and client side, and the ability to interact with any dotnet library. The interoperability with the enormous amount of C# libraries is great. But it can also leverage a vast amount of javascript libraries, thanks to Fable. Therefore, even a complete amateur can make amazing applications due to the fact that indeed “when it compiles, it runs” and the ease of being able to refactor code without running into mysterious and intractable errors.f

If not everywhere, certainly in Brazil, it is hard to employ functional programming languages on a enterprise use case. Customers often prefer solutions they already know — especially on consultancy jobs.

This is the story of what happened when a customer gave us full autonomy on tech choices — giving us the chance to build an application from the ground up, with whatever tools we found best — and for us, that meant full stack F#.

We've been enthusiastic about the idea for years, and we all had toy projects w/ F#, but putting up a production server required us to solve many problems. Data sensitivity, concurrency control, massive machine learning jobs — we've done it before, but this time we did it with F#.

This talk compares the developer experience with and without strongly typed functional programming. This is a talk of the courage it takes to make the choices we made, and the pay off.

This talk details the experience of using F# for DL and data science (DS) on a daily basis in two large corporations and compares F# with Python for DL/DS

With respect to DS/DL, there are two issues of concern with Python: (A) models are becoming tightly integrated with the front-end language (e.g. Python and PyTorch). This makes its harder to consume some recent models from other languages / ecosystems. And (B) today's data pipelines, can become large and complex resulting in large code bases surrounding the actual DL model(s). Python's lack of static typing and slowness is a major impediment.

F# is expressive, statically type-checked and much faster than basic Python at data handling. Combine that with tooling that supports interactive programming well an F# is ideally suited DS/DL for the .Net ecosystem.

The F# language encourages you to precisely model your domain, create succinct DSLs and write code functionally using immutable data structures. When used to build large-scale real-world systems, this produces simple code that is easy to reason about, while being joyous and productive to create.

Within the confines of an F# system, one that is fully within our control, these patterns are naturally predominant. However, the real-world is messy, and any useful system needs to go beyond its boundaries and interact with outside systems such as web servers, database servers, distributed application orchestration frameworks and message brokers. Such interactions, while empowered by the powerful .NET ecosystem, can be jarring to an F# developer, as they do not speak the same patterns that we become accustomed to.

We will explore some approaches in abstracting away these "impure" systems, in such a way so it feels natural to interact with them using F#. These are presented using a few real-world examples:

1. F# and Databases: persisting and evolving rich domain models using relational databases, without converting to laborious SQL
2. F# and Actors: creating distributed applications of massive scale and zero single points of failures using an actor framework such as Orleans
3. F# on the web: creating seamless client/server web and mobile applications without thinking of APIs

The take-away from this session would be to encourage thinking in terms of creating F#-friendly DSLs on top of impure systems, such that application developers can focus more on actually representing business logic and workflows, as opposed to obsessing over mundane details such as persistence, scaling and APIs.