ZIO & Cats Effect: एक सफल गठबंधन

कैट्स इफ़ेक्ट स्कैला-दुनिया के लिए एक प्रकार का "रिएक्टिव स्ट्रीम" बन गया है, जिससे आप पुस्तकालयों के संपूर्ण विविध पारिस्थितिकी तंत्र को एक साथ जोड़ सकते हैं।

कई उत्कृष्ट पुस्तकालय: http4s, fs2, doobie - केवल कैट्स इफेक्ट से टाइप कक्षाओं के आधार पर लागू किए जाते हैं। और ZIO और Monix जैसी लाइब्रेरी, बदले में, अपने प्रभाव प्रकारों के लिए इन प्रकार की कक्षाओं के उदाहरण प्रदान करती हैं। संस्करण 3.0 में तय की जाने वाली कुछ समस्याओं के बावजूद, कैट्स इफेक्ट स्काला भाषा के संपूर्ण कार्यात्मक पारिस्थितिकी तंत्र को व्यवस्थित रूप से समर्थन करने के लिए कई खुले स्रोत योगदानकर्ताओं की मदद करता है। बिल्लियों के प्रभाव का उपयोग करने वाले डेवलपर्स को एक मुश्किल विकल्प का सामना करना पड़ता है: जो अपने अनुप्रयोगों के लिए उपयोग करने के लिए प्रभावों का कार्यान्वयन करता है।

आज तीन विकल्प हैं:

• बिल्लियों IO, संदर्भ कार्यान्वयन;
• मोनिक्स, टास्क डेटा प्रकार और कोड में इसकी प्रतिक्रियाशीलता;
• ZIO, ZIO डेटा टाइप और इसका क्रॉस-थ्रेडिंग स्कोप।

इस पोस्ट में मैं आपको यह साबित करने की कोशिश करूंगा कि कैट्स इफेक्ट का उपयोग करके अपने एप्लिकेशन को बनाने के लिए, ZIO डिजाइन समाधान और क्षमताओं के साथ एक अच्छा विकल्प है जो कि कैट्स IO में संदर्भ कार्यान्वयन से काफी अलग हैं।

1. बेहतर एमटीएल / टैगलेस-फाइनल आर्किटेक्चर

एमटीएल (मोनाड ट्रांसफ़ॉर्मर्स लाइब्रेरी) एक प्रोग्रामिंग शैली है जिसमें फ़ंक्शन उनके प्रकार के प्रभाव से बहुरूपी होते हैं और "प्रकार वर्ग की कमी" के माध्यम से अपनी आवश्यकताओं को व्यक्त करते हैं। स्काला में, इसे अक्सर टैगलेस-अंतिम शैली कहा जाता है (हालांकि यह एक ही बात नहीं है), खासकर जब प्रकार वर्ग में कोई कानून नहीं है।

यह सर्वविदित है कि ऐसे क्लासिक एमटीएल प्रकार वर्गों के लिए एक वैश्विक उदाहरण को परिभाषित करना असंभव है जैसे कि राइटर और स्टेट, साथ ही कैट्स आईओ जैसे प्रभाव प्रकारों के लिए। समस्या यह है कि इन प्रकार के प्रभावों के लिए इन प्रकार के वर्गों के उदाहरणों को एक उत्परिवर्ती राज्य तक पहुंच की आवश्यकता होती है, जो विश्व स्तर पर नहीं बनाया जा सकता है, क्योंकि एक उत्परिवर्ती राज्य का निर्माण भी एक प्रभाव है।

सर्वश्रेष्ठ प्रदर्शन के लिए, हालांकि, "मोनड ट्रांसफार्मर" से बचना और मुख्य प्रभाव प्रकार के शीर्ष पर सीधे लिखना और राज्य कार्यान्वयन प्रदान करना महत्वपूर्ण है।

इसे प्राप्त करने के लिए, स्काला प्रोग्रामर एक चाल का उपयोग करते हैं: वे अपने कार्यक्रमों के शीर्ष स्तर पर प्रभाव के साथ (लेकिन साफ) उदाहरण बनाते हैं और फिर कार्यक्रम में उन्हें स्थानीय निहितार्थ के रूप में प्रदान करते हैं:

Ref.make[AppState](initialAppState).flatMap(ref => implicit val monadState = new MonadState[Task, AppState] { def get: Task[AppState] = ref.get def set(s: AppState): Task[Unit] = ref.set(s).unit } myProgram ) 

