Stephen Cleary adalah salah satu dari
100 pengguna
teratas Stack Overflow. Sebagian besar berkat jawaban asinkronnya di .NET. Hidupnya tidak terbatas pada pemrograman: di Twitter, ia pertama kali menulis tentang dirinya sendiri "Kristen", dan hanya kemudian "pengembang".
Sekarang, sehubungan dengan penampilan aliran async, pengetahuannya sangat relevan: sebagai pelapor tentang topik ini, sosok Stephen hanya memohonnya. Dan segera di DotNext dia
akan menceritakannya . Sementara itu, kami bertanya kepadanya tentang semua ini: agama, Stack Overflow, dan asynchrony.
Biografi
- Pertanyaan pertama sederhana: beri tahu kami tentang biografi profesional Anda.- Saya menjadi tertarik pada pemrograman cukup awal, saya berusia 7-8 tahun. Kemudian di sekolah saya bisa menulis program kecil dalam bahasa Logo, dan ini adalah pengalaman pemrograman pertama saya. Kemudian, ketika saya berusia 12-13, saya menabung di komputer pertama saya. Dan ketika saya memilih Ilmu Komputer ketika saya masuk perguruan tinggi, itu adalah keputusan yang sangat jelas: saya sudah tertarik pada komputer untuk waktu yang nyata.
Pada tahun 1998, setelah lulus dari perguruan tinggi, saya mulai bekerja di perusahaan lokal yang bergerak di bidang konveyor yang secara otomatis dikendalikan oleh kendaraan untuk industri dan otomatisasi pabrik lainnya. Tujuh tahun kemudian, perusahaan pindah ke Detroit, tetapi saya tidak ingin pindah ke sana, dan sejak itu saya berhasil bekerja di perusahaan yang berbeda. Sejak 2013, saya bekerja jarak jauh, satu setengah tahun terakhir di Faithlife.
- Lucu sekali Anda memulai dengan Logo, dan sekarang di sebuah perusahaan yang produk utamanya disebut Logo. Dan apa yang sebenarnya kamu lakukan di sana?- Backend: layanan web diakses oleh Logo dan produk lain dari perusahaan. Faithlife memiliki beragam produk terkait gereja. Logo - untuk pembelajaran Alkitab. Dan ada juga Proclaim, yang dirancang untuk mereka yang memberikan khotbah (membantu dengan slide dan sejenisnya). Faithlife secara historis membuat produk untuk pendeta, tetapi sekarang mereka menambahkan hal-hal yang membantu orang awam.
Saya melakukan backend, saya sering harus berurusan dengan ASP.NET Web API, dan saat ini saya sedang bekerja dengan Docker. Saat ini kami memiliki bagian di cloud, dan sebagian di tempat, dan sesuatu tidak boleh ditransfer ke cloud sama sekali, tetapi kami ingin mentransfer beberapa hal di sana - dan saya sedang melakukannya.
Agama
- Tidak jarang Anda bertemu dengan perusahaan yang membuat perangkat lunak "gereja", jadi saya ingin mengklarifikasi: apakah bekerja di backend terlihat seperti di tempat lain, atau apakah ia memiliki spesifikasi sendiri? Dan pengembang biasanya orang percaya dan mereka sendiri menggunakan produk perusahaan, atau tidak?- Tidak ada perbedaan mendasar dalam pekerjaan: Anda perlu berpikir tentang desain API yang tepat seperti halnya di tempat lain. Beberapa produk kami (terutama yang desktop) sudah ada sejak lama, dan kami harus berurusan dengan API lama. Dan ketika mulai menggunakan Docker, penting untuk memikirkan kompatibilitas ke belakang. Secara umum, kami memiliki keprihatinan yang sama dengan orang lain.
Meskipun Faithlife membuat produk untuk gereja, itu bukan perusahaan Kristen. Untuk sampai di sini, Anda tidak perlu menjadi seorang Kristen: pertama, pilihan semacam itu akan melanggar hukum Amerika (akan menjadi diskriminasi agama dalam perekrutan), dan kedua, perusahaan tidak akan menginginkan hal ini pula.
Tetapi bagi pengembang untuk menggunakan produk perusahaan, itu dianjurkan dalam segala hal. Sebagai contoh, baru-baru ini menghabiskan hari pelatihan tentang penggunaan Logo. Kami juga memiliki banyak alat internal - dalam hal ini, kami didorong untuk pergi bekerja hari itu di departemen yang menggunakan alat Anda untuk secara pribadi melihat bagaimana ini terjadi.
- Di Twitter Anda di bidang bio ada kata-kata "Kristen" dan "pengembang". Apakah kedua bagian dari identitas Anda ini berpotongan?- Saya akan mengatakan bahwa mereka terpisah. Saya selalu mencoba untuk memisahkan kehidupan kerja dan rumah, tidak melakukan pekerjaan di waktu luang saya (meskipun tidak selalu berhasil). Gereja adalah bagian besar dari kepribadian saya, sebagian besar teman saya berasal dari sana. Di tempat kerja, saya punya beberapa teman.
"Yah, bio Anda juga mengatakan" kecanduan menulis OSS, "dan memberi orang-orang perangkat lunak bebas suara altruistik dan Kristen. Dalam hal ini, tidak ada korelasi?- Hmm, mungkin. Saya pikir, dari sudut pandang filosofis, Anda benar-benar dapat melihat hubungan antara open source dan Kristen: dalam kedua kasus, penekanannya adalah pada "memberi kepada orang-orang" yang Anda sebutkan.
Ada juga jenis open source "kemanusiaan". Saya sendiri tidak terlibat dalam hal ini, saya memiliki perpustakaan untuk keperluan umum. Tapi saya tahu pengembang Kristen yang telah bekerja secara gratis pada sesuatu yang secara langsung mempengaruhi kehidupan lain, terutama di tempat-tempat dengan orang miskin. Misalnya, perangkat lunak yang memungkinkan Anda memastikan alarm kebakaran berfungsi dengan baik. Di sini, tentu saja, ada korelasinya.
- Anda juga aktif di Stack Overflow - apakah ini juga cara bagi Anda untuk memberikan sesuatu tanpa pamrih kepada komunitas?- Saya tidak akan mengatakan itu, bagi saya rasanya lebih seperti "mengajar." Meskipun "mengajar" juga dapat dihubungkan dengan agama Kristen ... Keluarga saya memiliki banyak guru, dan saya melanjutkan ini dengan cara saya sendiri - bukan sebagai profesi, tetapi dengan bantuan Stack Overflow dan konferensi. Jadi saya memuaskan kebutuhan saya untuk ini.
Stack overflow
- Kami masih memiliki sejumlah pertanyaan tentang Stack Overflow, yang aneh pertama. Anda baru-baru ini menerima lencana di sana untuk jawaban di Windows Phone 8:
Bagaimana bisa terjadi bahwa pada tahun 2019 Anda menerima lencana untuk jawaban tentang teknologi yang hampir mati? Apakah seseorang masih bertanya tentangnya?- Untuk mendapatkan lencana, Anda biasanya memerlukan setidaknya sejumlah jawaban dengan jumlah suara tertentu untuk jawaban ini. Saya kira saya mendapat lencana ini karena sekarang seseorang memilih beberapa jawaban saya, yang diterbitkan bertahun-tahun yang lalu, dan dengan itu akhirnya mendapatkan jumlah suara yang tepat. Ini lucu karena saya belum melihat pertanyaan Windows Phone 8 untuk waktu yang sangat lama!
(tertawa)- Pada SO, reputasi Anda adalah 320.000 - dan ini lebih dari seperempat reputasi John Skeet yang legendaris, meskipun Anda memberikan jawaban dengan urutan yang lebih kecil darinya. Bagaimana Anda mendapatkan ini?- Saya tidak begitu yakin. Lebih mudah untuk mendapatkan reputasi bagi mereka yang datang ke situs sebelum orang lain, dan meskipun saya adalah salah satu pengguna awal, saya masih datang terlambat daripada banyak orang. Saya mulai menjawab pertanyaan - awalnya, 1-2 per hari, yang sangat jauh dari John Skeet. Berfokus pada topik async / menunggu, serta konkurensi dan multithreading - hanya karena itu, pada kenyataannya, menjadi spesialisasi saya. Bertahun-tahun yang lalu saya sudah terlibat dalam asinkron, dan kemudian itu menyakitkan. Jadi ketika async / menunggu muncul, saya langsung melihat apa artinya itu. Jadi saya berada di waktu yang tepat di tempat yang tepat, dan “darah guru” saya membantu menjelaskan semuanya dalam bahasa yang dimengerti orang. Dan dalam kasus Stack Overflow, saya berubah menjadi spesialis async / menunggu lokal. Dan John Skeet - yah, dia tidak mengatakannya secara langsung, tapi saya kira itu - meninggalkan sebagian besar pertanyaan tentang async / menunggu saya. Tapi dia, tentu saja, menjawab lebih dari saya, dia tidak bisa ditangkap!
- Melihat jumlah reputasi, mudah untuk berpikir "seseorang membutuhkan setengah hidupnya untuk menjawab" - dan berapa banyak waktu yang Anda habiskan untuk SO?"Tidak banyak." Saya memeriksa Stack Overflow beberapa kali sehari, dan biasanya menjawab 1-3 pertanyaan. Dan saya mendapatkan mayoritas suara positif untuk jawaban yang tersisa bertahun-tahun yang lalu. Inilah cara SO membantu mereka yang datang lebih awal: mereka adalah yang pertama menjawab pertanyaan bertahun-tahun yang lalu, menerima suara, dan suara-suara membuat jawaban ini lebih terlihat, dan pada akhirnya mereka mendapatkan suara baru. Ini adalah efek longsoran yang mendorong jawaban lama.
Tampaknya bagi saya ini menyebabkan beberapa masalah, karena kadang-kadang ada jawaban baru yang merujuk pada teknologi yang lebih modern dan karena itu lebih baik, tetapi jawaban lama tidak diperbarui. Tapi, secara umum, saya mendapat mayoritas suara untuk jawaban lama, tapi saya masih mencoba menjawab yang baru setiap hari. Saya tidak menghabiskan banyak waktu untuk hal ini, saya hanya melakukannya terus-menerus selama bertahun-tahun.
- Ketika John Skeet terbang kepada kami di DotNext, kami bertanya kepadanya tentang keadaan Stack Overflow saat ini dan apa yang dianggapnya sebagai masalah situs. Sangat menarik untuk membandingkan: apa pendapat Anda tentang ini?"Saya pikir SO membaik, terutama pada tahun lalu." Mereka sekarang berusaha sangat keras untuk meningkatkan kualitas pertanyaan. Seringkali, orang pertama yang menanyakan sesuatu di situs ini tidak terbiasa dengan cara mengajukan pertanyaan teknis dengan benar.
Dan ini adalah masalah yang selalu ada di Internet. Di tahun 90-an, ketika semua orang berada di newsgroup, dia juga ada di sana. Sepuluh tahun kemudian, semuanya terjadi di milis dan Grup Google. Sekarang sumber daya baru untuk pertanyaan pemrograman Stack Overflow. Tetapi selalu ada pertanyaan tentang pemrograman, dan bagaimana cara mengajukan pertanyaan yang baik selalu menjadi masalah, dan bagaimana menjaga komunitas yang ramah juga. Mungkin masalah ini tidak akan pernah bisa diselesaikan sepenuhnya. Saya tidak mengatakan bahwa kita seharusnya tidak mengerjakan ini - kita harus pasti. Tetapi jika Anda melihat ke masa lalu, ternyata bahkan di tahun 90-an sudah ada tutorial tertulis tentang cara mengajukan pertanyaan teknis.
Ada beberapa masalah yang baru di Stack Overflow. Anda bisa mulai dengan fakta bahwa banyak dari mereka tidak pernah bertanya kepada orang lain sebelum menanyakan pertanyaan pertama mereka. Karena itu, dalam banyak kasus, mereka sama sekali tidak menyadari semua hal yang harus disajikan dalam pertanyaan sehingga dapat dijawab.
Dan kemudian, bayangkan Anda sedang mengerjakan suatu tugas. Anda jungkir balik dalam kode, kepala Anda dipenuhi dengan semua ini. Dan Anda melihat beberapa hal tertentu yang tidak cocok dengan cara apa pun. Ini adalah detail konkret kecil dari sistem besar, dan biasanya Anda bertanya "Bagaimana saya bisa melakukan hal kecil ini?" Tanpa menyadari bahwa Anda memiliki semua konteks ini yang Anda tahu, tetapi Anda tidak memasukkannya ke dalam pertanyaan. Seringkali pertanyaan "Bagaimana saya membuat X" jawaban yang benar adalah "Jangan lakukan X, lakukan Y". Ini adalah jebakan yang sering jatuh ke dalam orang ketika menulis pertanyaan pertama. Mereka tidak menyadari bahwa jawaban mereka dalam bentuk saat ini adalah "tidak responsif".
Dan di samping masalah kualitas pertanyaan, ada juga kecenderungan - terutama pada Stack Overflow, di mana setiap orang berjuang untuk mendapatkan poin, mencoba menjawab secepat mungkin - dengan cepat menutup pertanyaan atau dengan cepat menuliskan jawaban yang paling tidak menyenangkan. Saya tidak bermaksud “dengki,” saya telah melihat sangat sedikit komentar dengki jujur - hanya beberapa selama bertahun-tahun. Sebaliknya, mereka keras, dan bagi penulis pertanyaan ini dibaca sebagai tidak ramah.
Stack Overflow telah mengambil beberapa langkah sederhana untuk memperbaikinya. Sekarang, ketika orang pertama kali mengajukan pertanyaan, situs memberi tahu Anda apa yang harus dimasukkan di dalamnya. Mereka sebelumnya menambahkan "lihat pertanyaan-pertanyaan serupa ini," yang merupakan langkah pertama yang baik. Dan sekarang ada seluruh sistem yang perlu diselesaikan untuk pertanyaan pertama, yang membantu menyusunnya dengan baik.
Mereka juga menambahkan pengingat bagi mereka yang menulis jawaban. Seperti "Ini pemula, ramah," dan ini cara yang baik untuk mengingatkan Anda bahwa kebanyakan orang tidak menulis pertanyaan dengan baik pertama kali, dan itu benar-benar normal. Secara umum, mereka sedang mengerjakannya. Apakah masalah ini akan diselesaikan sepenuhnya? Saya meragukannya. Tetapi kemajuan itu mungkin.
Sinkronisasi
- Dalam posting yang didedikasikan untuk peringatan 10 tahun iPhone, Anda menulis bahwa penampilannya memengaruhi pemrograman asinkron, karena aplikasi seluler harus responsif. Dan dapatkah Anda memberikan latar belakang sejarah umum tentang perkembangan asinkron bagi mereka yang baru-baru ini mulai berkembang dan tidak melihat dunia tanpa asinkron / menunggu?- Yah, pemrograman asinkron selalu dimungkinkan. Saya pikir di tahun 60an mereka sudah melakukannya. Dan dia memiliki keuntungan yang sama untuk waktu yang lama: UI yang lebih responsif dan bagian server yang lebih skalabel. Dan dukungan selalu menjadi masalah: sangat sulit untuk mempertahankan kode asinkron. Awalnya, itu dibangun di atas callback.
Saya pikir langkah besar adalah munculnya Janji. Ini adalah apa yang mereka sebut dalam JavaScript, dan dalam C # itu adalah Task atau ValueTask. Dan ini adalah langkah besar ke depan, karena sekarang kami memiliki objek yang mewakili operasi. Anda bisa memonitor perkembangannya dan sebagainya. Dan async / menunggu dalam bahasa apa pun pada dasarnya hanya gula sintaksis di sekitar Janji.
Saya akan mengatakan bahwa penampilan Promise adalah peristiwa yang paling berdampak pada kode asinkron. Dan dalam hal async / menunggu, penting bahwa mesin negara dibuat untuk Anda. Di masa lalu, ketika kami bekerja dengan callback, kami harus membuat mesin negara kami sendiri. Dan itu selalu sulit karena Anda pasti lupa beberapa kondisi atau transisi, dan tidak ada yang berhasil. Dan itu sangat sulit untuk di-debug. Async / menunggu tidak membawa kemampuan untuk menulis kode asinkron, tetapi kemampuan untuk menulis kode yang dapat didukung.
- Dan sekarang apakah Anda melihat situasi tenang, atau apakah perubahan baru akan segera menunggu kita?- Saya pikir sekarang semuanya cukup stabil. Async / menunggu tampak revolusioner - tetapi hanya bagi mereka yang belum melakukan pemrograman asinkron sebelumnya. Dan bagi mereka yang bekerja, rasanya sangat alami. Tapi, secara umum, ini adalah peristiwa besar.
Dan sekarang acara lain hadir dengan .NET Core 3. Mereka melakukan apa yang oleh semua orang disebut stream async, meskipun sebenarnya mereka enumerables asinkron. Saya pikir ini akan membingungkan orang, karena sudah ada jenis aliran yang tidak ada hubungannya dengan aliran async. Secara umum, akan ada lebih banyak peningkatan bertahap. Akankah kita melihat sesuatu yang sebesar ketika async / menunggu pertama kali mengumumkan diri mereka sendiri? Saya kira tidak.
Jika Anda menginginkan perubahan paradigma baru, selalu ada kemungkinan sistem berbasis aktor. Atau sesuatu seperti goroutine, di mana semua asynchrony tersirat. Menurut saya, hal-hal ini agak mirip. Masalahnya adalah bahwa dalam. NET ini tidak begitu mudah untuk ditambahkan. Saya pikir ada terlalu banyak pembatasan untuk. NET untuk melakukan ini, jadi ini tidak mungkin terjadi. Jika kita melihat transisi skala besar ke dunia Aktor atau dunia Goroutine, di mana pendekatan konkurensi tidak akan sama dengan multithreading hari ini, ini akan membutuhkan bahasa dan runtime yang sepenuhnya baru. Dan .NET tidak layak untuk digunakan. Dan saya tidak berpikir bahwa pemrograman secara keseluruhan akan mengambil lompatan seperti itu. Mungkin saya salah, tetapi posisi saya saat ini adalah sebagai berikut.
- Lebih ke pertanyaan tentang seberapa banyak segalanya berubah dari waktu ke waktu. Banyak buku pemrograman dengan cepat menjadi usang, tetapi di mana perubahan kurang, mereka bertahan lebih lama. Bagaimana dengan Concurrency Anda di C # Cookbook , berapa banyak yang memerlukan pembaruan?- Pertanyaan bagus. Saya baru saja menerbitkan edisi kedua, dan yang pertama keluar pada tahun 2014. Artinya, lima tahun telah berlalu, dan kami sudah berada di edisi kedua - bagi saya sepertinya ini adalah perkembangan yang cepat.
Saya pikir itu masih tergantung pada bagaimana buku itu ditulis. Saya mencoba menulis agar tidak ketinggalan zaman selama mungkin. Anda hanya perlu mencoba untuk tidak merujuk pada hal-hal seperti Windows Phone 8. Tapi itu pasti akan menjadi usang pula. Async stream dan sejenisnya muncul, dan saya ingin memasukkan hal-hal seperti itu dalam buku. Akibatnya, ada sesuatu yang sudah ketinggalan zaman, tetapi sebagian besar materi bermigrasi ke edisi baru tanpa perubahan.
Dan, tentu saja, semuanya tergantung pada siapa buku ini dibuat. Tentu saja, buku tentang menggunakan Visual Studio 2008 akan kedaluwarsa dengan sangat cepat. Tapi saya pikir ada tempat untuk klasik asli. Saya menganggap Code Complete sebagai salah satu buku pemrograman terbaik di dunia. Dan berapa lama itu ditulis? Saya bahkan tidak tahu. Beberapa dekade yang lalu. Dan ini masih merupakan buku yang fantastis! Sesuatu di dalamnya sudah ketinggalan zaman, tetapi secara keseluruhan masih bagus.
- Baru-baru ini, ada tweak tentang async / menunggu di Twitter, yang dimulai dengan tweet dari Vaughn Vernon, penulis beberapa buku tentang DTD dan model aktor:
Dia tidak suka async / menunggu importunity - menurutnya, ini menyebar ke seluruh kode dan dapat menyebabkan pemblokiran utas. Apa yang Anda pikirkan tentang ini? Apakah layak merancang sesuatu yang lain?- Ya, mungkin fakta bahwa async / menunggu menyebar di sekitar proyek adalah keluhan yang paling umum. Saya ingin menyebutkan beberapa hal di sini.
Pertama, kode asinkron, agar benar-benar asinkron, memerlukan asinkron dari semua orang yang memanggilnya. Dan itu tidak berkeliling. Paradigma apa pun yang Anda gunakan (bahkan salah satu yang lama), pada akhirnya Anda mengalami hal itu. Saya punya laporan di mana saya secara kronologis melewati semua paradigma dan menunjukkan bagaimana kode menjadi lebih bersih dan lebih baik.
Ada beberapa pendekatan berbeda untuk menghindari dominasi async / menunggu yang meluas. Yang pertama adalah mengisolasi semua input / output menjadi objek yang terpisah. Anda dapat menggunakan pola desain seperti Ports & Adapters: ini memungkinkan Anda untuk mengandung semua I / O di luar logika bisnis Anda, dan kemudian itu tidak akan memerlukan async / menunggu sama sekali. Baru-baru ini saya melihat seluruh laporan tentang cara mencegah "async di mana-mana" dengan refactoring proyek sehingga logika bisnis tidak pernah berurusan dengan I / O. Saya akan merekomendasikan pendekatan ini.
Ada pendekatan lain untuk berurusan dengan dominasi async / menunggu, tetapi tidak layak di .NET. Menurut pendapat saya, Go mencoba melakukan ini dengan goroutin. Bahkan, semuanya ada di sana - itu adalah async / menunggu yang solid. Anda dapat menghapus async / menunggu dari bahasa dengan menambahkannya ke semuanya dan membuatnya tersirat.
Tidak ada cara lain. Ketika async / menunggu muncul, seseorang (saya tidak ingat persis siapa) mengatakan bahwa itu seperti virus zombie: segera setelah bagian dari kode Anda terinfeksi, distribusi dimulai.
- Beberapa pengembang menggunakan model aktor, menjelaskan ini dengan kesederhanaan kontrol aliran (aktor, pada kenyataannya, single-threaded). Apakah Anda berpikir bahwa dengan pilihan perpustakaan yang tepat, pengembang dapat menyingkirkan kerumitan pemrograman konkurensi?"Yah, tidak cukup." Karena bahkan dengan model aktor, masalah tetap ada. Anda tidak akan menemukan kondisi lomba seperti dalam program multi-utas, tetapi Anda akan mengalami kesulitan persahabatan.
Misalnya, masalah dengan keterlambatan pesan atau dengan pesan yang tidak sinkron. Mereka biasanya diperlukan untuk mencegah kebuntuan dalam model aktor. Tetapi setiap model aktor yang menggunakan pesan asinkron juga dapat menyebabkan kebuntuan. Pesan asinkron juga dapat membuat masalah koordinasi mereka sendiri. Biasanya pada level ini seseorang juga harus berhadapan dengan idempotensi.
Juga, menggunakan aktor dengan pesan asinkron dapat membuat manajemen negara cukup membingungkan, kecuali jika itu terjadi sepenuhnya dalam pesan. Dan bahkan dalam kasus ini, Anda akan mengalami kesulitan dengan konsistensi akhirnya. Secara umum, dari sudut pandang saya, model aktor tidak dapat menyelesaikan semua masalah. Saya akan menggambarkannya seperti ini: itu hanya bisa berubah di mana masalah akan muncul.
"Anda dikenal sebagai donor, tetapi Anda menggunakan bahasa lain seperti TypeScript." Ketika Anda mencobanya, bagaimana hal itu membuat Anda melihat C # dan .NET? Apakah Anda menemukan sesuatu di sana yang ingin Anda lihat di C #?- Pertanyaan bagus. C # mengambil banyak hal dari bahasa lain. Salah satunya yang ia ambil banyak adalah Python. Dan saya menyukainya. Saya belum menulis dalam Python selama bertahun-tahun, tetapi saya pikir ini adalah bahasa yang dirancang dengan sangat baik. Saya sangat menghargai blok enumerator yang dipinjam C # dari Python. Dan Python adalah salah satu yang pertama di mana aliran Async muncul, jadi kita dapat mengatakan bahwa C # mengambilnya dari sana.
Dalam berbagai bahasa saya suka hal yang berbeda. Saya umumnya lebih suka mengetik statis, jadi saya belum menggunakan Python belakangan ini, dan untuk alasan yang sama saya menggunakan TypeScript daripada JavaScript. JavaScript memiliki kelebihannya hanya karena one-threading-nya. Misalnya, jika Anda melihat relevansi Ekstensi Reaktif, Anda akan melihat bahwa dalam .NET ini tidak diterima secara khusus. Dan dalam JavaScript, Anda dapat melihat Rx di mana-mana.
- Beberapa pertanyaan terakhir adalah tentang laporan Anda tentang DotNext. Anda akan berbicara tentang aliran Asynchronous di sana - dapatkah Anda memberi tahu pengembang NET secara singkat tentang apa yang diharapkan dan mengapa laporan ini bermanfaat bagi mereka?- Jadi, laporan saya tentang aliran asinkron: mengapa mereka ditambahkan ke bahasa, dan apa skenario utama untuk penggunaannya. Saya mendekati ini dengan sangat pragmatis, dan tidak masuk ke semua detail tentang apa yang terjadi di bawah tenda. , async streams, , , async streams, .
— . — DotNext?— , , , . , : , .
, , , . - async streams , , , . , DotNext.
DotNext 2019 Moscow 6-7 . , — .