I really loved this article. It is very similar to how I have started using F# in my work. It's nice to know I'm not alone! I have been using private but was considering moving them to sub modules as it didn't feel right. I'll definitely be doing that now!
Do you have any recommendations for handling side-effects? F# coding conventions (docs.microsoft.com/en-us/dotnet/fs...) recommend using classes but I don't really want to go that route as I prefer to show that my code is using FP style. However, initialising a random number generator, for example, is not thread-safe when instantiated statically:
module MyApp.Rand
let random = System.Random()
My thinking is to initialise it at the start of the app and pass it in to any functions that need it, pretty much how to manage any kind of state in FP but I'm still learning this stuff.
If it is something that can be initialized once, I often do it at the start of the program as you mentioned. Basically, the entry point to the program can do whatever it needs (including side effects) to setup the program.
I am currently working on an article for how we are managing side effects interleaved with logical decisions. Here is an extended example that I plan to explain in the article. It is based on the MVU pattern. And in fact, for the front-end we also augment the MVU pattern with a Perform function to run side effects. Example here.
For randomness, I have an old article that addresses how to shuffle without side effects.
I also highly recommend Mark Seemann's blog for articles on functional architecture. Here is a good one, for example.
I really loved this article. It is very similar to how I have started using F# in my work. It's nice to know I'm not alone! I have been using
privatebut was considering moving them to sub modules as it didn't feel right. I'll definitely be doing that now!Do you have any recommendations for handling side-effects? F# coding conventions (docs.microsoft.com/en-us/dotnet/fs...) recommend using classes but I don't really want to go that route as I prefer to show that my code is using FP style. However, initialising a random number generator, for example, is not thread-safe when instantiated statically:
My thinking is to initialise it at the start of the app and pass it in to any functions that need it, pretty much how to manage any kind of state in FP but I'm still learning this stuff.
Thanks again for a great article.
I wrote a followup article for how we are handling side effects on the back-end.
Testable Back-end Programming in F#
Kasey Speakman ・ Apr 8 ・ 11 min read
If it is something that can be initialized once, I often do it at the start of the program as you mentioned. Basically, the entry point to the program can do whatever it needs (including side effects) to setup the program.
I am currently working on an article for how we are managing side effects interleaved with logical decisions. Here is an extended example that I plan to explain in the article. It is based on the MVU pattern. And in fact, for the front-end we also augment the MVU pattern with a Perform function to run side effects. Example here.
For randomness, I have an old article that addresses how to shuffle without side effects.
I also highly recommend Mark Seemann's blog for articles on functional architecture. Here is a good one, for example.
Thank you for this and thanks for those links. I'll definitely check them out.
Love the shuffle idea.