Perbandingan dua type checker Python baru berbasis Rust: Pyrefly dan Ty

• Baru-baru ini, dua type checker Python berbasis Rust, Pyrefly dari Meta dan Ty dari Astral, diperkenalkan dan menunjukkan performa yang luar biasa serta paradigma typing baru dibanding mypy dan pyright yang sudah ada
• Pyrefly berfokus pada inferensi tipe yang agresif dan keterbukaan open source, sementara Ty memperkenalkan prinsip “gradual guarantee” dengan fokus meminimalkan terjadinya type error
• Keduanya masih berada di versi alfa awal, tetapi hasil benchmark di berbagai proyek menunjukkan bahwa Ty rata-rata mencatat kecepatan eksekusi yang lebih tinggi
• Dalam analisis inkremental, Pyrefly menyediakan inkrementalisasi tingkat modul, sedangkan Ty menawarkan inkrementalisasi halus hingga target fungsi, sehingga penggunaan dan strukturnya berbeda
• Ty menghadirkan sistem tipe inovatif seperti intersection type dan negation type, serta memberikan pesan error yang lebih intuitif dan jelas

---

Pengenalan Pyrefly dan Ty

• Pyrefly dan Ty adalah type checker Python yang dikembangkan dengan Rust
• Pyrefly dikembangkan oleh Meta (dulu Facebook) dan menggantikan Pyre yang berbasis OCaml
• Ty dikembangkan oleh Astral, yang dikenal lewat alat Python seperti uv dan ruff
• Kedua proyek sama-sama dirilis sebagai open source, tetapi masih berada pada tahap alfa sebelum rilis resmi
• Kedua tim memperkenalkan visi, tujuan, dan pendekatan masing-masing di PyCon 2025 Typing Summit

Kesamaan

• Keduanya dikembangkan dengan Rust dan mendukung analisis inkremental (Incremental Checking)
• Keduanya menggunakan ruff untuk parsing AST kode Python
• Konektivitas dengan lingkungan pengembangan juga sangat baik, termasuk pemeriksaan tipe lewat command line dan integrasi LSP/IDE

Perbedaan 1: Kecepatan

Benchmark PyTorch

• Ty sekitar 2~3 kali lebih cepat daripada Pyrefly, dan keduanya 10~20 kali lebih cepat daripada mypy dan pyright yang ada saat ini
• Pyrefly menargetkan peningkatan performa 35 kali dibanding Pyre, dan 14 kali dibanding mypy/pyright
• Ty dirancang dengan target performa satu hingga dua orde magnitudo lebih cepat daripada generasi type checker saat ini

Benchmark Django

• Ty adalah yang tercepat, diikuti oleh Pyrefly
• Pyright menunjukkan hasil yang jauh lebih lambat

Benchmark repositori mypy

• Hasilnya serupa: Ty adalah yang tercepat, dan Pyrefly menyusul dengan selisih tipis
• mypy dan pyright mencatat waktu eksekusi yang jauh lebih lambat

Perbedaan 2: Tujuan typing

Pyrefly

• Mengejar strategi menginferensikan tipe semaksimal mungkin untuk menangkap error bahkan saat kode tidak memiliki tipe eksplisit
• Mengarah pada stabilitas kode yang maksimal lewat inferensi tipe yang lebih agresif

Ty

• Menerapkan prinsip Gradual guarantee
• Dirancang agar tidak menimbulkan type error saat tipe eksplisit dihapus dari kode yang sebelumnya berjalan dengan benar
• Tidak memicu error meski tanpa type annotation, dan hanya meminta annotation tambahan bila benar-benar diperlukan
• Contoh: meski nilai di-assign ke field tanpa tipe eksplisit, hal itu tidak memicu type error, melainkan diperlakukan sebagai Unknown | None dan sejenisnya

Perbedaan 3: Metode analisis inkremental

• Pyrefly: hanya menganalisis ulang file (modul) yang berubah dan modul yang bergantung padanya (inkrementalisasi tingkat modul)
• Ty: memanfaatkan framework Salsa dari Rust untuk inkrementalisasi yang lebih rinci hingga tingkat fungsi
• Pendekatan tingkat modul dinilai sudah cukup cepat, sedangkan tingkat fungsi bisa membuat codebase lebih kompleks (perbedaan strategi masing-masing alat)

Perbedaan 4: Fitur (sistem tipe dan dukungan)