इस तथ्य के बावजूद कि इस तरह की चाल उपयोगी है, यह अभी भी एक "बैसाखी" है। एक आदर्श दुनिया में, प्रकार वर्गों के सभी उदाहरण सुसंगत हो सकते हैं (प्रति प्रकार एक उदाहरण), और स्थानीय रूप से निर्मित नहीं किया जा सकता है, प्रभाव पैदा कर सकता है, फिर बाद के तरीकों से उपयोग के लिए खुद को अंतर्निहित मूल्यों में लपेट सकता है।

MTL / टैगलेस-फ़ाइनल की एक बड़ी विशेषता यह है कि आप ZIO पर्यावरण का उपयोग करके सीधे ZIO डेटा प्रकार के शीर्ष पर अधिकांश उदाहरणों को परिभाषित कर सकते हैं।

ZIO डेटा प्रकार के लिए एक वैश्विक MonadState परिभाषा बनाने का एक तरीका यहां दिया गया है:

 trait State[S] { def state: Ref[S] } implicit def ZIOMonadState[S, R <: State[S], E]: MonadState[ZIO[R, E, ?], S] = new MonadState[ZIO[R, E, ?], S] { def get: ZIO[R, E, S] = ZIO.accessM(_.state.get) def set(s: S): ZIO[R, E, Unit] = ZIO.accessM(_.state.set(s).unit) } 

एक उदाहरण अब वैश्विक रूप से किसी भी वातावरण के लिए परिभाषित किया जाता है जो कम से कम State[S] समर्थन करता है।

इसी तरह FunctorListen , अन्यथा MonadWriter रूप में जाना जाता है:

 trait Writer[W] { def writer: Ref[W] } implicit def ZIOFunctorListen[W: Semigroup, R <: Writer[W], E]: FunctorListen[ZIO[R, E, ?], W] = new FunctorListen[ZIO[R, E, ?], W] { def listen[A](fa: ZIO[R, E, A]): ZIO[R, E, (A, W)] = ZIO.accessM(_.state.get.flatMap(w => fa.map(a => a -> w))) def tell(w: W): ZIO[R, E, W] = ZIO.accessM(_.state.update(_ |+| w).unit) } 

और हां, हम MonadError लिए भी ऐसा ही कर सकते हैं:

 implicit def ZIOMonadError[R, E]: MonadError[ZIO[R, E, ?], E] = new MonadError[ZIO[R, E, ?], E]{ def handleErrorWith[A](fa: ZIO[R, E, A])(f: E => ZIO[R, E, A]): ZIO[R, E, A] = fa catchAll f def raiseError[A](e: E): ZIO[R, E, A] = ZIO.fail(e) } 

यह तकनीक अन्य प्रकार की कक्षाओं में आसानी से लागू होती है, जिसमें टैगलेस-अंतिम प्रकार की कक्षाएं शामिल हैं, जिनमें से उदाहरणों में उत्पन्न होने वाले प्रभाव (परिवर्तन, कॉन्फ़िगरेशन), परीक्षण कार्य जो प्रभाव उत्पन्न करते हैं (टैग रहित-अंतिम के साथ पर्यावरण प्रभाव का संयोजन), या पर्यावरण से आसानी से सुलभ कुछ भी हो सकता है। ।

कोई और अधिक धीमी गति से विवर्तनिक परिवर्तन! कक्षा के उदाहरणों को स्थानीय निहितार्थों से जोड़ते समय प्रभाव बनाने के लिए "नहीं" कहें। कोई और अधिक बैसाखी की जरूरत है। शुद्ध कार्यात्मक प्रोग्रामिंग में प्रत्यक्ष विसर्जन।

2. मात्र नश्वर के लिए संसाधनों की बचत

ZIO की पहली विशेषताओं में से एक इंटरट्रक्शन थी - किसी भी निष्पादन योग्य प्रभाव को तुरंत बाधित करने के लिए ZIO रनटाइम की क्षमता और सभी संसाधनों को मुक्त करने की गारंटी। इस सुविधा के एक क्रूड कार्यान्वयन ने कैट्स आईओ को प्रभावित किया।

हास्केल ने इस तरह की कार्यक्षमता को एसिंक्स अपवाद कहा है, जो आपको विलंबता, कुशल समानांतर और प्रतिस्पर्धी संचालन, और विश्व स्तर पर अनुपालन बनाने और कुशलतापूर्वक उपयोग करने की अनुमति देता है। इस तरह के व्यवधान न केवल महान लाभ लाते हैं, बल्कि संसाधनों तक सुरक्षित पहुंच का समर्थन करने के क्षेत्र में जटिल कार्य भी करते हैं।

प्रोग्रामर को सरल विश्लेषण के माध्यम से कार्यक्रमों में त्रुटियों को ट्रैक करने के लिए उपयोग किया जाता है। यह ZIO के साथ भी किया जा सकता है, जो त्रुटियों का पता लगाने में मदद करने के लिए एक प्रकार की प्रणाली का उपयोग करता है। लेकिन रुकावट कुछ और है। कई अन्य प्रभावों से निर्मित एक प्रभाव किसी भी सीमा पर बाधित हो सकता है।

