Pyrefly - Pemeriksa Tipe Baru dan Pengalaman IDE untuk Python

• Pyrefly dari Meta adalah pemeriksa tipe Python sumber terbuka sekaligus ekstensi IDE yang dikembangkan dengan Rust
• Mendukung performa analisis supercepat dan fitur integrasi IDE, serta dikembangkan untuk mengatasi keterbatasan Pyre
• Mengusung inferensi tipe otomatis, dukungan untuk codebase berukuran besar, dan filosofi sumber terbuka sebagai prinsip utama
• Bertujuan meningkatkan sistem tipe di seluruh ekosistem melalui kolaborasi dan kontribusi dengan komunitas Python
• Saat ini telah merilis versi alfa dan secara aktif meminta umpan balik serta kontribusi dari komunitas

---

Pengantar

• Pyrefly adalah proyek sumber terbuka berupa pemeriksa tipe statis Python sekaligus ekstensi IDE yang dikembangkan Meta dengan Rust
• Mendukung deteksi error lebih awal dengan memverifikasi konsistensi tipe sebelum kode dijalankan
• Dapat digunakan baik melalui integrasi IDE maupun CLI, sehingga menyediakan alur kerja yang fleksibel
• Menargetkan kontribusi pada pengembangan sistem tipe Python dan berbagai library melalui kolaborasi dengan komunitas open source

Latar belakang pengembangan Pyrefly

• Pada 2017, Meta mengembangkan pemeriksa tipe baru (yang kemudian menjadi Pyre) untuk codebase Python Instagram berskala besar
• Pyre dikembangkan dengan OCaml demi performa, sambil merujuk pada desain yang kuat dari Hack, Flow, dan lainnya
• Seiring waktu, muncul keterbatasan ketika kebutuhan akan perkembangan sistem tipe dan integrasi IDE makin besar
• Meta juga menggunakan alat komunitas seperti Pyright, tetapi karena ada batasan dalam memenuhi kebutuhan seperti penelusuran kode skala besar dan ekspor tipe, mereka mencoba mengembangkan Pyrefly

Prinsip utama Pyrefly

• 1. Performa

  • Pengembang membutuhkan pemeriksaan tipe cepat pada setiap penekanan tombol segera setelah menulis kode
  • Pyrefly menggunakan arsitektur implementasi Rust berperforma tinggi yang mampu memeriksa 1,8 juta baris per detik bahkan pada codebase yang sangat besar

• 2. Desain berpusat pada IDE

  • Abstraksi dirancang sejak awal agar IDE dan CLI dapat mempertahankan sudut pandang yang sama
  • Pada Pyre hal ini merupakan perbaikan belakangan, tetapi pada Pyrefly konsistensi ditekankan sejak tahap desain

• 3. Inferensi

  • Mendukung inferensi tipe otomatis bahkan untuk kode Python tanpa anotasi dan tanpa tipe yang dinyatakan secara eksplisit
  • Menampilkan tipe nilai kembalian dan variabel lokal di IDE, dan untuk membantu penulisan kode yang lebih baik, tipe hasil inferensi dapat disisipkan otomatis dengan klik ganda

• 4. Sumber terbuka

  • Pyrefly dirilis di GitHub dengan lisensi MIT, dan menyambut PR komunitas serta laporan issue
  • Berupaya menjalin komunikasi aktif melalui kanal Discord sambil terhubung dengan ekosistem Python dan library utama Meta seperti PyTorch

Masa depan Pyrefly

• Aktif bergerak dengan tujuan meningkatkan bahasa Python dan pengalaman pengembang bersama komunitas
• Sejak awal pengembangan Pyre, Meta terus membuka kode sumber dan berkontribusi ke PEP; melalui Pyrefly, mereka juga berencana memaksimalkan manfaat penggunaan tipe bagi berbagai pengembang, library, dan pemula
• Berdasarkan pengalaman dan hasil pemanfaatan tipe di bahasa dinamis, Meta berencana membagikan berbagai pengalaman dan mendorong peningkatan kualitas tipe di ekosistem
• Saat ini Pyrefly masih versi alfa, tetapi menargetkan peluncuran resmi pada musim panas ini sambil terus melakukan perbaikan bug dan penambahan fitur
• Umpan balik komunitas sangat penting, dan mereka secara aktif meminta laporan issue serta permintaan perbaikan setelah menggunakan Pyrefly