Kelebihan Pyrefly

• Inferensi tipe implisit sangat kuat
• Bahkan tanpa tipe eksplisit, ia dapat menganalisis tipe kompleks seperti nilai balik fungsi, dictionary, dan list untuk menangkap error
• Dirancang dengan fokus pada masalah typing yang kompleks seperti generic, overload, dan wildcard import
• Akurasi inferensi generic lebih tinggi daripada Ty

Keunikan Ty

• Karena “gradual guarantee”, perubahan tipe tetap dibiarkan secara fleksibel saat tipe eksplisit tidak ada
• Mendukung sistem tipe inovatif seperti intersection type dan negation type
• Pesan error dirancang sangat jelas dan intuitif
• Memungkinkan assignment berbagai tipe ke list dan sejenisnya secara bebas, serta memperkenalkan nilai tipe Unknown secara sistematis

Keterbatasan/status alfa

• Kedua produk masih berada pada tahap alfa, sehingga inferensi tipe atau sebagian fitur masih belum matang
• Misalnya, beberapa hasil seperti inferensi tipe list di Ty masih kurang sempurna

Perbandingan fitur lebih rinci

Inferensi tipe implisit

• Pyrefly secara aktif menginferensikan return type dan tipe objek koleksi, lalu menampilkan revealed type dan error dengan jelas
• Ty akan mengembalikan Unknown atau @Todo jika inferensinya tidak memadai

Generic

• Baik Pyrefly maupun Ty sama-sama menangani masalah generic umum dengan baik
• Pyrefly unggul dalam interpretasi tipe instance yang dibuat tanpa type parameter
• Kedua checker masih menunjukkan kelemahan dibanding mypy dan pyright dalam masalah covariance/contravariance

Pesan error

• Ty berfokus pada pesan error yang ringkas dan mudah dibaca
• Dibanding Pyrefly, mypy, dan pyright, pesan yang diberikan lebih mudah dipahami sekilas

Intersection/negation type

• Hanya Ty yang mendukung intersection type (&) dan negation type (~), sehingga bisa menangani operasi tipe kompleks seperti berikut

  • Contoh: pada tipe WithX | Other, ketika ada atribut x, Ty otomatis melakukan percabangan ke WithX
  • Contoh: jika bukan subclass tertentu, tipe diinterpretasikan sebagai MyClass & ~MySubclass

• Intersection dan negation type seperti ini merupakan fitur yang sangat maju dalam teori tipe

Contoh lanjutan lainnya

• Ty juga dapat dimanfaatkan melalui sistem tipenya untuk operasi kompleks seperti persamaan Diofantin
• Pengujian ditulis dalam dokumen Markdown (rujukan: resource mdtest milik Astral ruff)

Kesimpulan dan prospek

• Ekosistem Python kini kedatangan type checker baru yang sangat cepat dan membawa pendekatan baru
• Ty menjadikan stabilitas tipe bertahap sebagai strategi utamanya, sementara Pyrefly berfokus pada inferensi tipe aktif
• Karena keduanya masih di tahap awal, masih ada banyak ruang agar fitur-fitur mereka saling mendekat atau terus berevolusi
• Keduanya bisa dicoba lewat situs resmi, dan juga menyediakan plugin untuk editor utama seperti VSCode dan Cursor
• Ada pula rumor bahwa Google akan meng-open-source-kan type checker berbasis Go, sehingga bidang analisis tipe Python diperkirakan akan menjadi semakin kaya

Pemanfaatan/Referensi

• Pyrefly: pyrefly.org/sandbox
• Ty: play.ty.dev
• Ty dari Astral memanfaatkan pengujian berbasis Markdown (jalur detail dapat dilihat pada mdtest di repo ruff)
• Dokumentasi resmi, plugin editor, dan perintah instalasi paket juga semuanya tersedia

[q8840]

Sepertinya ty akan selalu menganggapnya unknown jika tipe nilai kembalian tidak ditulis pada fungsi yang digunakan, dan baru memeriksanya setelah disimpan
pyrefly bisa menginferensikannya meski tidak ditulis, dan juga memeriksanya saat sedang mengetik

[GN⁺]

Opini Hacker News

