Thanks, Cool and very entertaining talk.

Superb

very good talk

I read most of Simon's functional programming book, it is very good reading. I do not do too much FP in everyday programming, but I enjoy to learn about it. For example about Memoize, Currying, Monads, Discriminated Unions - I have (for fun) written several blog posts with C# code, mostly based upon his book. It would be very nice if and when C# gets discriminated unions, it would give be (IMHO - far) a better FP support in C#.

I wish they'd made records in C# actually read-only, but as long as I can do public setter and the type is sent through a method, it can be modified, completely against the "immutable by default" idea presented before it was released 😢

"worth absolutely any tradeoff... within reason"

Hmm... someone said Language Ext is not supported (can an open source project be considsered supported) any more. I just checked and the last commit to main was Aug 10, 2025. So, that seems pretty recent.

Given the topic, I would have loved to see mention of a functional language that targets the CLR and is shipped with Visual Studio - F#. The idea is not to switch anyone over but to give them a taste for why one might be interested in functionally programming in C#.

Why not making the unions with abstract record instead of with interface.

Was the QR code only good during the conference?

Do you have any idea how many fsharp guys would drop their csharp jobs in 2 seconds flat to go program in the language they love? I can't even begin to understand what anyone means by there not being a talent pool. We exist. We're passionate and the community is full of brilliant engineers who would saw their leg off for a chance to be happier. Lol.

28:58 "Now these are fairly simple bits of logic, ya know, 'cause I made this up"

for anyone else who is as braindead as me and for some reason wants to code review, for whatever reason, then yes! the correctly refactored code is indeed something like this:

var oldCrew = (isTuesday && !isEvenYear) || (!isTuesday && isEvenYear);

Time to decompose as this is looking complicated!

I'll see myself out...

Update from a couple of days ago, we are getting union types in C# 15 hopefully. Dotnet 10 may have a preview for it, dotnet 11 will probably be paired with the C# version that has them. We will love.

Just use F Hash

I like the talk, but sometimes it does feel more like "this is fact, accept it" than "this is what I want to tell you, here is an easily grokkable example" which makes it harder to "believe", especially in the first third

Regarding the question at 1:06:00, personally find the language F# a bit... conflicting in its design. It tries to be a lot like other functional languages, but it just is not there yet. It is missing so many small things that would make it better. I have been doing F# as a hobby for half a year now and was taught F# in university for over 3 months. That language just has to many conflicting bits that do not work well for large scale code bases. Private is not private, it is file scoped private. You can not declare a record inline for a discriminated union constructor case. The compiler that F# uses does not allow for cross-referencing types. This will cause you to either having to write abstractions for the sake of having them, or having to work with object ID's and object stores all of the time, which introduces state into a functional pipeline and there are only 500 million opinions on how to deal with state in FP (it gets messy fast. No it does not look good, FP does not work well with statefull things it becomes ugly and it shows it wasn't designed for it. Use OOP for composition of anything with state, FP for composing logic). F# just does not have the features that I as a software engineer need. Yes I will have cross referencing types and they are not a bad thing. Yes I will want my unions to be able to have inline data structure declarations. Why can I not have a sum type with named positionals??? Why does working with abstraction become such a pain so quickly in F#? I do truly not care if what I have said goes against what FP stands for. I know it doesn't, I have worked with it. And I as an engineer just need certain tools available to me that F# just simply either doesn't provide or blocks from existing entirely. F# is a well designed and very minimalistic language, but it just does not hit the sweet spot. OCaml did a better job at a lot of things and that is saying something. ML-based languages have many variations between them. F# just didn't learn from them.

I personally like Idris and Haskell a lot. Haskell a bit less so, types as a first class construct is not for everyone I suppose. F# just simply lacks to much for me to pick it as the right tool for any job. It forces you to structure your programs in a way that may not even work well for it (no cross-referencing of files, yes that is a problem and yes that is a normal thing to do. Fight me over it for all I care, it is a philosophical problem in how we model and think of definitions with nominal existence, and a language should not force something like that). Love it, hate it, if I want full functional support the best language still does not exist. Elixer is very good. I have worked with it and I like it a lot. It is not strictly functional but it is very modern in how it does things, look it up. Scala is also very nice and very well supported all-round. Haskell and Idris are two very nice languages but they have a very steep curve to them and are not for every mere mortal. I personally use C# or Kotlin. Kotlin is basically Swift and C# if they fell in love but could not get rid of the freaking java garbage (reified and inline do not exist and they can not hurt you. In kotlin they do, and I find them trash).

I am in a field where I can vibe code nearly everything. To bother about functional or non functional design etc. is so strange for me. It is simply abstracted away.

He lost me at his declaration of love for Dr Who. If he loves Dr Who, then functional programming must suck. Who wants to write in a slow, sucky paradigm.