निम्नलिखित प्रभाव पर विचार करें:

 for { handle <- openFile(file) data <- readFile(handle) _ <- closeFile(handle) } yield data 

अधिकांश डेवलपर्स इस परिदृश्य पर आश्चर्यचकित नहीं होंगे: readFile क्रैश होने पर closeFile को निष्पादित नहीं किया जाएगा। सौभाग्य से, प्रभाव प्रणाली में एक ensuring (कैट्स इफेक्ट में guarantee ) है जो आपको अंतिम हैंडलर को अंतिम प्रभाव के समान जोड़ने की अनुमति देती है।

तो, ऊपर दिए गए कोड की मुख्य समस्या को आसानी से हल किया जा सकता है:

 for { handle <- openFile(file) data <- readFile(handle).ensuring(closeFile(handle)) } yield () 

अब यह प्रभाव "गिरावट प्रतिरोधी" हो गया है, इस अर्थ में कि यदि readFile टूट जाता है, तो फ़ाइल अभी भी बंद हो जाएगी। और अगर readFile सफल होता है, तो फ़ाइल भी बंद हो जाएगी। सभी मामलों में, फ़ाइल बंद हो जाएगी।

लेकिन फिर भी बिल्कुल नहीं। रुकावट का मतलब है कि प्रभाव को हर जगह बाधित किया जा सकता है, यहां तक ​​कि readFile और readFile बीच भी। यदि ऐसा होता है, तो खुली फ़ाइल बंद नहीं होगी और संसाधन रिसाव होगा।

संसाधन प्राप्त करने और जारी करने का पैटर्न इतना व्यापक है कि ZIO ने एक ब्रैकेट ऑपरेटर पेश किया, जो कि कैट्स इफेक्ट 1.0 में भी दिखाई दिया। ब्रैकेट स्टेटमेंट रुकावटों से बचाता है: यदि संसाधन सफलतापूर्वक प्राप्त होता है, तो संसाधन के उपयोग से प्रभाव बाधित होने पर भी रिलीज़ होगा। इसके अलावा, न तो रसीद और न ही संसाधन की रिहाई को बाधित किया जा सकता है, इस प्रकार संसाधन सुरक्षा की गारंटी प्रदान करता है।

ब्रैकेट का उपयोग करके, ऊपर दिया गया उदाहरण इस तरह दिखेगा:

 openFile(file).bracket(closeFile(_))(readFile(_)) 

दुर्भाग्य से, ब्रैकेट केवल एक (काफी सामान्य) संसाधन खपत पैटर्न को एनकैप्सुलेट करता है। कई अन्य हैं, विशेष रूप से प्रतिस्पर्धी डेटा संरचनाओं के साथ, जिसके लिए इंटरप्ट के लिए सुलभ होना चाहिए, अन्यथा लीक संभव है।

सामान्य तौर पर, सभी व्यवधान कार्य दो मुख्य चीजों के लिए आते हैं:

• कुछ क्षेत्रों में रुकावट को रोका जा सकता है;
• उन क्षेत्रों में रुकावट की अनुमति दें जो जम सकते हैं।

ZIO में दोनों को लागू करने की क्षमता है। उदाहरण के लिए, हम निम्न-स्तरीय ZIO सार का उपयोग करके ब्रैकेट का अपना संस्करण विकसित कर सकते हैं:

 ZIO.uninterruptible { for { a <- acquire exit <- ZIO.interruptible(use(a)) .run.flatMap(exit => release(a, exit) .const(exit)) b <- ZIO.done(exit) } yield b } 

इस कोड में, use(a) एकमात्र हिस्सा है जिसे बाधित किया जा सकता है। आसपास का कोड किसी भी मामले में release निष्पादन की गारंटी देता है।

किसी भी समय, आप देख सकते हैं कि क्या रुकावटों का अवसर है। इसके लिए, केवल दो आदिम संचालन की आवश्यकता होती है (शेष सभी उनसे प्राप्त होते हैं)।

यह संरचना पूर्ण-पूर्ण इंटरप्ट मॉडल आपको न केवल एक सरल ब्रैकेट कार्यान्वयन को कार्यान्वित करने की अनुमति देता है, बल्कि संसाधन प्रबंधन में अन्य परिदृश्यों को भी लागू करता है, जिसमें इंटरप्ट के फायदे और नुकसान के बीच एक संतुलन पाया जाता है।