• Sebagai pengembang ty, ia menekankan bahwa dirinya senang melihat ty dan pyrefly makin mendapat perhatian, tetapi sekali lagi menegaskan bahwa kedua proyek itu belum benar-benar selesai. Ia juga melihat contoh-contoh yang muncul karena fitur belum diimplementasikan, dan meminta pemahaman bahwa ketika sesuatu terasa “aneh”, bisa jadi bagian itu memang belum dikembangkan. Perlu dipahami juga bahwa Python adalah bahasa yang sangat besar dan beragam.

  • Ada pendapat bahwa gaya pengujian markdown milik ty sangat disukai, karena tes sekaligus berfungsi sebagai dokumentasi, yang dianggap ide luar biasa. Ia penasaran apakah pendekatan ini terinspirasi dari contoh kode terdokumentasi di Rust.

  • Ada kesan bahwa penandaan bagian yang mengungkapkan tipe dengan @TODO terasa lucu, tetapi setelah dipikir-pikir justru cukup cerdas dan berguna.

  • Dari sudut pandang orang yang berpengalaman dengan TypeScript, berbagai upaya seperti inferensi tipe, type narrowing, dan perbedaan perilaku antar type checker Python terasa menarik. Tetap saja, type checker yang cepat dan andal masih sangat dibutuhkan, dan Python terasa sangat tertinggal dalam hal ini. Ia berpandangan bahwa type checker seharusnya meningkatkan produktivitas dan keandalan kode, dan karena itu mendukung proyek-proyek seperti ini.

  • Dari sudut pandang pengembang Rust, ada pertanyaan tentang “bahasa skrip untuk Rust”: apakah ada komunitas atau jaringan riset yang membahas bahasa yang cocok dengan sintaks Rust, bisa mengimpor tipe Rust secara native, serta dapat dikompilasi cepat/hot reload. Ia juga meminta pendapat apakah Python, meski sintaksnya berbeda, bisa mengisi peran itu. Tautan terkait dilampirkan https://news.ycombinator.com/item?id=44050222

• Pendapat dari sudut pandang luar yang tidak terlalu berpengalaman dengan Python: jika tertarik memanfaatkan type hints, disarankan membaca posting Reddit https://www.reddit.com/r/Python/comments/10zdidm/why_type_hinting_sucks/. Meski tulisan itu tidak boleh dianggap terlalu serius, ia menekankan bahwa sebaik apa pun alat tipe yang ada, “praktik yang baik” tetap harus didahulukan. Contohnya, agar penggunaan yang konsisten dan type checking yang ketat bisa diterapkan pada codebase besar seperti di Django atau Meta, pengembang harus dibuat mengikuti kebiasaan yang direkomendasikan. Python, seperti C++, punya terlalu banyak fitur dan runtime yang permisif, sehingga pada akhirnya hanya sebagian kecil yang bisa dipakai secara terbatas agar mudah dikelola. Namun, bagian terbatas itu bisa berbeda-beda tergantung orang dan tujuan. Ia juga membandingkannya dengan kasus saat pengembang Rust berbenturan dengan pengembang kernel Linux karena sistem tipe yang lebih ketat.

  • Pada komentar teratas di posting Reddit itu, ada kecenderungan menepis diskusi dengan “tinggal pakai Any, jadi tidak ada gunanya membahas ini”. Ia menegaskan bahwa dalam kasus nyata, deklarasi tipe yang lebih jelas dapat mencegah kesalahan lebih awal terhadap perubahan fungsi pustaka di masa depan atau nilai input yang tidak terduga. Menurutnya, agar kode Python tetap mudah dipelihara dan andal, type checking itu wajib.

  • Kesimpulannya, daripada menghabiskan terlalu banyak waktu dan tenaga untuk type checking Python, mungkin lebih baik pindah ke bahasa static typing yang lebih cocok, lalu hanya memakai Python pada bagian yang perlu lewat lapisan interop. Ini memang tidak selalu memungkinkan, tetapi ada kegelisahan bahwa terlalu banyak waktu terbuang untuk memaksa Python menyesuaikan diri.

  • Ada kritik bahwa fitur Python yang kuat namun kompleks, seperti meta class, descriptor, penggunaan __call__, object.__new__, name mangling, dan self.__dict__, mengandung terlalu banyak “sihir” sehingga sangat menurunkan keterbacaan kode. Secara pribadi, ia menyatakan tidak akan memakai fitur-fitur itu.

  • Ada pertanyaan dari mana datangnya kebiasaan memberi opini tanpa benar-benar memakai bahasa tersebut. Pengembang Python memahami bahasanya secara mendalam lewat penggunaan nyata, sehingga terasa aneh ketika non-pengguna mengkritik bahasa itu dengan dasar eksternal. Ia juga menyoroti suasana perdebatan yang bertumpu pada contrived example.

  • Dari pengalaman menggunakan Python selama bertahun-tahun, ia menegaskan bahwa kesalahan terbesar adalah tidak memakai type hints dan type checker sama sekali.

