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.

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.

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.

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

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.

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

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!

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.

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.

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!

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.

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.

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!

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

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.

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