Komunitas Python sedang aktif mendiskusikan potensi pergeseran dari pola async/await menuju virtual threads, yang dipicu oleh frustrasi yang meningkat terhadap kompleksitas model concurrency saat ini. Perdebatan ini menyoroti pertanyaan fundamental tentang bagaimana Python seharusnya menangani pemrograman concurrent di masa depan.
Masalah Function Coloring
Salah satu isu paling signifikan yang mendorong diskusi ini adalah apa yang developer sebut sebagai function coloring - keharusaan untuk menandai fungsi sebagai async dan menggunakan kata kunci await di seluruh codebase. Hal ini menciptakan pemisahan antara kode synchronous dan asynchronous yang tidak bisa berinteraksi dengan mudah. Banyak developer membandingkan ini dengan aspect-oriented programming dari tahun 1990-an, yang menunjukkan bahwa ini menambah kompleksitas compiler tanpa memberikan manfaat yang proporsional.
Komunitas telah mencatat bahwa async/await memang mengekspos lebih banyak orang pada konsep pemrograman concurrent, tetapi dengan biaya memerlukan mesin internal yang kompleks yang bocor ke dalam kode user. Kompleksitas ini menjadi lebih bermasalah dengan perubahan free-threading terbaru Python, yang memperkenalkan masalah threading bersamaan dengan kompleksitas async.
Istilah Teknis Utama
- Function Coloring: Persyaratan untuk menandai fungsi sebagai async/await, menciptakan jalur kode sync/async yang tidak kompatibel
- Structured Concurrency: Model pemrograman di mana tugas anak tidak dapat bertahan lebih lama dari tugas induknya
- Virtual Threads: Thread ringan yang dikelola oleh runtime daripada sistem operasi
- Stackful vs Stackless Coroutines: Pendekatan berbeda untuk menyimpan status eksekusi selama pergantian tugas
- Free-threading: Fitur terbaru Python yang memungkinkan eksekusi paralel sejati tanpa Global Interpreter Lock ( GIL )
Virtual Threads sebagai Alternatif yang Lebih Sederhana
Virtual threads, mirip dengan goroutines Go atau Project Loom Java, menawarkan pendekatan yang berbeda. Alih-alih memerlukan sintaks khusus, mereka akan memungkinkan pemanggilan fungsi blocking biasa sementara runtime menangani penjadwalan di belakang layar. Ini berarti developer dapat menulis kode sederhana yang terlihat sequential tetapi sebenarnya berjalan secara concurrent.
Model yang diusulkan akan menggunakan structured concurrency melalui thread groups, memastikan bahwa child threads tidak hidup lebih lama dari parent mereka. Hubungan ini membuat aliran informasi lebih jelas daripada thread-local variables tradisional. Namun, mengimplementasikan ini di Python menghadapi tantangan karena aturan scoping bahasa dan kurangnya deklarasi variabel.
Pertimbangan Performa dan Memori
Kritikus menunjuk pada penelitian yang menunjukkan bahwa stackless coroutines (model async/await saat ini) lebih efisien memori dan memiliki biaya switching yang lebih rendah daripada alternatif stackful seperti virtual threads. Namun, anggota komunitas berargumen bahwa perbedaan performa ini dapat diabaikan dalam konteks Python, di mana overhead interpreter mendominasi.
Tidak ada alasan nyata bagi python untuk memilih model async/await.
Perdebatan ini meluas melampaui performa murni ke produktivitas developer. Beberapa berargumen bahwa solusi sederhana yang suboptimal bisa lebih cepat dalam total waktu pengembangan, meskipun lebih lambat saat runtime.
Perbandingan Model Concurrency
| Pendekatan | Kompleksitas Sintaks | Penggunaan Memori | Pengalaman Developer | Performa |
|---|---|---|---|---|
| Async/Await | Tinggi (function coloring) | Rendah | Kompleks | Dioptimalkan |
| Virtual Threads | Rendah (fungsi reguler) | Sedang | Sederhana | Cukup baik |
| Gevent | Rendah (monkey patching) | Sedang | Sederhana | Baik |
| Traditional Threads | Rendah | Tinggi | Kompleks (locks) | Bervariasi |
Tantangan Library di Dunia Nyata
Diskusi ini mengungkap masalah praktis dengan library async saat ini. Masalah dengan penanganan cancellation di library populer seperti yang menangani file I/O dapat menyebabkan deadlock ketika digunakan dengan pola structured concurrency. Masalah ini berasal dari pencampuran kode async dengan thread pools, menciptakan situasi di mana cancellation yang tepat menjadi tidak mungkin.
Pendekatan Alternatif yang Mendapat Perhatian
Beberapa developer menyebutkan pengalaman sukses dengan gevent, yang menggunakan monkey patching untuk menyediakan cooperative multitasking tanpa function coloring. Yang lain menunjuk pada bahasa seperti Elixir sebagai contoh model concurrency yang lebih sederhana yang menghindari komplikasi ini sepenuhnya.
Pendekatan ekosistem Rust juga muncul, di mana developer dapat memilih antara model concurrency yang berbeda daripada terkunci pada satu pendekatan. Fleksibilitas ini memungkinkan proyek untuk memilih alat terbaik untuk kebutuhan spesifik mereka.
Melihat ke Depan
Meskipun virtual threads tidak secara resmi direncanakan untuk Python, diskusi ini mencerminkan ketidakpuasan yang lebih luas dengan pola async saat ini. Komunitas tampak terbagi antara mereka yang ingin mendorong perbaikan async/await dan mereka yang mengadvokasi pergeseran fundamental menuju concurrency berbasis thread.
Perdebatan ini pada akhirnya berpusat pada apakah Python harus memprioritaskan optimisasi performa teoritis atau pengalaman developer dan kesederhanaan kode. Seiring bahasa berkembang dengan fitur seperti free-threading, keputusan arsitektural ini menjadi semakin penting untuk arah masa depan Python.
Reference: From Async/Await to Virtual Threads