• Ada ketertarikan pada “gradual guarantee” milik ty, yaitu bahwa menghapus satu anotasi tipe tidak seharusnya memunculkan type error. Ini dianggap pendekatan yang paling cocok untuk Python yang penuh kode dinamis.

  • Ada ingatan bahwa gradual typing membentuk situasi di mana any dapat muncul di mana saja tanpa memicu peringatan, sehingga bahkan kode penting pun tidak benar-benar mendapat jaminan type safety dan akibatnya kurang terlindungi. Dari pengalaman memakai mypy, hal ini dianggap fatal, dan perlu ada fitur deklarasi seperti “file ini diperiksa sepenuhnya secara statis”. Menurutnya, tipe yang “gradual” justru hampir seperti anti-pattern, dan mungkin istilah “soft typing” lebih tepat.

  • Ada pandangan bahwa pada codebase yang sudah ada, selain gradual typing memang tidak ada cara lain. Berdasarkan pengalaman menerapkan type hints dengan mypy ke beberapa codebase Python warisan, pendekatan “opt-in per modul” adalah yang paling masuk akal. Jika pyrefly tidak mendukung ini, kegunaannya akan terbatas. Namun, dari sudut pandang code generation oleh LLM, type checker yang sangat cepat dan ketat tetap bermanfaat.

  • Ini dianggap mirip dengan adopsi awal TypeScript, yang menekankan onboarding halus untuk proyek besar yang sudah ada. Secara bertahap, opsi noImplicitAny atau strict dapat diaktifkan per modul hingga akhirnya berubah menjadi lingkungan verifikasi tipe yang kuat.

  • Bahkan sebagai programmer Rust, ia merasa “gradual guarantee” adalah pendekatan yang paling masuk akal.

  • Secara pribadi, dukungan untuk gradual typing tidak terlalu menarik baginya. Sejak awal sistem tipe dinamis Python sudah terasa rapuh, jadi setengah tujuan menambahkan anotasi tipe adalah untuk mengendalikan potensi salah perilaku itu. Ia berharap opsi seperti no-implicit-any atau mode strict wajib tersedia.

• Tooling dari Astral memberi energi segar ke ekosistem Python, tetapi memunculkan pertanyaan tentang “pandangan jangka panjang”: apakah nanti akan diintegrasikan langsung ke Python? Hilang dalam 5 tahun? Menjadi rug pull berbasis langganan?

  • Ada pandangan bahwa lewat business source license, besar kemungkinan deployment produksi yang memakai tool Astral nantinya akan diarahkan agar wajib mengambil langganan perusahaan atau semacamnya. Produk saat ini memang belum tepat untuk tujuan itu, tetapi dari sudut pandang investasi venture capital, model serupa tampaknya mungkin ditempuh.

  • Dalam pengumuman resmi, Astral memang menyatakan akan menjual berbagai layanan di atas tool-toolnya. Tautan referensi: https://astral.sh/blog/announcing-astral-the-company-behind-ruff

  • Sebenarnya kekhawatiran seperti ini bukan hanya berlaku untuk Astral, melainkan untuk semua proyek. Secara khusus, tooling dari Facebook juga diperingatkan berisiko menjadi tidak terurus seiring waktu. Pada akhirnya, pengguna memang harus selalu menanggung risiko sendiri.

  • Ada kutipan pendapat pengguna Reddit bahwa model dasar VC pada akhirnya berharap diakuisisi oleh FAANG atau dibesarkan cukup mengancam untuk mengejar “acqui-hire”. Untuk Astral, skenario seperti akuisisi dan penyerapan talenta juga mungkin terjadi.

  • Ada rumor bahwa Astral belakangan ini juga sedang menyiapkan tool khusus perusahaan besar, misalnya hosted private package registry.

