Короче, ладно. Тут вопрос кто как делает. Я человек прагматичный юзаю и ФП и интерфейсики с mutable когда это проще. Платят-то не за чистоту функций, а за результат, который должен быть в том числе простой в реализации.
Чисто функциональная реализации (dot free, monads, side effect free, pure, composition, и куча операторов >> не всегда лучший выбор)
Как и чисто ООП, а то получаются IAbstractServiceManagerSingletonFactory

мне кажется, что тут воинствующих функциональщиков и нет

Для мутабельности в фшарпе есть мейлбоксы

Ну это из разряда - для мутабельности есть рекурсия. Так вопрос тоже можно решить, но иногда чтобы сделать мутабельность, можно просто взять mutable поле :D

тем более какие тормозные асинки в F# на цпу работе - нет спасибо

С мутабельными полями фиг знает. С таким подходом проще на c# писать

Только из-за мутабельных полей переходить на язык без DU и type inference?

тем более она (мутабельность) редко нужна. Но если нужна, хорошо что она есть в F#

Ну я придерживаюсь точки зрения, что для функциональных языков принципы построения кода все же иные

я кажется нашёл одного

Я не воинствующий

Я немного о другом

есть мнение что F# позиционируется в лучшем случае как functional-first, а не purely functional, а на википедии вероятно вообще как мультипарадигменный

Скорее о том, что мутабельность в моей практике возникает тогда, когда пытаешься писать в привычном императивном стиле

Когда же мутабельность заменяешь на термин "состояние", открываются новые возможности

Ну ок. Вот предположим, была у меня задача недавно, сделать сервер, который принимает запрос на некую работу, регистрирует, кладёт её в очередь, отдаёт тут же ссылку на статус работы.
Есть разгребатор очереди который перемолачивает запросы и делает что-то страшное.
Какую структуру данных ты бы выбрал для связи ID запроса и собсно запроса?

Кортеж

Плюс два актора

Ок. как найти по ID запроса его состояние