Odpalanie zapytań SQL w FP ma tyle samo sensu co każda inna monada I/O.
Jeśli tak się dzieje to z miejsca tracę większość atutów jakie mam w FP.
Niekoniecznie. Monada IO może przynosić pewne korzyści.
Reklama ZIO z https://degoes.net/articles/no-effect-tracking (przytaczam, niekoniecznie się utożsamiam, ale ZIO wygląda zacnie jak na monadę IO w Scali)
Why IO?
If effect tracking is commercially useless, then why use IO data types?
If you’re in Haskell, you don’t have a choice: if you want to get useful work done, then you will use some model of interaction with the outside world, and it may as well be IO, which is industry-proven and adopted extensively.
If you’re in Scala, however, you do have a choice: you can write plain vanilla Scala code, and perform side-effects anywhere that you want. Or you can grab one of the functional effect systems like ZIO, and create and compose values that model side-effects instead.
The greatest reason to use a functional effect system like ZIO is that it makes side-effects first-class values. Values are things you can accept and return from functions. You can store them in data structures. You can write your own operators, which accept functional effects, and which transform or combine them in custom ways.
All of these abilities let you make your own control flow structures and factor out kinds of duplication you can’t avoid when you solve problems using side-effecting code (take a look at some of my talks for examples).
ZIO goes beyond providing first-class effects, and delivers additional valuable features, including:
- Highly-scalable fiber-based runtime
- Resource-safety across asynchronous and concurrent effects
- Declarative concurrency without locks and condition variables
- Easy and safe parallelism
- Context propagation and dependency injection
- Execution traces that work across async and concurrent boundaries
- Fiber-dumps that show the runtime graph of your application
- Powerful operators that allow you to snap together solutions to complex problems quickly
- Type-safety and user-friendliness
- Features for making user-land code fully testable
The real reason for using ZIO or other functional effect isn’t effect tracking: it’s everything else!
Ja osobiście mieszam FP z imperatywnym OOP, bo w Scali jest to dość naturalne. Aczkolwiek tej mutowalności i tak nie jest dużo.
- ciężko jest izolować efekty uboczne, ponieważ realizacja zadań wymaga przeplatania odczytów z zapisami, bawienia się z lockami
Czemu wymaga zabaw z lockami? A co jeśli zastosujesz mechanizm aktorów, taki jak np z Akki: https://akka.io/ (albo odpowiednik z ZIO)? Obsługa wiadomości wewnątrz aktora jest robiona jednowątkowo, nawet jeśli aktor dostaje wiadomości z różnych wątków. Z zewnątrz oczywiście można zaobserwować że aktor zmienia stan (gdyby nie zmieniał to byłby bezużyteczny), ale to samo dotyczy np. systemu plików, baz danych, zdalnych połączeń, itd