Panduan penggunaan versi alfa Pyrefly dan komunitas

• Proses pengembangan Pyrefly dan detail teknisnya telah dibagikan melalui Meta Tech Podcast dan presentasi PyCon US
• Kabar tambahan disediakan melalui berbagai kanal seperti situs terkait Meta Open Source, YouTube, Facebook, Threads, X, dan LinkedIn

[GN⁺]

Komentar Hacker News

• Merasa agak khawatir atas nama "Python Language Tooling Team" di Meta; popularitas uv sangat tinggi sehingga ada firasat ty akan menang di ranah ini. Jika salah langkah, bisa muncul situasi seperti Atom atau Flow, ketika tim internal kalah dari open source eksternal lalu dari atas muncul suasana "apa tim ini benar-benar masih perlu? kenapa tidak dijadikan open source saja?". Rasanya ini hal yang perlu diperhatikan oleh manajemen (Aaron Pollack?).
  • Kevin menyapa dengan ramah dan menyebut bahwa ia pernah bekerja di Flow, dan sekarang aktif di tim Pyrefly. Ia menjelaskan bahwa kali ini mereka mengambil pendekatan yang berbeda dari Flow dan secara jelas menempatkan open source serta pembangunan komunitas sebagai prioritas. Ia juga membagikan pandangannya bahwa meski akhir-akhir ini ada banyak volatilitas terkait investasi infrastruktur perusahaan, ia percaya bahwa saat ini mereka berada di titik awal perjalanan yang benar, lalu menyampaikan apresiasi atas dukungannya.
  • Ada pendapat bahwa Meta sangat mementingkan kontrol atas proyek open source, khususnya alat pengembang. Diceritakan anekdot lama bahwa setelah maintainer git menyoroti penggunaan monorepo dan menolak perbaikan untuk di-upstream, mereka beralih ke mercurial, dan pihak mercurial dengan senang hati menerima kontribusi. Karena perubahan pada alat internal berlangsung sangat cepat, memiliki sendiri proyek tersebut dianggap masuk akal.
  • Ada komentar bahwa dari semua hal yang keluar dari Facebook, JSX adalah yang paling disukai (mungkin satu-satunya bagian yang dianggap bagus).
• Seseorang memperkenalkan diri bahwa ia bekerja di tim Pyrefly di Meta, mengatakan bahwa banyak pertanyaan sudah tercakup di FAQ dan memberikan tautan rujukan, sambil dengan ramah menyatakan siap menjawab pertanyaan tambahan dan berterima kasih atas ketertarikannya.
• Ada pengamatan bahwa belakangan ini muncul tiga type checker Python yang ditulis dengan Rust (Microsoft, Facebook, Astral), sementara mypy yang sudah ada juga masih tetap bertahan.
  • Ada koreksi bahwa type checker milik Microsoft, Pyright, berbasis Typescript, namun menurut pengalaman pribadi tetap lebih cepat daripada mypy.
  • Ada pertanyaan apakah semuanya adalah static type checker, dengan komentar bahwa tidak ada yang untuk runtime.
• Disebutkan bahwa ini memang pengumuman resmi, tetapi Pyrefly sebenarnya sudah dibahas beberapa minggu lalu. Saat ini dirilis dalam tahap alpha, dan dikutip pernyataan resmi tim bahwa fokus mereka sekarang adalah perbaikan bug dan pengembangan fitur, dengan target melepas label alpha pada musim panas.
• Ada komentar bahwa kode Rust yang ditulis di sini sangat mudah dipahami, tetapi juga kekhawatiran bahwa alat Python belakangan terus ditulis dengan Rust sehingga memunculkan lagi masalah N bahasa, serta harapan agar Mojo bisa melakukan sesuatu di sini.
  • Dijelaskan bahwa dalam ekosistem Python, alur yang wajar adalah memakai Python untuk hal-hal yang bisa ditangani Python, dan memakai bahasa seperti Rust atau C untuk area yang membutuhkan performa tinggi. Pada akhirnya N=3 (Python, Rust, C), meskipun ada harapan agar C perlahan menghilang dari pemrograman aplikasi dalam jangka panjang. Namun kenyataannya itu akan memakan waktu lama, dan malah bisa jadi Python sendiri yang menjadi legacy.
