🤣🤣🤣 Oh no, I need a new release soon. 😂😂

SqlBulkTools.FSharp v1.0.0 is released! #fsharp github.com/JordanMarr/SqlBul…

FSharp.SystemComandLine v2.0.0-beta7 is released! This adapts to API changes in the new System.CommandLine v2.0.0-beta7. #fsharp github.com/JordanMarr/FSharp…

Find a little time to update at least my bluntly "stolen" and opinionated Template for #fsharp #fable apps with an azure functions backend. #Feliz #DaisyUI #AzureFunctions #Vite nuget.org/packages/Hits.Web.…

We’ve been watching the conversation unfold in recent PRs on the .NET runtime repo, which Copilot was tasked to resolve and it says a lot about where we are with AI in software right now... 👇 buff.ly/TjDHhje

Yet another article about error handling in #fsharp medium.com/@lanayx/practical…

Learn how to run an #fsharp app in a Docker container with @sirhamy #dotnet buff.ly/lweyrIs

Big v3.0 release of SqlHydra today! #fsharp github.com/JordanMarr/SqlHyd…

Look over what I stumbled upon :D #fsharp

Anders Hejlsberg has an F# book behind.

This is one of the wildest git diffs I've ever seen

And now take a look at this beautiful idiomatic #fsharp code to balance parentheses. - It uses an immutable list of F# ('T list), which is persistent and functionally handled, there is no explicit mutability; each "push" creates a new list (although the compiler optimizes this with tail recursion) - Uses pattern matching and operators such as ::, which are central in F# and reflect a pure functional style - The state of the stack is passed as a parameter in each recursive call (stack), maintaining immutability and only depends on the native F# lists, without the need to define an additional class

Demystifying the Enigma Machine - a Functional Journey by @isaac_abraham Register for free and read more at: meetup.com/func-prog-sweden/… Kind regards @KivraHq for the venue. And you can join from anywhere as we are live streaming. #funcprogsweden #functionalprogramming #fsharp

In this week's blog post, Joost learns more about the feature range of #fable while trying to format some dates! #dotnet #fsharp #webdev buff.ly/4b5VEkd

Hey #fsharp, short question: I saw in some code, that there is a package for "phantom types". I think they use unit of measure as an alternative for classic fsharp value types. I also saw some code, where it was used. But I forgot what package it was. Can someone gibe me a hint?

FP languages have bad tooling... compared to what, exactly? - C . A horribly chaotic ecosystem. No standard package manager. Good luck with installing a compiler and libraries. Each IDEs is titanic: huge, slow, easy to break. - JavaScript. Enjoy dealing with incompatible non-portable code that requires an army of transpilers. Also: ES6, Babel, Webpack. Cool buzzwords until you realize you have to configure your toolchain just to get "Hello, World!". Oh, and then there is Node.js. The only language that has good tooling... doesn't exist. Every language is its own masochistic philosophy. Some just hide it better than others.

Presenting "F# by Example", a fork of Go by Example but for F# - a new reference source for those who are both new and experienced with the language. fsharp-by-example.com #fsharp @fsharponline

Watch out you might just starting enjoying F# more.

#csharp devs, can't wait for type unions? Consider trying #fsharp's discriminated unions, we love them! @fsharponline #dotnet buff.ly/42KmBYi

Just finished reading "Functional Design and Architecture" by @graninas. As promised, my book review. TL;DR It's a good book. But it's not for everyone. First of all, the target audience is crucial for the book. If you're an author, it's important to understand your audience. If you're a reader, it's important to know whether you're in the target audience to benefit from reading. I had the impression that this book's target audience consists of Software Engineers who know FP and even Haskell but are not satisfied with popular design approaches and want to get inspiration from mainstream practices. I don't think there is a huge number of such people; Haskellers are usually inward-looking. But if you're one of them, you're quite open-minded, and you'll benefit from this book a lot. Another challenge of this book: I feel like it covers diverse topics. I can imagine at least several books written in detail about themes mentioned in this book: 1. Making diagrams for sharing your thought process and architecture 2. A Haskell tutorial 3. A Free Monad tutorial 4. A DDD tutorial 5. Comparison of FP approaches 6. Testing in the FP world 7. Concurrency tutorial 8. Importance of the Systems Design 9. Hierarchical Free Monads and FDD This is a good thing! It means that value for money is great, and you can learn about many topics from one book. But at the same time, this book can't afford to cover every single topic in detail. You have to have some knowledge about them and be on board with the main ideas to understand their value. The author respects the reader. There's little jargon. There's no gatekeeping. Trivial things are not explained. Yet complex things are elaborated. While food for thought is left to the reader. This book is like a text RPG quest: you're given directions to complete your task but you have to do the rest of the work on your own. I liked the first example about designing the scripting language for a spaceship system. It's not a boring example, and you can easily see how real-life software can get complicated. Even this highly simplified demo example in the book is already quite difficult to implement. I especially liked the part about Software Transactional Memory (STM). The book did a great job explaining how systems can instantly skyrocket in complexity once you add a tiny requirement e.g. logging inside a transaction. Alexander presents the approach with Hierarchical Free Monads. But you can clearly see that the author is not trying to push this approach for every single use case. There's a comparison between Handle, ReaderT, Final Tagless and Free Monadic patterns and the Free Monad's one is not the best choice for the task in question. My verdict: if you really want to level up your systems design skills and learn some FP approaches, it's a good book to read. But please, read a Haskell tutorial first. ----- As a side note, reading this book made me reflect on the complexity of modern software. While reading, I kept thinking "Is this complexity really justified? Is FP really good?" For context, just to implement a Web Backend framework based on Free Monads, I noticed that the following Haskell features were used: Algebraic Data Types Typeclasses Monads Higher-Order Functions Higher-Kinded Types MultiParamTypeClasses GADTs FunctionalDependencies TypeApplications AllowAmbigousTypes TypeFamilies Rank2Types I know all these features. And their usage makes sense. But I tried putting myself into the shoes of the person who doesn't know anything about FP. And in those shoes, it's really hard to see whether learning these 10 FP features is superior to learning 10 OOP patterns. No matter what you think, software can be really complex. This book demonstrates this well. And if language features or design patterns can really help with simplifying them, why not use them? But the learning journey takes a while. You can't become an expert instantly.