कैट्स आईओ इंटरप्ट को नियंत्रित करने के लिए केवल एक ऑपरेशन प्रदान करता है: अचेतन कॉम्बिनेटर। यह कोड के पूरे ब्लॉक को निर्बाध बनाता है। यद्यपि इस ऑपरेशन का उपयोग शायद ही कभी किया जाता है, यह संसाधन रिसाव या ताले को जन्म दे सकता है।

इसी समय, यह पता चला है कि आप कैट्स आईओ के अंदर एक आदिम को परिभाषित कर सकते हैं, जो आपको इंटरप्ट पर अधिक नियंत्रण प्राप्त करने की अनुमति देता है। फैबियो लाबेला का बहुत जटिल कार्यान्वयन बेहद धीमा निकला।

ZIO आपको रुकावटों के साथ कोड लिखने की अनुमति देता है, घोषणात्मक यौगिक कथनों के साथ उच्च स्तर पर काम कर रहा है, और आपको कम प्रदर्शन और अवरुद्ध लीक के साथ संयुक्त गंभीर जटिलता के बीच चयन करने के लिए मजबूर नहीं करता है।

इसके अलावा, ZIO में हाल ही में जोड़ा गया सॉफ्टवेयर ट्रांजैक्शनल मेमोरी उपयोगकर्ता को डेटा संरचनाओं और कोड को घोषित रूप से लिखने की अनुमति देता है जो स्वचालित रूप से अतुल्यकालिक, प्रतिस्पर्धी हैं और व्यवधान की अनुमति देते हैं।

3. गारंटी फाइनल

कई प्रोग्रामिंग भाषाओं में कोशिश / अंत में ब्लॉक संसाधनों को लीक किए बिना तुल्यकालिक कोड लिखने के लिए आवश्यक गारंटी प्रदान करता है।

विशेष रूप से, यह ब्लॉक निम्नलिखित की गारंटी देता है: यदि कोई ट्रायल ब्लॉक निष्पादन शुरू करता है, तो अंत में ब्लॉक स्टॉप होने पर निष्पादित होगा।

यह वारंटी इस पर लागू होती है:

• नेस्टेड हैं "कोशिश / अंत में" ब्लॉक;
• "कोशिश ब्लॉक" में त्रुटियां हैं;
• नेस्टेड अंततः ब्लॉक में त्रुटियाँ हैं।

ZIO "सुनिश्चित करना" ऑपरेशन का उपयोग केवल कोशिश / अंत में किया जा सकता है:

 val effect2 = effect.ensuring(cleanup) 

ZIO "effect.ensuring (फाइनल)" के लिए निम्नलिखित गारंटी प्रदान करता है: यदि "प्रभाव" निष्पादित होना शुरू हुआ, तो "प्रभाव" बंद होने पर "अंतिम" निष्पादन शुरू हो जाएगा।

जैसे प्रयास / अंत में, ये गारंटी निम्न मामलों में रहती हैं:

• रचनाएं "सुनिश्चित" हैं;
• "प्रभाव" में त्रुटियां हैं;
• नेस्टेड "फाइनल" में त्रुटियां हैं।

इसके अलावा, गारंटी को बनाए रखा जाता है भले ही प्रभाव बाधित हो ("ब्रैकेट पर गारंटी" समान है, वास्तव में, "ब्रैकेट" "सुनिश्चित" पर लागू किया गया है)।

कैट IO डेटा प्रकार एक और, कमजोर गारंटी प्रदान करता है। "Effect.guarantee (फाइनलिज़र)" के लिए, इसे निम्न प्रकार से कमजोर किया जाता है: यदि "प्रभाव" निष्पादित किया जाने लगा, तो "अंतिम" तब निष्पादन शुरू करेगा जब "प्रभाव" बंद हो जाता है, यदि समस्या प्रभाव "प्रभाव" में नहीं डाली जाती है।

बिल्लियों IO में "ब्रैकेट" के कार्यान्वयन में एक कमजोर गारंटी भी पाई जाती है।

संसाधन रिसाव पाने के लिए, "गारंटी" या "ब्रैकेट.यूज़" प्रभाव के अंदर उपयोग किए जाने वाले प्रभाव का उपयोग करें, इसे इस तरह से लिखें:

 //   `interruptedFiber` -    val bigTrouble = interruptedFiber.join 

जब बिगटॉरबल को इस तरह से दूसरे प्रभाव में डाला जाता है, तो प्रभाव निर्बाध हो जाता है - "गारंटी" के माध्यम से सेट कोई "फाइनल", या "ब्रैकेट" के माध्यम से संसाधनों की सफाई निष्पादित नहीं की जाएगी। यह सब संसाधनों की एक नाली की ओर जाता है, तब भी जब ब्लॉक में "फाइनल" होता है।