• Senang melihat ada panduan penggunaan untuk integrasi dengan Vim/Neovim, disertai tautan terkait.
• Ada yang mempertanyakan mengapa fakta bahwa ini ditulis dengan Rust disebut-sebut sebagai keunggulan besar. Kebanyakan orang tidak menjalankan type checker pada sistem embedded atau layanan mission-critical, jadi rasanya seperti mendengar "ditulis dengan Erlang". Untuk kode yang performanya tidak terlalu penting, menulisnya dalam Python justru memungkinkan lebih banyak partisipasi dan perluasan komunitas, sehingga muncul pertanyaan mengapa begitu terpaku pada Rust.
  • Ada yang berbagi pengalaman menggunakan Rust: dari sisi pengguna, kelebihannya adalah kecepatan dan keamanan; dari sisi pengembang, kontribusi terasa lebih mudah. Daya tarik Astral juga dianggap terletak pada membawa alat berbasis Rust seperti ini ke Python. Meskipun ia lebih memahami Python daripada Rust, ia merasa berkontribusi pada proyek Rust justru lebih mudah. Ada pandangan bahwa porting alat berkualitas Rust ke Python adalah tujuan keseluruhannya.
  • Ada yang berpendapat bahwa LSP (Language Server Protocol) adalah kode yang sangat mementingkan performa karena langsung memengaruhi responsivitas IDE. Rust sangat efisien baik dalam CPU maupun memori. Kalau ditulis dalam OCaml, Reason, Haskell, dan semacamnya, kecepatan atau efisiensinya mungkin tetap cukup, tetapi kolam kontributornya akan jauh lebih terbatas.
  • Ada komentar bahwa cukup memuaskan karena cukup mencari "[deskripsi alat] rust" untuk dengan mudah menemukan perangkat lunak yang cepat. Sekitar 95% alat yang dipakainya ditulis dengan Rust dan sebagian besar memuaskan.
  • Ada yang mengatakan Rust dipakai seperti singkatan untuk "terasa cepat secara nyata". Ditekankan juga bahwa open source Rust tetap bisa direview.
  • Dijelaskan bahwa type checker yang ditulis dalam Python memang kurang dalam hal performa. Contohnya, linter seperti Pylint yang dibuat dengan Python melakukan pemeriksaan satu per satu per baris kode dan bisa memakan waktu lebih dari 30 detik, sehingga ini memang area yang sensitif terhadap performa.
• Ada rasa penasaran soal transisi dari Pyre ke Pyrefly dan penulisan ulang total ke Rust, serta ingin tahu manfaat atau motivasi spesifik di balik peralihan dari bahasa yang kurang dikenal ke Rust yang sedang tren.
  • Dijawab bahwa pertanyaan ini dibahas dalam FAQ mereka, dan disampaikan bahwa jika nanti pengalaman sudah lebih banyak, mereka ingin membahasnya juga dalam sebuah posting blog panjang, sambil memberikan tautan.
• Ada pendapat bahwa ini terasa seperti proyek yang mencoba menyelesaikan terlalu banyak hal sekaligus.
• Ada opini bahwa begitu melihat VS Code, minat langsung hilang. Ia tidak paham mengapa orang menganggap VS Code cocok sebagai IDE Python, padahal ada IDE sungguhan seperti PyCharm.
  • Ada tanggapan bahwa pyrefly tidak hanya terikat pada vscode, dan diminta agar lebih mempertimbangkan bahwa orang punya preferensi yang berbeda-beda. pycharm juga tidak otomatis lebih baik. Ia pribadi merasa pengembangan jarak jauh di vscode sangat nyaman, dan tidak merasa perlu menulis di internet bahwa pycharm buruk.