• Pada contoh my_list = [1, 2, 3], mypy, pyrefly, dan pyright menganggap my_list.append("foo") sebagai type error, tetapi hanya ty yang mengizinkannya tanpa deklarasi tambahan. Ini memicu argumen bahwa dalam praktik kerja, daftar bertipe tunggal hampir selalu menjadi kebiasaan, jadi type checker seharusnya berangkat dari asumsi itu. Ada kritik keras bahwa hanya karena Python mengizinkannya, bukan berarti verifikasi tipe boleh menjadi longgar. Ada juga yang menilai ini seperti kebijakan yang dioptimalkan untuk kode pemula.

  • Sebagai pengembang ty, ada klarifikasi bahwa “inferensi tipe list literal memang belum selesai”. Saat ini ty hanya menggunakan list[Unknown], dan karena Unknown adalah tipe gradual yang mirip Any, semua append jadi diizinkan. Ke depan direncanakan inferensi yang lebih presisi, dan dilampirkan tautan isu diskusi terkait https://github.com/astral-sh/ty/issues/168

  • Ada pendapat bahwa ini bukan optimasi untuk pemula, melainkan sesuatu yang tak terhindarkan demi kompatibilitas dengan kode warisan. Untuk memperkenalkan type checker ke codebase besar yang belum bertipe, beban adopsi akan lebih ringan jika kode lama bisa tetap berjalan semirip mungkin dengan kondisi semula.

  • Ada sanggahan bahwa “mengabaikan hal yang diizinkan Python lalu membuat tooling berdasarkan opini pribadi” bukan pendekatan yang meyakinkan.

  • Ada pandangan bahwa pendekatan pyrefly bermasalah karena “sulit diadopsi penuh pada codebase besar yang tidak bertipe”. Karena kode harus diperbaiki satu per satu, ini tidak mudah jika organisasi tidak punya kesepahaman untuk melakukan pekerjaan tersebut. Di tempat seperti Meta yang bisa memaksakan aturan secara internal, itu mungkin cocok, tetapi untuk adopsi bertahap, pendekatan yang lebih permisif seperti ty terasa lebih realistis. Meski begitu, secara pribadi ia lebih menyukai alat yang memberi peringatan pada tipe campuran.

  • Ada pendapat bahwa “jika itu adalah kode Python yang valid untuk dijalankan, maka semestinya tidak menjadi type error kecuali tipenya dibatasi secara eksplisit”. Jika menginginkan subset statis yang lebih ketat, pengguna bisa langsung menambahkan anotasi tipe.

• Ada pendapat dari orang yang berpengalaman bahwa pendekatan Pyrefly mengejar inferensi tipe yang lebih kuat, sehingga untuk kode besar yang benar-benar type-safe, anotasi yang dibutuhkan jauh lebih sedikit. Meski awal adopsinya berat, dalam jangka panjang lebih efisien. Sementara itu, ty pada dasarnya seperti keadaan saat opsi noImplicitAny dimatikan.

• Ada harapan akan type checker yang benar-benar mendukung integrasi notebook (live coding), karena pemeriksaan statis yang bisa menangkap kesalahan sebelum sel panjang dijalankan akan sangat efisien.

  • Ada pertanyaan tentang pengalaman memakai Jupyter notebook di VSCode, dengan catatan bahwa penerapan type checker seperti pylance kadang justru mengganggu pada kode eksperimental.

  • Ada rekomendasi untuk pengalaman Language Server di VSCode yang memungkinkan integrasi notebook dan umpan balik langsung saat live coding, karena dinilai bisa menjawab kebutuhan integrasi notebook dan type checking interaktif secara langsung.

• Desain Pyrefly terasa lebih masuk akal secara pribadi karena mirip dengan pendekatan inferensi tipe TypeScript, dan adopsi gradual pada tingkat modul dianggap ideal. Jika sampai ke tingkat fungsi, itu terasa terlalu terperinci dan justru berlebihan. Dari sisi performa juga, tingkat modul dianggap sudah cukup.

• Ada pandangan bahwa meskipun sebuah proyek memiliki banyak aspek dinamis, ia tetap akan lebih memilih inferensi tipe yang lebih kuat seperti Pyrefly, meski ada ketidaknyamanan yang menyertainya.

• Saat ini basedpyright dipakai di IDE dan lingkungan CI, dan secara umum kestabilannya memuaskan, sedangkan mypy kurang disukai karena kadang gagal bahkan untuk pekerjaan tipe yang sederhana.