उदाहरण के लिए, निम्नलिखित कोड में "फाइनल" कभी भी निष्पादन शुरू नहीं करेगा:

 (IO.unit >> bigTrouble).guarantee(IO(println("Won't be executed!!!«))) 

जब वैश्विक संदर्भ को ध्यान में रखे बिना कोड का मूल्यांकन किया जाता है, तो यह निर्धारित करना असंभव है कि "ब्रैकेट" ऑपरेशन के "उपयोग" प्रभाव में कहीं भी डाला जाएगा या "फाइनल" ब्लॉक के अंदर।

इसलिए, आप यह पता लगाने में सक्षम नहीं होंगे कि पूरे कार्यक्रम का मूल्यांकन किए बिना कैट आईओ कार्यक्रम संसाधन लीक या लापता "फाइनल" ब्लॉक के साथ काम करेगा या नहीं। पूरे कार्यक्रम को केवल मैन्युअल रूप से मूल्यांकन किया जा सकता है, और यह प्रक्रिया हमेशा उन त्रुटियों के साथ होती है जिन्हें कंपाइलर द्वारा सत्यापित नहीं किया जा सकता है। इसके अलावा, इस प्रक्रिया को हर बार कोड में कोई महत्वपूर्ण परिवर्तन होने पर दोहराया जाना चाहिए।

ZIO में कैट्स इफ़ेक्ट, "गारंटी कैस" और "ब्रैकेट" से "गारंटी" का कस्टम कार्यान्वयन है। कार्यान्वयन में मूल ZIO शब्दार्थ (न कि कैट IO शब्दार्थ) का उपयोग होता है, जो हमें संसाधन लीक के साथ संभावित समस्याओं का मूल्यांकन करने की अनुमति देता है यहां और अब, यह जानते हुए कि सभी स्थितियों में अंतिम रूप से लॉन्च किया जाएगा और संसाधनों को मुक्त किया जाएगा।

4. स्थिर स्विचिंग

कैट्स इफ़ेक्ट में "कॉन्टेक्स्टशिफ्ट" से "इवैलोन" विधि है, जो आपको कुछ कोड के निष्पादन को दूसरे निष्पादन संदर्भ में ले जाने की अनुमति देती है।

यह कई कारणों से उपयोगी है:

• कई क्लाइंट लाइब्रेरी आपको अपने थ्रेड पूल में कुछ काम करने के लिए मजबूर करती हैं;
• यूआई पुस्तकालयों को यूआई थ्रेड में होने वाले कुछ अपडेट की आवश्यकता होती है;
• कुछ प्रभावों को उनके विशिष्ट विशेषताओं के अनुकूल थ्रेड पूल पर अलगाव की आवश्यकता होती है।

"एवलॉन" ऑपरेशन उस प्रभाव को निष्पादित करता है जहां इसे चलाया जाना चाहिए, और फिर मूल निष्पादन संदर्भ पर लौटता है। उदाहरण के लिए:

 cs.evalOn(kafkaContext)(kafkaEffect) 

नोट: कैट IO में एक समान "शिफ्ट" निर्माण है, जो आपको वापस जाने के बिना एक अलग संदर्भ में स्विच करने की अनुमति देता है, लेकिन व्यवहार में, इस व्यवहार की शायद ही कभी आवश्यकता होती है, इसलिए "evalOn" को प्राथमिकता दी जाती है।

"EvalOn" का ZIO कार्यान्वयन (ZIO आदिम "लॉक" पर बनाया गया) विशिष्ट रूप से समझने के लिए आवश्यक गारंटी प्रदान करता है कि प्रभाव कहाँ काम करता है - प्रभाव हमेशा एक विशिष्ट संदर्भ में निष्पादित किया जाएगा।

कैट्स IO की एक अलग, कमजोर गारंटी है - प्रभाव को पहले असिंक्रोनस ऑपरेशन या आंतरिक स्विचिंग तक एक निश्चित संदर्भ में निष्पादित किया जाएगा।

एक छोटे से कोड को ध्यान में रखते हुए, यह सुनिश्चित करना असंभव है कि क्या एसिंक्रोनस प्रभाव (या नेस्टेड स्विचिंग) उस प्रभाव में बनाया जाएगा जो स्विच करेगा, क्योंकि अतुल्यकालिक प्रकारों में प्रदर्शित नहीं होता है।

इसलिए, संसाधन सुरक्षा के मामले में, यह समझने के लिए कि कैट्स आईओ प्रभाव कहाँ लॉन्च किया जाएगा, पूरे कार्यक्रम का अध्ययन करना आवश्यक है। व्यवहार में, और मेरे अनुभव से, कैट्स आईओ उपयोगकर्ताओं को आश्चर्य होता है, जब एक संदर्भ में "evalOn" का उपयोग करते हुए, यह बाद में पता चलता है कि अधिकांश प्रभाव गलती से दूसरे में प्रदर्शन किया गया था।

ZIO आपको यह निर्धारित करने की अनुमति देता है कि प्रभावों को कहां ट्रिगर किया जाना चाहिए, और विश्वास करें कि यह सभी मामलों में होगा, चाहे प्रभाव अन्य प्रभावों में कैसे बना हो।

5. त्रुटि संदेशों की सुरक्षा

कोई भी प्रभाव जो संसाधन, संगामिति, या संसाधनों तक सुरक्षित पहुँच का समर्थन करता है, एक रैखिक त्रुटि मॉडल में चलेगा: सामान्य तौर पर, सभी त्रुटियों को नहीं बचाया जा सकता है।

यह दोनों `थ्रोएबल` के लिए सही है, एक निश्चित त्रुटि प्रकार जो कि कैट्स आईओ में बनाया गया है, और पॉलीओर्फिक त्रुटि प्रकार जो कि जिओ द्वारा समर्थित है।

कई एक समय की त्रुटियों के साथ स्थितियों के उदाहरण:

• फाइनल एक अपवाद फेंकता है;
• दो (गिरने) प्रभाव समानांतर निष्पादन में संयुक्त होते हैं;
• रेसिंग की स्थिति में दो (गिरने) प्रभाव;
• रुकावट से सुरक्षित अनुभाग छोड़ने से पहले बाधित प्रभाव गिरता है।

चूंकि सभी त्रुटियां सहेजे नहीं जाते हैं, ZIO एक नि: शुल्क सेमिनार (अमूर्त बीजगणित से एक अमूर्त, इसका ज्ञान यहां नहीं माना जाता है) पर आधारित एक "कारण [ई]" डेटा संरचना प्रदान करता है, जो किसी भी प्रकार की त्रुटि के लिए धारावाहिक और समानांतर त्रुटियों को जोड़ने की अनुमति देता है। सभी परिचालनों के दौरान (एक गिर या बाधित प्रभाव के लिए सफाई सहित), ZIO त्रुटियों को "कारण [E]" डेटा संरचना में एकत्रित करता है। यह डेटा संरचना किसी भी समय उपलब्ध है। नतीजतन, ZIO हमेशा सभी त्रुटियों को संग्रहीत करता है: वे हमेशा उपलब्ध होते हैं, उन्हें व्यावसायिक आवश्यकताओं के अनुसार लॉग किया जा सकता है, अध्ययन किया जा सकता है और रूपांतरित किया जा सकता है।

कैट IO ने त्रुटि जानकारी के नुकसान के साथ एक मॉडल चुना। जबकि ZIO कॉज़ [E] के माध्यम से दो त्रुटियों को कनेक्ट करेगा, कैट्स IO त्रुटि संदेशों में से एक को "खो" देगा, उदाहरण के लिए, "e.printStackTrace ()" जो त्रुटि होती है पर कॉल करके।

उदाहरण के लिए, इस कोड में "फाइनल" में एक त्रुटि खो जाएगी।

 IO.raiseError(new Error("Error 1")).guarantee(IO.raiseError(new Error("Error 2«))) 

ट्रैकिंग त्रुटियों के लिए इस दृष्टिकोण का अर्थ है कि आप स्थानीय रूप से त्रुटियों के पूरे स्पेक्ट्रम का पता लगा सकते हैं और संसाधित कर सकते हैं जो प्रभावों के संयोजन के कारण होता है। ZIO आपको किसी भी प्रकार की त्रुटि का उपयोग करने की अनुमति देता है, जिसमें "थ्रोएबल" (या "IOExceptio" या एक अन्य कस्टम अपवाद पदानुक्रम जैसे अधिक विशिष्ट उपप्रकार) शामिल हैं, यह सुनिश्चित करते हुए कि प्रोग्राम निष्पादन के दौरान कोई त्रुटि नहीं हुई है।

6. गतिरोध के बिना अतुल्यकालिक

ZIO और Cats IO दोनों एक कंस्ट्रक्टर प्रदान करते हैं जो आपको कॉलबैक के साथ कोड लेने और इसे प्रभावी रूप से लपेटने की अनुमति देता है

यह सुविधा बिल्लियों के प्रभाव में Async पाइप वर्ग के माध्यम से प्रदान की जाती है:

 val effect: Task[Data] = Async[Task].async(k => getDataWithCallbacks( onSuccess = v => k(Right(v)), onFailure = e => k(Left(e)) )) 

यह एक अतुल्यकालिक प्रभाव बनाता है, जिसे निष्पादित करते समय, मूल्य प्रकट होने तक इंतजार करेंगे, और फिर जारी रखेंगे, और यह सब प्रभाव के उपयोगकर्ता के लिए स्पष्ट होगा। इसलिए, अतुल्यकालिक कोड विकसित करने के लिए कार्यात्मक प्रोग्रामिंग बहुत आकर्षक है।

ध्यान दें कि जैसे ही कॉलबैक कोड एक प्रभाव में बदल जाता है, कॉलबैक फ़ंक्शन (यहां इसे `k` कहा जाता है) कहा जाता है। यह कॉलबैक फ़ंक्शन सफलता / त्रुटि मान के साथ बाहर निकलता है। जब यह कॉलबैक फ़ंक्शन कहा जाता है, तो प्रभाव का निष्पादन (पहले रोका गया) फिर से शुरू होता है।

ZIO गारंटी देता है कि प्रभाव रनटाइम थ्रेड पूल पर निष्पादन को फिर से शुरू करेगा यदि प्रभाव किसी विशेष विशेष संदर्भ में, या प्रभाव को संलग्न करने के लिए किसी अन्य संदर्भ को नहीं सौंपा गया था।

Cats IO कॉलबैक थ्रेड पर प्रभाव को फिर से शुरू करता है। इन विकल्पों के बीच का अंतर काफी गहरा है: कॉलबैक के कारण थ्रेड कॉलबैक कोड को हमेशा के लिए निष्पादित करने की उम्मीद नहीं करता है, लेकिन केवल नियंत्रण रिटर्न से पहले थोड़ी देरी की अनुमति देता है। दूसरी ओर, कैट्स आईओ इस तरह की गारंटी बिल्कुल नहीं देता है: कॉलिंग थ्रेड, लॉन्चिंग कॉलबैक, फ्रीज हो सकता है, अनिश्चित समय का इंतजार कर सकता है जब निष्पादन नियंत्रण वापस आ जाता है।

बिल्लियों के प्रभाव ("स्थगित", "सेमफोर") में प्रतिस्पर्धी डेटा संरचनाओं के पहले संस्करण फिर से शुरू हुए प्रभाव जो कॉलिंग थ्रेड को निष्पादन का नियंत्रण वापस नहीं करते हैं। नतीजतन, गतिरोध और एक टूटे हुए निष्पादन अनुसूचक से संबंधित समस्याओं की खोज की गई थी। यद्यपि ये सभी समस्याएं पाई गई हैं, वे केवल कैट्स इफेक्ट में प्रतिस्पर्धी डेटा संरचनाओं के लिए तय की गई हैं।

उपयोगकर्ता कोड जो कैट आईओ के समान दृष्टिकोण का उपयोग करता है, वह इस तरह की परेशानियों में पड़ जाएगा, क्योंकि इस तरह के कार्य गैर-नियतात्मक हैं, त्रुटियों केवल रनटाइम में बहुत कम ही हो सकती हैं, जिससे डिबगिंग और समस्या का पता लगाना एक कठिन प्रक्रिया है।

ZIO डेडलॉक सुरक्षा प्रदान करता है और एक सामान्य कार्य शेड्यूलर बॉक्स से बाहर निकलता है, और उपयोगकर्ता को स्पष्ट रूप से कैट्स IO के व्यवहार का भी चयन करता है (उदाहरण के लिए, "प्रॉमिस" पर "असुरक्षित" का उपयोग करके, जो फिर से शुरू हुए अतुल्यकालिक प्रभाव में समाप्त होता है)।

यद्यपि कोई भी समाधान पूरी तरह से सभी मामलों के लिए उपयुक्त नहीं है, और ZIO और Cats IO सभी परिस्थितियों (अलग-अलग तरीकों से) को हल करने के लिए पर्याप्त लचीलापन प्रदान करते हैं, ZIO का मतलब बिना किसी चिंता के "Async" का उपयोग करना है और आपको समस्या कोड को "असुरक्षित" में डालने के लिए मजबूर करता है, जो गतिरोध पैदा करने के लिए जाना जाता है

7. भविष्य के साथ संगत

स्काला मानक पुस्तकालय से "फ्यूचर" का उपयोग करना बड़ी संख्या में कोड बेस के लिए एक वास्तविकता है। ZIO एक "FromFuture" विधि के साथ आता है, जो एक तैयार निष्पादन निष्पादन प्रदान करता है:

 ZIO.fromFuture(implicit ec => // Create some Future using `ec`: ??? ) 

जब इस विधि का उपयोग Future को एक प्रभाव में लपेटने के लिए किया जाता है, तो ZIO सेट कर सकता है कि Future को कहां निष्पादित किया जाएगा, और अन्य विधियां, जैसे कि evalOn, भविष्य को वांछित निष्पादन संदर्भ में सही ढंग से स्थानांतरित कर देगा। कैट्स IO "फ्यूचर" को स्वीकार करता है, जिसे एक बाहरी "एक्जिक्यूशनकोटेक्स्ट" के साथ बनाया गया था। इसका मतलब यह है कि कैट्स IO इवेलॉन या शिफ्ट के तरीकों की आवश्यकताओं के अनुसार फ्यूचर के निष्पादन को आगे नहीं बढ़ा सकता है। इसके अलावा, यह भविष्य के लिए निष्पादन के संदर्भ को निर्धारित करने के साथ उपयोगकर्ता पर बोझ डालता है, जिसका अर्थ है संकीर्ण चयन और एक अलग वातावरण।

चूंकि प्रदत्त एक्ज़ीक्यूशन कोटेक्स्ट को अनदेखा किया जा सकता है, ZIO को सामान्य मामले में फ्यूचर के साथ एक स्मूथ और अधिक सटीक इंटरैक्शन की गारंटी देते हुए कैट्स IO फीचर्स के योग के रूप में दर्शाया जा सकता है, लेकिन अभी भी कुछ अपवाद हैं।

8. ब्लॉकिंग आईओ

जैसा कि लेख " थ्रेड पूल " में दिखाया गया था । ZIO के साथ सर्वोत्तम अभ्यास ”, सर्वर अनुप्रयोगों के लिए, अधिकतम दक्षता के लिए कम से कम दो अलग-अलग पूलों की आवश्यकता होती है:

• सीपीयू / अतुल्यकालिक प्रभाव के लिए निश्चित पूल;
• गतिशील, अवरुद्ध धागे की संख्या में वृद्धि की संभावना के साथ।

एक निश्चित थ्रेड पूल पर सभी प्रभावों को चलाने के निर्णय से एक दिन गतिरोध पैदा होगा, जबकि गतिशील पूल पर सभी प्रभावों को ट्रिगर करने से प्रदर्शन हानि हो सकती है।

JVM पर, ZIO दो ऑपरेशन प्रदान करता है जो अवरोधक प्रभावों का समर्थन करते हैं:

• "ब्लॉकिंग (प्रभाव") ऑपरेटर, जो ब्लॉकिंग थ्रेड्स के पूल में एक निश्चित प्रभाव के निष्पादन को स्विच करता है जिसमें अच्छे प्रीसेट होते हैं जिन्हें वांछित होने पर बदला जा सकता है);
• «effectBlocking(effect)» , , .

, , , «blocking». , - , , «effectBlocking» , ZIO ( ).

Cats IO , . , «blocking», «evalOn», , , .

( ZIO) (, ), .

9.

, Scala, :

• «ReaderT»/ «Kleisli», ;
• «EitherT», ( «OptionT», «EitherT» «Unit» ).

, (, http4s «Kleisli» «OptionT»). («effect totation»), ZIO «reader» «typed error» ZIO. «reader» «typed error» , ZIO , . , «Task[A]», «reader» «typed errors».

ZIO () - . , ZIO , .

Cats IO . , , «reader» «typed errors» «state», «writer» , .

ZIO 8 Cats IO . , Scala .

10.

ZIO , , . , Scala, .

ZIO 2000 , «typed errors» , — 375 . Scala , . , , .

:

• ;
• ;
• , ;
• .

. , - , .

- . , . ZIO . Cats IO , , ZIO ( , ).

11.

ZIO , , - .

• , : «ZIO. succeed» «Applicative[F].pure», «zip» «Apply[F].product», «ZIO.foreach» «Traverse[F].traverse».
  
• (Cats, Cats Effect, Scalaz ).
• , ( «Runtime», Cats Effect - Cats Effect). — Cats IO.
• .
• . : "zip"/"zipPar", "ZIO.foreach"/"ZIO.foreachPar", "ZIO.succeed"/"ZIO.succeedLazy«.
  
• , «». ZIO IDE.
• Scala ZIO : «ZIO.fromFuture», «ZIO.fromOption», «ZIO.fromEither», «ZIO.fromTry».
• «».

, Scala, , ZIO , , , ZIO, . Cats IO , Cats.

, , , ( , , ).

12.

ZIO — - , .

:

• , «Ref», «Promise», «Queue», «Semaphore» «Stream» //;
• STM, , , ;
• «Schedule», ;
• «Clock», «Random», «Console» «System» , ;
• , .

- Cats IO . Cats IO , ( ) .

निष्कर्ष

Cats Effect Scala-, , .

, Cats Effect, , Cats Effect : Cats IO, Monix, Zio.

, . , , , : ZIO Cats Effect .

Scala — . , Scala. ScalaConf , 18 , John A De Goes .