[{"data":1,"prerenderedAt":421},["ShallowReactive",2],{"site-header":3,"site-footer-license":42,"article-aplikasimu-lambat-dan-kamu-udah-kepikiran-ganti-bahasa-tunggu-dulu-with-latest":46},{"navigations":4},[5,20,37],{"collection":6,"item":7},"series",{"__typename":6,"title":8,"slug":9,"children_series":10},"Artikel","all",[11,14,17],{"title":12,"slug":13},"Algoritma dan Struktur Data","algoritma-struktur-data",{"title":15,"slug":16},"Konsep Dasar Pemrograman","konsep-dasar-pemrograman",{"title":18,"slug":19},"Kecerdasan Artifisial","kecerdasan-artifisial",{"collection":6,"item":21},{"__typename":6,"title":22,"slug":23,"children_series":24},"Tutorial","tutorial",[25,28,31,34],{"title":26,"slug":27},"Belajar Java","belajar-java",{"title":29,"slug":30},"Belajar Pascal","belajar-pascal",{"title":32,"slug":33},"Belajar Python","belajar-python",{"title":35,"slug":36},"Belajar Golang","belajar-golang",{"collection":6,"item":38},{"__typename":6,"title":39,"slug":40,"children_series":41},"Lab","lab",[],{"name":43,"url":44,"show":45},"CC BY-SA","https://creativecommons.org/licenses/by-sa/4.0/",false,{"article":47,"renderedBody":376,"renderedTakeaway":377,"latestArticles":378,"toc":395},{"prerequisite":48,"id":49,"title":50,"slug":51,"excerpt":52,"published_at":48,"thumbnail_image":48,"tags":53,"reading_time":60,"takeway":61,"body":62,"authors":63,"series":64},null,"112","Aplikasimu lambat, dan kamu udah kepikiran ganti bahasa. Tunggu dulu","aplikasimu-lambat-dan-kamu-udah-kepikiran-ganti-bahasa-tunggu-dulu","Ada endpoint yang grafiknya spike tiap beberapa menit, dan kepikiran buat pindah dari Go ke Rust? Discord dan Cloudflare beneran melakukannya — tapi cuma setelah kehabisan cara lain dan punya datanya. Yuk, bedah gejala mana yang beneran butuh rewrite, dan mana yang cuma butuh profiling. 🤔",[54,55,56,57,58,59],"backend","performance","golang","rust","system-design","profiling",5,"Pindah bahasa baru punya dasar kalau bottleneck-nya terbukti berasal dari runtime atau dari arsitektur yang nggak bisa berbagi resource, dan komponennya cukup terisolasi untuk digarap sendirian.\n- Yang sebenarnya kamu beli dari pindah bahasa bukan \"kode yang lebih cepat\", tapi hilangnya GC di kasus Discord dan kemampuan berbagi resource lintas thread di kasus Cloudflare.\n- Discord baru pindah ke Rust setelah dua usaha tuning-nya gagal, dan Cloudflare mengevaluasi pilihannya tiap kuartal selama beberapa tahun sebelum akhirnya membangun Pingora.\n- Instagram justru cukup mematikan GC di Python-nya dan langsung jadi 10% lebih efisien, jadi bahasa yang dianggap lambat pun bukan masalah selama dipakai dengan benar.\n- Selama masih ada query, indeks, atau konfigurasi yang belum dibereskan, masalah yang sama cuma pindah ke bahasa baru berikut biaya belajarnya.","Bayangin ada satu *endpoint* yang grafik latency-nya nggak rata. Kebanyakan waktu dia adem, tapi tiba-tiba naik lancip, turun lagi, lalu naik lagi. Kamu mandangin grafik itu sambil ngopi, dan yang muncul di kepala **bukan profiler**. Yang muncul adalah kalimat, \"kayaknya pindah bahasa aja deh.\" 😅\n\nDorongan itu wajar banget, kok. Ada perusahaan besar yang beneran pindah bahasa dan hasilnya bagus. Tapi ada yang jarang kita perhatiin: dua cerita paling terkenal itu **nggak dimulai dari bahasa baru**. Mereka mulai dari angka, dari ngukur sampai kelihatan persis di mana yang mentok. Joel Spolsky pernah bilang bahwa [menulis ulang dari nol adalah \"the single worst strategic mistake that any software company can make\"](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/), dan kita bakal lihat kenapa kalimat itu masih relevan.\n\nYuk kita bedah tiga kasus nyata, plus satu kontra-contoh. Tujuannya bukan bilang pindah bahasa itu salah. Tujuannya biar kamu tahu kapan solusi murah udah habis, dan kapan baru boleh mikir *rewrite*.\n\n## Kenapa *Discord* akhirnya pindah dari Go ke Rust?\n\nYang mereka pindahkan namanya Read States. Tugasnya cuma nyatet channel dan pesan mana yang udah kamu baca. Sederhana, tapi layanan ini dipanggil tiap kali kita connect, tiap kali kirim pesan, dan tiap kali buka pesan. Jadi dia nempel di hampir semua hal yang kita lakuin di sana, lho.\n\nSkalanya gede, nih. Ada [miliaran Read State](https://discord.com/blog/why-discord-is-switching-from-go-to-rust), satu per user per channel. Tiap instance cache memegang jutaan user dan puluhan juta Read State. Per detiknya ada ratusan ribu update cache dan puluhan ribu write *database*.\n\nGejalanya emang aneh tapi konsisten: spike latency dan CPU tiap sekitar 2 menit. Penyebabnya, Go memaksa *GC* jalan minimal tiap 2 menit, terlepas dari seberapa besar *heap*-nya tumbuh. Dari [grafik di blog mereka](https://discord.com/blog/why-discord-is-switching-from-go-to-rust), CPU naik dari sekitar 20% ke 30–40%. *Average response time* naik dari sekitar 0–2 ms ke sekitar 25 ms. Yang p95 melonjak dari sekitar 0–10 ms ke sekitar 300 ms. Catat ya, itu p95, bukan p99, dan semua angka ini hasil baca grafik, jadi sifatnya perkiraan.\n\nNah, bagian pentingnya: mereka nggak langsung pindah. Mereka nyoba tuning dulu, dan dua-duanya gagal. Pertama, mengubah GC percent dari *endpoint*. Hasilnya nggak ngaruh, soalnya alokasi mereka nggak cukup cepat untuk memicu GC lebih sering. Kedua, memperkecil *LRU cache*. Spike-nya memang mengecil, tapi p99-nya naik karena cache jadi lebih sering *miss* dan bebannya pindah ke *database*.\n\nJadi mereka udah ketemu tembok, tuh. Bukan tembok malas, tapi tembok yang diukur dan dicoba dobrak dua kali. Baru setelah itu mereka porting ke Rust, dan kata mereka latency-nya sama bagusnya dengan versi Go, dan **nggak ada spike sama sekali**. Dengan optimasi dasar aja versi Rust sudah mengalahkan versi Go yang di-tuning mati-matian. Setelah diprofil lagi, Rust menang di latency, CPU, dan memori.\n\nBeberapa hari kemudian kapasitas cache dinaikkan ke 8 juta Read State, hal yang nggak mungkin di versi Go karena GC-nya makin lama makin berat. Hasilnya, *average* response time jadi satuan mikrodetik, dan Max @mention jadi satuan milidetik. Tapi lihat catatan kaki mereka sendiri: mereka nggak berpikir kamu harus menulis ulang semuanya di Rust cuma karena bisa.\n\n## Cloudflare: kodenya lebih cepat, atau arsitekturnya?\n\nCerita kedua datang dari Cloudflare, yang mengganti *NGINX* dengan *Pingora*. Menurut [tulisan mereka soal Pingora](https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/), sistem barunya melayani lebih dari 1 triliun *request* per hari. Dia cuma butuh sepertiga CPU dan memori dibanding infrastruktur proxy sebelumnya. Di produksi, hematnya 70% CPU dan 67% memori di beban yang sama. TTFB juga turun 5 ms di median dan 80 ms di p95.\n\nSekarang bagian yang paling sering kelewat. Hemat itu **bukan karena kodenya lebih cepat**, lho. Layanan lama mereka juga udah sub-milidetik. Yang lebih cepat itu cara dia berbagi koneksi. 🤯\n\nMasalahnya ada di arsitektur NGINX, sih. Satu *request* cuma dilayani satu *worker*, yaitu satu proses OS. Load-nya nggak seimbang antar core, dan *connection pool*-nya per *worker*. Akibatnya makin banyak *worker* ditambah, makin jelek rasio *reuse* koneksinya. Ini kayak kalau tiap orang punya galon air sendiri di mejanya. Kamu butuh minum, galon sebelah masih penuh, tapi nggak bisa diambil, jadi kamu beli galon baru lagi. Tambah orang bukan bikin galon yang ada lebih kepakai, malah nambah galon baru terus.\n\nPingora dibangun dengan multithreading, *runtime* async *Tokio*, dan *work stealing*. Mereka juga bikin HTTP *library* sendiri karena *traffic* di internet banyak yang nggak patuh RFC. Hasilnya, koneksi baru yang dibuat per detik tinggal sepertiga. Untuk satu pelanggan besar, rasio *reuse* koneksi naik dari 87,1% ke 99,92%, dan koneksi baru ke origin turun 160x. Terjemahan blog mereka: \"kami menghemat 434 tahun waktu *handshake* setiap hari.\"\n\nAda alasan lain mereka pindah. C nggak *memory safe*, Lua kurang performan dan nggak ada *static typing*, dan komunitas NGINX bergerak lambat. Setelah melayani beberapa ratus triliun *request*, Pingora belum pernah crash karena kode service-nya. Sistem ini lalu [di-open source-kan pada 28 Februari 2024](https://blog.cloudflare.com/pingora-open-source).\n\n## Jadi sebenarnya apa yang kamu beli dengan pindah bahasa?\n\nDua kemenangan tadi datang dari dua mekanisme yang beda. Di *Discord*, yang hilang adalah GC. Di Cloudflare, yang didapat adalah kemampuan berbagi resource lintas *thread*. Itu aja, sih. Bukan \"Rust lebih cepat\" secara magis, tapi ada **satu batasan spesifik** yang akhirnya lenyap.\n\nKalau masalahmu bukan salah satu dari dua itu, ganti bahasa nggak akan mengubah apa pun. Query lambat tetap lambat di Rust. N+1 tetap N+1 di Go. Kamu cuma bakal punya masalah yang sama dengan sintaks yang berbeda, plus biaya belajar yang nggak kecil, lho.\n\nKutipan Knuth sering dipotong jadi slogan. Versi lengkapnya begini: *\"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.\"* Slogan itu sering dipakai buat menghindari ngukur, padahal Knuth justru minta kita tahu kode mana yang masuk 3% itu. Dan satu-satunya cara tahu adalah dengan *profiler*.\n\n## Gimana kalau masalahmu memang GC, tapi bahasanya Python?\n\nDi sini ada kabar yang menenangkan. Kalau masalahmu memang GC, kamu nggak selalu butuh bahasa baru. Pada Januari 2017, [Instagram mematikan GC di Python-nya](https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172) dan langsung jadi 10% lebih efisien. Nggak pindah bahasa, nggak ganti *framework*, **cuma mematikan satu fitur**. 🙌\n\nKonteksnya gini. Instagram jalan dengan *Django* multi-proses, pakai *uWSGI* model *pre-fork*. Satu master mem-*fork* dirinya jadi puluhan *worker* yang melayani *request*. Idealnya, memori yang dibagi antar *worker* itu tetap dibagi.\n\nTapi temuannya lain. *Shared memory* tiap *worker* turun dari sekitar 250 MB ke sekitar 140 MB, kira-kira sepertiga, cuma dalam beberapa detik setelah *worker* lahir. Sebabnya, Python pakai *reference counting*. Setiap kali sebuah objek dibaca, counter-nya ditulis. Tulisan itu memicu *copy-on-write* di kernel, jadi halaman memori yang tadinya dibagi berubah jadi milik masing-masing proses.\n\nCoba pikirin sebentar, deh. Gejala \"GC bikin latency jelek\" muncul di tiga tempat berbeda: di Go (*Discord*), di JVM Cassandra (*Discord* lagi), dan di Python (Instagram). Jawabannya beda-beda. *Discord* pindah bahasa, Instagram cuma ganti konfigurasi. Yang salah bukan bahasanya, tapi keputusan yang diambil di sekitar bahasanya.\n\n## Kadang bottleneck-nya bahkan bukan bahasa\n\nIni kontra-contohnya, dan lagi-lagi dari *Discord*. Pada 2023, mereka pindah dari *Cassandra* ke *ScyllaDB*, dan [177 node jadi 72 node](https://discord.com/blog/how-discord-stores-trillions-of-messages). P99 untuk mengambil pesan historis turun dari 40–125 ms jadi 15 ms. Insert pesan turun dari 5–70 ms jadi 5 ms.\n\nAkar masalah aslinya adalah *hot partition*, konkurensi yang nggak terkendali, dan GC di JVM Cassandra. Yang menyelesaikannya adalah *request coalescing* plus *consistent hash routing* (ditulis di Rust), serta *database* yang bebas GC. Jadi bahkan di cerita \"pindah ke Rust\", sebagian besar kemenangannya datang dari desain dan pilihan komponen yang tepat.\n\nBonusnya, migrator-nya ditulis di Rust dan estimasi migrasinya berubah dari 3 bulan jadi 9 hari. Puncaknya jalan di 3,2 juta pesan per detik. Jadi Rust tetap punya tempat yang jelas, tapi tempatnya sempit dan spesifik.\n\n## Kapan *rewrite* boleh dipertimbangkan?\n\nAlasan Spolsky masuk akal: kode lama itu sudah dipakai, sudah diuji, dan ratusan *bug* sudah ditemukan dan diperbaiki. Menulis ulang berarti membuang semua pengetahuan itu. Dia juga bilang soal performa, \"1% of the work gets you 99% of the bang.\" Kalau 1% itu belum kamu cari, jangan loncat ke 100%.\n\nJadi rewrite itu **keputusan terakhir**, bukan langkah pertama. Ada tiga pertanyaan yang harus kamu punya datanya.\n\n- Udah habis belum usaha yang lebih murah, seperti *query*, indeks, *caching*, N+1, dan *connection pool*? Ingat, Cloudflare mengevaluasi pilihannya tiap kuartal selama beberapa tahun.\n- Bottleneck-nya kebukti berasal dari *runtime* atau arsitektur, bukan dari kode kita sendiri?\n- Komponennya cukup terisolasi? *Discord* cuma memindahkan satu service, dan Cloudflare cuma mengganti layer proxy.\n\nKalau belum bisa jawab ketiganya dengan data, jawabannya sekarang adalah belum. Dan itu jawaban yang sehat, kok, bukan tanda kamu pengecut.\n\n## Kalau tetap harus pindah, pilih yang mana?\n\nIni cuma pendapat, ya. Pilih Go kalau bebanmu didominasi I/O dan kamu butuh cepat produktif. Pilih Rust kalau bebanmu CPU-bound, kamu memegang cache besar di RAM, kamu bangun infrastruktur jaringan atau storage, atau kamu butuh p99 yang datar tanpa toleransi jeda GC.\n\nDan kalau Python atau Node-mu masih jalan baik setelah semua usaha murah dicoba, nggak ada yang memaksa kamu pindah. Bahasa yang dianggap lambat pun bukan masalah kalau dipakai dengan benar.\n\n## Minggu ini, buka *profiler* dulu\n\nJadi balik ke *endpoint* yang spike tadi. Sebelum nulis baris Rust pertama, buka *profiler* dulu minggu ini. Cari tahu apakah spike-nya datang dari GC, dari *query*, atau dari pool koneksi yang nggak dibagi. Kalau jawabannya satu dari dua yang pertama dan cuma bisa dibereskan dengan pindah *runtime*, kamu punya data buat meyakinkan tim. Kalau bukan, selamat, kamu baru aja hemat berbulan-bulan kerja. 😄",[],{"id":65,"title":8,"slug":9,"articles":66,"parent_series":48},"9",[67,77,85,95,106,116,125,133,144,152,161,167,176,184,193,202,209,218,227,234,243,250,259,261,269,277,284,291,299,307,317,326,334,342,350,361,369],{"id":68,"title":69,"slug":70,"excerpt":71,"thumbnail_image":48,"tags":72},"110","Ketika Pilih Framework Cuma Biar Kelihatan Beda","ketika-pilih-framework-cuma-biar-kelihatan-beda","Terakhir kali kamu milih framework atau library baru, itu karena masalahmu butuh alat itu, atau karena alatnya kedengaran keren dan belum banyak yang pakai? Pertanyaan ini nggak enak dijawab. Soalnya keputusan teknologi sering diambil dengan alasan yang nggak pernah ditulis di dokumen teknis mana pun.",[73,74,75,76],"karier","framework","opini","pengalaman",{"id":78,"title":79,"slug":80,"excerpt":81,"thumbnail_image":48,"tags":82},"109","State of JS 2025 Bilang Developer Cuma Pakai 2,6 Framework Sepanjang Karier","state-of-js-2025-developer-cuma-pakai-2-6-framework","Coba hitung semua framework yang pernah kamu coba, lalu potong jadi yang beneran dipakai buat kerjaan. Daftarnya jauh lebih pendek dari dugaan. State of JS 2025 nanya ke 13.002 developer, dan rata-ratanya cuma 2,6. Yuk, lihat angkanya bareng-bareng!",[83,84,74,73],"javascript","survei",{"id":86,"title":87,"slug":88,"excerpt":89,"thumbnail_image":48,"tags":90},"111","Rust Masuk Kernel Linux: Revolusi Nyata atau Cuma Euforia RIIR?","rust-di-kernel-linux-revolusi-atau-cuma-hype","Selama lebih dari 30 tahun kernel Linux cuma mau bahasa C, lalu tiba-tiba Rust resmi masuk di Linux 6.1. Itu revolusi beneran atau cuma kebawa euforia meme Rewrite It In Rust? Yuk lihat datanya, bukan cuma opininya.",[57,91,92,93,94],"linux","kernel","system-programming","memory-safety",{"id":96,"title":97,"slug":98,"excerpt":99,"thumbnail_image":48,"tags":100},"33","Berkenalan dengan RabbitMQ: Si Kurir Pesan Serba Bisa","berkenalan-dengan-rabbitmq-si-kurir-pesan-serba-bisa","Pernah nggak sih kalian klik Bayar Sekarang dan notifikasi suksesnya muncul seketika, padahal email konfirmasi baru nyampe beberapa detik kemudian? Rahasianya ada di satu kurir tak terlihat. Yuk, kita kenalan sama RabbitMQ!",[101,102,54,103,104,105],"rabbitmq","message-broker","microservices","async","queue",{"id":107,"title":108,"slug":109,"excerpt":110,"thumbnail_image":48,"tags":111},"29","Memahami Database Indexing: Rahasia Query Super Cepat","memahami-database-indexing-rahasia-query-super-cepat","Query kalian mulai lelet padahal data baru nembus jutaan baris? Sebelum buru-buru *upgrade* server, yuk cek dulu *index*-nya. Yuk, kita bedah gimana *database indexing* sebenernya kerja!",[112,113,114,115,55,54],"database","sql","postgresql","indexing",{"id":117,"title":118,"slug":119,"excerpt":120,"thumbnail_image":48,"tags":121},"30","Berkenalan dengan Bahasa Go: Kenapa Banyak Dipakai untuk Backend Modern?","berkenalan-dengan-bahasa-go-untuk-backend-modern","Kok bisa sih Go yang masih muda ini jadi bahasa andalan Docker sampai Kubernetes? Yuk, kita kenalan sama Goroutine, Channel, dan alasan dia hemat memori luar biasa!",[56,122,54,123,124,58],"go","concurrency","goroutine",{"id":126,"title":127,"slug":128,"excerpt":129,"thumbnail_image":48,"tags":130},"11","Apa Kabar JavaScript? Rilis State of JS 2022","apa-kabar-javascript-rilis-state-of-js-2022","Survei State of JS 2022 resmi dirilis dengan lonjakan responden yang luar biasa! Framework dan build tool apa saja yang berhasil mencuri perhatian tahun ini?",[83,131,132],"web","news",{"id":134,"title":135,"slug":136,"excerpt":137,"thumbnail_image":48,"tags":138},"37","Kenapa Backend Butuh Graceful Shutdown? Jangan Asal Cabut Kabel Server!","kenapa-backend-butuh-graceful-shutdown-jangan-asal-cabut-kabel-server","Pernah nggak sih, abis kalian nge-*deploy* backend, beberapa detik kemudian monitoring malah banjir *alert* **502 Bad Gateway** dari pengguna? Saldo udah kepotong tapi status order belum keburu ter-*update* di *database*. Yuk, kita bahas kenapa *graceful shutdown* itu wajib banget!",[54,139,140,141,142,58,143],"devops","fastapi","docker","kubernetes","architecture",{"id":145,"title":146,"slug":147,"excerpt":148,"thumbnail_image":48,"tags":149},"39","Database Sharding vs Partitioning: Kapan Data Perlu Dipecah?","database-sharding-vs-partitioning-kapan-data-perlu-dipecah","Tabel transaksi kalian udah nembus miliaran baris dan tiap *query* laporan bikin *CPU* melonjak 100%? Sebelum asal pecah data, yuk kita pahami dulu beda *sharding* sama *partitioning*!",[54,112,114,58,143,150,151],"sharding","scaling",{"id":153,"title":154,"slug":155,"excerpt":156,"thumbnail_image":48,"tags":157},"24","Kenapa Butuh Rate Limiting?","kenapa-butuh-rate-limiting","Pernah nggak sih endpoint login kalian diserbu bot yang nyoba nembak ribuan password cuma dalam semenit? Yuk, kita bahas kenapa Rate Limiting itu wajib, plus cara masangnya di FastAPI!",[54,158,58,159,160,140],"rate-limiting","api","redis",{"id":162,"title":163,"slug":164,"excerpt":165,"thumbnail_image":48,"tags":166},"38","Optimistic vs Pessimistic Locking: Mengatasi Rebutan Data di Database","optimistic-vs-pessimistic-locking-mengatasi-rebutan-data-di-database","Seribu orang ngeklik \"Beli Sekarang\" di detik yang sama buat rebutan 1 tiket terakhir. Kira-kira apa yang bakal terjadi di server kalian? Yuk, kita banding *pessimistic* sama *optimistic locking*!",[54,112,123,114,58,143,113],{"id":168,"title":169,"slug":170,"excerpt":171,"thumbnail_image":48,"tags":172},"26","REST API vs gRPC: Kapan Sebaiknya Mulai Pindah dari JSON?","rest-api-vs-grpc-kapan-sebaiknya-pindah-dari-json","Pernah nggak sih sistem mikroservis kalian mulai kerasa berat padahal cuma tuker-tukeran data internal? Belum tentu masalah servernya. Yuk, kita bahas kapan REST + JSON masih juara dan kapan gRPC jadi jawabannya!",[54,173,174,103,175,58],"grpc","rest-api","protobuf",{"id":177,"title":178,"slug":179,"excerpt":180,"thumbnail_image":48,"tags":181},"46","Mengapa C Mulai Ditinggalkan: Duel Filosofi Keamanan Rust vs Kesederhanaan Zig","mengapa-c-mulai-ditinggalkan-duel-filosofi-rust-vs-zig","Pernah denger kalau sekitar 70% celah keamanan kritis software modern itu asalnya dari bahasa C? Iya, bahasa yang udah jadi fondasi internet ini 😅. Yuk, kita bedah duel filosofi Rust vs Zig dan cari tahu mana yang pas buat proyek kalian!",[93,57,182,183,94],"zig","c",{"id":185,"title":186,"slug":187,"excerpt":188,"thumbnail_image":48,"tags":189},"23","Kenapa Pakai FastAPI dan Kenapa Dia Kenceng Banget?","kenapa-pakai-fastapi-dan-kenapa-dia-kenceng-banget","Sering dengar FastAPI tapi masih bingung kenapa dia bisa ngebut kayak NodeJS dan Go? Yuk, kita bedah bareng rahasia ASGI, sihir Pydantic, sampai dokumentasi otomatisnya!",[140,190,54,191,192],"python","asgi","pydantic",{"id":194,"title":195,"slug":196,"excerpt":197,"thumbnail_image":48,"tags":198},"14","Instalasi Java dengan Visual Studio Code","instalasi-java-dengan-visual-studio-code","Mau belajar ngoding Java tapi spek laptop pas-pasan buat buka IDE berat? Yuk, cari tahu cara setup VS Code biar ngoding Java tetap lancar dan enteng!",[199,200,201],"howto","java","editor",{"id":203,"title":204,"slug":205,"excerpt":206,"thumbnail_image":48,"tags":207},"15","Kenapa Ada Banyak Sekali Distro Linux?","kenapa-ada-banyak-sekali-distro-linux","Pernah bingung pas mau install Linux tapi malah disuguhi puluhan pilihan distro? Tenang, kalian nggak sendirian. Yuk, cari tahu kenapa distro Linux bisa sebanyak itu dan apa bedanya!",[91,208],"distro",{"id":210,"title":211,"slug":212,"excerpt":213,"thumbnail_image":48,"tags":214},"31","Mengenal Redis: Lebih dari Sekadar In-Memory Cache","mengenal-redis-lebih-dari-sekadar-in-memory-cache","Masih nganggep Redis cuma buat caching? Padahal dia bisa jadi leaderboard, message broker, sampai rate limiter lho. Yuk, kita bedah semua kemampuannya!",[160,54,215,216,217,190],"cache","nosql","in-memory",{"id":219,"title":220,"slug":221,"excerpt":222,"thumbnail_image":48,"tags":223},"20","Tailwind v3.0 Rilis: Ada JIT, Arbitrary Values, dan Banyak Lagi!","tailwind-v3-0-rilis-jit-arbitrary-dan-banyak-lagi","Tailwind CSS v3.0 resmi dirilis dengan segudang peningkatan performa yang bikin proses coding makin asyik. Apa aja sih fitur andalan yang wajib dicoba?",[224,225,226],"tailwind-css","css-framework","web-development",{"id":228,"title":229,"slug":230,"excerpt":231,"thumbnail_image":48,"tags":232},"18","React, Angular, atau Vue: Pilih Framework yang Mana?","react-angular-vue-pilih-framework-yang-mana","Bingung menentukan pilihan di antara React, Angular, dan Vue untuk proyek web kalian berikutnya? Tenang, yuk kita bandingkan kelebihan masing-masing di sini!",[226,233,74],"frontend",{"id":235,"title":236,"slug":237,"excerpt":238,"thumbnail_image":48,"tags":239},"19","Static Typing dan Dynamic Typing: Apa Bedanya?","static-typing-dan-dynamic-typing-apa-bedanya","Pernah bingung kenapa di Java tipe data harus dideklarasikan, sementara di Python tinggal pakai aja? Yuk, cari tahu perbedaan static typing dan dynamic typing di sini!",[240,241,242],"programming","types","comparison",{"id":244,"title":245,"slug":246,"excerpt":247,"thumbnail_image":48,"tags":248},"21","TypeScript: JavaScript dengan Gaya dan Tipe Data Statis","typescript-javascript-dengan-gaya","Pernah pusing gara-gara runtime error di JavaScript? Yuk, kenalan dengan TypeScript yang bawa fitur static typing biar kode kalian makin rapi dan aman!",[249,83,226],"typescript",{"id":251,"title":252,"slug":253,"excerpt":254,"thumbnail_image":48,"tags":255},"22","Yang Baru di Nuxt 3: Nitro Engine, Vite, dan Fitur Keren Lainnya","yang-baru-di-nuxt-3-nitro-vite-dan-banyak-lagi","Nuxt 3 hadir membawa perubahan arsitektur besar-besaran untuk menyelaraskan dengan Vue 3. Penasaran apa saja peningkatan performa dan fitur barunya?",[256,257,258],"nuxt-3","vue-3","frontend-framework",{"id":49,"title":50,"slug":51,"excerpt":52,"thumbnail_image":48,"tags":260},[54,55,56,57,58,59],{"id":262,"title":263,"slug":264,"excerpt":265,"thumbnail_image":48,"tags":266},"32","Docker Compose untuk Developer Santai: Satu Perintah Buat Jalankan Semua Service","docker-compose-untuk-developer-santai","Pernah nggak kalian ngulang-ngulang perintah `docker run` cuma buat nyalain web, database, dan cache satu-satu? Capek, kan? Yuk, kita rapikan semuanya jadi satu file dan satu perintah!",[141,267,139,268,54],"docker-compose","containers",{"id":270,"title":271,"slug":272,"excerpt":273,"thumbnail_image":48,"tags":274},"35","Mengenal Idempotency Key: Rahasia Anti-Double Charge di API Pembayaran","mengenal-idempotency-key-rahasia-anti-double-charge-di-api-pembayaran","Pernah internet kalian ngadat pas lagi nekan tombol Bayar, terus panik ngekliknya tiga kali? Kalau endpoint-nya nggak idempotent, saldo bisa kepotong berkali-kali. Yuk, kenalan sama Idempotency Key!",[54,159,275,58,276,140,160],"idempotency","payment",{"id":278,"title":279,"slug":280,"excerpt":281,"thumbnail_image":48,"tags":282},"25","Kenapa Event Queue Bikin Backend Kalian Nggak Gampang Tumbang?","kenapa-event-queue-bikin-backend-kamu-nggak-gampang-tumbang","Pernah klik tombol Beli Sekarang dan notifikasi suksesnya muncul dalam sekejap, padahal di belakang layar ada invoice, email, sampai push notification yang harus dibuat? Rahasianya Event Queue. Yuk, kita bedah!",[54,58,283,102,143],"event-queue",{"id":285,"title":286,"slug":287,"excerpt":288,"thumbnail_image":48,"tags":289},"36","Mencegah Efek Domino di Mikroservis dengan Circuit Breaker Pattern","mencegah-efek-domino-di-mikroservis-dengan-circuit-breaker-pattern","Pernah nggak sih, satu fitur minor di aplikasi kalian mendadak lelet, eh malah bikin halaman checkout dan login ikut down total? Itu namanya *cascading failure*. Yuk, kita bahas gimana *circuit breaker pattern* (pemutus arus) nyelametin arsitektur kalian!",[54,103,290,58,143],"circuit-breaker",{"id":292,"title":293,"slug":294,"excerpt":295,"thumbnail_image":48,"tags":296},"17","Pemrograman Asynchronous vs Multithreading, Apa Sih Bedanya?","pemrograman-asynchronous-dan-multithreading-apa-bedanya","Sering dengar istilah asynchronous dan multithreading pas ngoding tapi masih bingung bedanya? Yuk, kita bedah perbedaannya lewat analogi bikin mi instan yang gampang dipahami!",[297,123,298],"pemrograman","tips-coding",{"id":300,"title":301,"slug":302,"excerpt":303,"thumbnail_image":48,"tags":304},"16","Menggunakan TypeScript dengan Node.js dan Express","menggunakan-typescript-dengan-node-js-dan-express","Pengen bikin server Express di Node.js tapi pakai fitur-fitur keren TypeScript? Yuk, intip cara setup lengkapnya dari nol di sini!",[83,305,306,249],"nodejs","express",{"id":308,"title":309,"slug":310,"excerpt":311,"thumbnail_image":48,"tags":312},"40","Menyelami Distributed Tracing: Melacak Jejak Request di Balik Keruwetan Microservices","menyelami-distributed-tracing-melacak-jejak-request-microservices","Satu klik Checkout di backend kalian bisa memicu puluhan network call antar-service, tapi pas ada yang lambat, service mana sebenernya yang salah? Log aja nggak cukup buat njawab itu. Yuk, kita bedah Distributed Tracing!",[54,313,314,315,103,143,316],"distributed-systems","observability","open-telemetry","tracing",{"id":318,"title":319,"slug":320,"excerpt":321,"thumbnail_image":48,"tags":322},"28","Mengatasi N+1 Query Problem: Musuh Tersembunyi Performa Backend","mengatasi-n-plus-1-query-problem-musuh-tersembunyi-backend","Pernah bikin endpoint yang cuma nampilin 50 postingan beserta nama penulisnya, tapi response-nya lambat banget? Bisa jadi kalian kena N+1 Query. Yuk, kita bedah penyebabnya dan cara memberantasnya!",[112,113,323,324,325,55,54],"orm","sqlalchemy","django",{"id":327,"title":328,"slug":329,"excerpt":330,"thumbnail_image":48,"tags":331},"13","Hal yang Perlu Diperhatikan Sebelum Pindah ke Linux","hal-yang-perlu-diperhatikan-sebelum-pindah-ke-linux","Tertarik migrasi dari Windows ke Linux tapi masih ragu? Yuk, pelajari kelebihan, kekurangan, dan persiapan penting sebelum kamu benar-benar pindah!",[91,332,333],"windows","foss",{"id":335,"title":336,"slug":337,"excerpt":338,"thumbnail_image":48,"tags":339},"27","Background Worker & Task Queue: Jangan Jalankan Proses Berat di Request HTTP!","background-worker-task-queue-jangan-jalankan-proses-berat-di-http","Pernah nggak sih kalian klik Daftar Akun lalu halaman loading muter sampai 15 detik tanpa kepastian? Penyebabnya klasik banget. Yuk, kita bahas kenapa proses berat nggak boleh dijalanin di request HTTP!",[54,340,341,140,101,160,104],"task-queue","celery",{"id":343,"title":344,"slug":345,"excerpt":346,"thumbnail_image":48,"tags":347},"12","Buat PowerShell Lebih Berwarna dengan Starship","buat-powershell-lebih-berwarna-dengan-starship","Bosen sama tampilan PowerShell yang hitam putih dan kaku? Yuk, sulap terminalmu jadi lebih interaktif, estetik, dan berwarna pakai Starship!",[348,332,349],"shell","powershell",{"id":351,"title":352,"slug":353,"excerpt":354,"thumbnail_image":48,"tags":355},"41","Log Aggregation Modern dengan Grafana Loki dan Vector: Hemat Storage Tanpa Indeks Raksasa","log-aggregation-modern-grafana-loki-vector-hemat-storage","Klaster Elasticsearch kalian rakus RAM dan boros storage, ya? Padahal nggak semua kata di log perlu diindeks, lho. Yuk, kita kenalan sama duet Grafana Loki dan Vector yang jauh lebih ramah kantong!",[54,356,357,358,359,360,139,58],"observa","logging","grafana","loki","vector",{"id":362,"title":363,"slug":364,"excerpt":365,"thumbnail_image":48,"tags":366},"45","Rate Limiting Algorithms: Token Bucket vs Leaky Bucket vs Sliding Window","rate-limiting-algorithms-token-bucket-leaky-bucket-sliding-window","Udah tahu kenapa *rate limiting* itu wajib, tapi masih bingung beda Token Bucket, Leaky Bucket, Fixed Window, dan Sliding Window? Yuk, kita adu empat algoritma ini bareng-bareng dan cari tahu mana yang paling pas buat API kalian!",[54,58,158,160,367,143,368],"api-gateway","traffict-management",{"id":370,"title":371,"slug":372,"excerpt":373,"thumbnail_image":48,"tags":374},"34","Kenapa Backend Butuh Database Connection Pooling?","kenapa-backend-butuh-database-connection-pooling","Pernah kena error Too many connections padahal CPU server masih santai di angka 30%? Masalahnya bukan di query kalian, tapi di cara aplikasi ngobrol sama database. Yuk, kenalan sama Connection Pooling!",[54,112,114,375,58,55],"connection-pooling","\u003Cp>Bayangin ada satu \u003Cem>endpoint\u003C/em> yang grafik latency-nya nggak rata. Kebanyakan waktu dia adem, tapi tiba-tiba naik lancip, turun lagi, lalu naik lagi. Kamu mandangin grafik itu sambil ngopi, dan yang muncul di kepala \u003Cstrong>bukan profiler\u003C/strong>. Yang muncul adalah kalimat, "kayaknya pindah bahasa aja deh." 😅\u003C/p>\n\u003Cp>Dorongan itu wajar banget, kok. Ada perusahaan besar yang beneran pindah bahasa dan hasilnya bagus. Tapi ada yang jarang kita perhatiin: dua cerita paling terkenal itu \u003Cstrong>nggak dimulai dari bahasa baru\u003C/strong>. Mereka mulai dari angka, dari ngukur sampai kelihatan persis di mana yang mentok. Joel Spolsky pernah bilang bahwa \u003Ca href=\"https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/\">menulis ulang dari nol adalah "the single worst strategic mistake that any software company can make"\u003C/a>, dan kita bakal lihat kenapa kalimat itu masih relevan.\u003C/p>\n\u003Cp>Yuk kita bedah tiga kasus nyata, plus satu kontra-contoh. Tujuannya bukan bilang pindah bahasa itu salah. Tujuannya biar kamu tahu kapan solusi murah udah habis, dan kapan baru boleh mikir \u003Cem>rewrite\u003C/em>.\u003C/p>\n\u003Ch2 id=\"kenapa-discord-akhirnya-pindah-dari-go-ke-rust\">Kenapa \u003Cem>Discord\u003C/em> akhirnya pindah dari Go ke Rust?\u003C/h2>\n\u003Cp>Yang mereka pindahkan namanya Read States. Tugasnya cuma nyatet channel dan pesan mana yang udah kamu baca. Sederhana, tapi layanan ini dipanggil tiap kali kita connect, tiap kali kirim pesan, dan tiap kali buka pesan. Jadi dia nempel di hampir semua hal yang kita lakuin di sana, lho.\u003C/p>\n\u003Cp>Skalanya gede, nih. Ada \u003Ca href=\"https://discord.com/blog/why-discord-is-switching-from-go-to-rust\">miliaran Read State\u003C/a>, satu per user per channel. Tiap instance cache memegang jutaan user dan puluhan juta Read State. Per detiknya ada ratusan ribu update cache dan puluhan ribu write \u003Cem>database\u003C/em>.\u003C/p>\n\u003Cp>Gejalanya emang aneh tapi konsisten: spike latency dan CPU tiap sekitar 2 menit. Penyebabnya, Go memaksa \u003Cem>GC\u003C/em> jalan minimal tiap 2 menit, terlepas dari seberapa besar \u003Cem>heap\u003C/em>-nya tumbuh. Dari \u003Ca href=\"https://discord.com/blog/why-discord-is-switching-from-go-to-rust\">grafik di blog mereka\u003C/a>, CPU naik dari sekitar 20% ke 30–40%. \u003Cem>Average response time\u003C/em> naik dari sekitar 0–2 ms ke sekitar 25 ms. Yang p95 melonjak dari sekitar 0–10 ms ke sekitar 300 ms. Catat ya, itu p95, bukan p99, dan semua angka ini hasil baca grafik, jadi sifatnya perkiraan.\u003C/p>\n\u003Cp>Nah, bagian pentingnya: mereka nggak langsung pindah. Mereka nyoba tuning dulu, dan dua-duanya gagal. Pertama, mengubah GC percent dari \u003Cem>endpoint\u003C/em>. Hasilnya nggak ngaruh, soalnya alokasi mereka nggak cukup cepat untuk memicu GC lebih sering. Kedua, memperkecil \u003Cem>LRU cache\u003C/em>. Spike-nya memang mengecil, tapi p99-nya naik karena cache jadi lebih sering \u003Cem>miss\u003C/em> dan bebannya pindah ke \u003Cem>database\u003C/em>.\u003C/p>\n\u003Cp>Jadi mereka udah ketemu tembok, tuh. Bukan tembok malas, tapi tembok yang diukur dan dicoba dobrak dua kali. Baru setelah itu mereka porting ke Rust, dan kata mereka latency-nya sama bagusnya dengan versi Go, dan \u003Cstrong>nggak ada spike sama sekali\u003C/strong>. Dengan optimasi dasar aja versi Rust sudah mengalahkan versi Go yang di-tuning mati-matian. Setelah diprofil lagi, Rust menang di latency, CPU, dan memori.\u003C/p>\n\u003Cp>Beberapa hari kemudian kapasitas cache dinaikkan ke 8 juta Read State, hal yang nggak mungkin di versi Go karena GC-nya makin lama makin berat. Hasilnya, \u003Cem>average\u003C/em> response time jadi satuan mikrodetik, dan Max @mention jadi satuan milidetik. Tapi lihat catatan kaki mereka sendiri: mereka nggak berpikir kamu harus menulis ulang semuanya di Rust cuma karena bisa.\u003C/p>\n\u003Ch2 id=\"cloudflare-kodenya-lebih-cepat-atau-arsitekturnya\">Cloudflare: kodenya lebih cepat, atau arsitekturnya?\u003C/h2>\n\u003Cp>Cerita kedua datang dari Cloudflare, yang mengganti \u003Cem>NGINX\u003C/em> dengan \u003Cem>Pingora\u003C/em>. Menurut \u003Ca href=\"https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/\">tulisan mereka soal Pingora\u003C/a>, sistem barunya melayani lebih dari 1 triliun \u003Cem>request\u003C/em> per hari. Dia cuma butuh sepertiga CPU dan memori dibanding infrastruktur proxy sebelumnya. Di produksi, hematnya 70% CPU dan 67% memori di beban yang sama. TTFB juga turun 5 ms di median dan 80 ms di p95.\u003C/p>\n\u003Cp>Sekarang bagian yang paling sering kelewat. Hemat itu \u003Cstrong>bukan karena kodenya lebih cepat\u003C/strong>, lho. Layanan lama mereka juga udah sub-milidetik. Yang lebih cepat itu cara dia berbagi koneksi. 🤯\u003C/p>\n\u003Cp>Masalahnya ada di arsitektur NGINX, sih. Satu \u003Cem>request\u003C/em> cuma dilayani satu \u003Cem>worker\u003C/em>, yaitu satu proses OS. Load-nya nggak seimbang antar core, dan \u003Cem>connection pool\u003C/em>-nya per \u003Cem>worker\u003C/em>. Akibatnya makin banyak \u003Cem>worker\u003C/em> ditambah, makin jelek rasio \u003Cem>reuse\u003C/em> koneksinya. Ini kayak kalau tiap orang punya galon air sendiri di mejanya. Kamu butuh minum, galon sebelah masih penuh, tapi nggak bisa diambil, jadi kamu beli galon baru lagi. Tambah orang bukan bikin galon yang ada lebih kepakai, malah nambah galon baru terus.\u003C/p>\n\u003Cp>Pingora dibangun dengan multithreading, \u003Cem>runtime\u003C/em> async \u003Cem>Tokio\u003C/em>, dan \u003Cem>work stealing\u003C/em>. Mereka juga bikin HTTP \u003Cem>library\u003C/em> sendiri karena \u003Cem>traffic\u003C/em> di internet banyak yang nggak patuh RFC. Hasilnya, koneksi baru yang dibuat per detik tinggal sepertiga. Untuk satu pelanggan besar, rasio \u003Cem>reuse\u003C/em> koneksi naik dari 87,1% ke 99,92%, dan koneksi baru ke origin turun 160x. Terjemahan blog mereka: "kami menghemat 434 tahun waktu \u003Cem>handshake\u003C/em> setiap hari."\u003C/p>\n\u003Cp>Ada alasan lain mereka pindah. C nggak \u003Cem>memory safe\u003C/em>, Lua kurang performan dan nggak ada \u003Cem>static typing\u003C/em>, dan komunitas NGINX bergerak lambat. Setelah melayani beberapa ratus triliun \u003Cem>request\u003C/em>, Pingora belum pernah crash karena kode service-nya. Sistem ini lalu \u003Ca href=\"https://blog.cloudflare.com/pingora-open-source\">di-open source-kan pada 28 Februari 2024\u003C/a>.\u003C/p>\n\u003Ch2 id=\"jadi-sebenarnya-apa-yang-kamu-beli-dengan-pindah-bahasa\">Jadi sebenarnya apa yang kamu beli dengan pindah bahasa?\u003C/h2>\n\u003Cp>Dua kemenangan tadi datang dari dua mekanisme yang beda. Di \u003Cem>Discord\u003C/em>, yang hilang adalah GC. Di Cloudflare, yang didapat adalah kemampuan berbagi resource lintas \u003Cem>thread\u003C/em>. Itu aja, sih. Bukan "Rust lebih cepat" secara magis, tapi ada \u003Cstrong>satu batasan spesifik\u003C/strong> yang akhirnya lenyap.\u003C/p>\n\u003Cp>Kalau masalahmu bukan salah satu dari dua itu, ganti bahasa nggak akan mengubah apa pun. Query lambat tetap lambat di Rust. N+1 tetap N+1 di Go. Kamu cuma bakal punya masalah yang sama dengan sintaks yang berbeda, plus biaya belajar yang nggak kecil, lho.\u003C/p>\n\u003Cp>Kutipan Knuth sering dipotong jadi slogan. Versi lengkapnya begini: \u003Cem>"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."\u003C/em> Slogan itu sering dipakai buat menghindari ngukur, padahal Knuth justru minta kita tahu kode mana yang masuk 3% itu. Dan satu-satunya cara tahu adalah dengan \u003Cem>profiler\u003C/em>.\u003C/p>\n\u003Ch2 id=\"gimana-kalau-masalahmu-memang-gc-tapi-bahasanya-python\">Gimana kalau masalahmu memang GC, tapi bahasanya Python?\u003C/h2>\n\u003Cp>Di sini ada kabar yang menenangkan. Kalau masalahmu memang GC, kamu nggak selalu butuh bahasa baru. Pada Januari 2017, \u003Ca href=\"https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172\">Instagram mematikan GC di Python-nya\u003C/a> dan langsung jadi 10% lebih efisien. Nggak pindah bahasa, nggak ganti \u003Cem>framework\u003C/em>, \u003Cstrong>cuma mematikan satu fitur\u003C/strong>. 🙌\u003C/p>\n\u003Cp>Konteksnya gini. Instagram jalan dengan \u003Cem>Django\u003C/em> multi-proses, pakai \u003Cem>uWSGI\u003C/em> model \u003Cem>pre-fork\u003C/em>. Satu master mem-\u003Cem>fork\u003C/em> dirinya jadi puluhan \u003Cem>worker\u003C/em> yang melayani \u003Cem>request\u003C/em>. Idealnya, memori yang dibagi antar \u003Cem>worker\u003C/em> itu tetap dibagi.\u003C/p>\n\u003Cp>Tapi temuannya lain. \u003Cem>Shared memory\u003C/em> tiap \u003Cem>worker\u003C/em> turun dari sekitar 250 MB ke sekitar 140 MB, kira-kira sepertiga, cuma dalam beberapa detik setelah \u003Cem>worker\u003C/em> lahir. Sebabnya, Python pakai \u003Cem>reference counting\u003C/em>. Setiap kali sebuah objek dibaca, counter-nya ditulis. Tulisan itu memicu \u003Cem>copy-on-write\u003C/em> di kernel, jadi halaman memori yang tadinya dibagi berubah jadi milik masing-masing proses.\u003C/p>\n\u003Cp>Coba pikirin sebentar, deh. Gejala "GC bikin latency jelek" muncul di tiga tempat berbeda: di Go (\u003Cem>Discord\u003C/em>), di JVM Cassandra (\u003Cem>Discord\u003C/em> lagi), dan di Python (Instagram). Jawabannya beda-beda. \u003Cem>Discord\u003C/em> pindah bahasa, Instagram cuma ganti konfigurasi. Yang salah bukan bahasanya, tapi keputusan yang diambil di sekitar bahasanya.\u003C/p>\n\u003Ch2 id=\"kadang-bottleneck-nya-bahkan-bukan-bahasa\">Kadang bottleneck-nya bahkan bukan bahasa\u003C/h2>\n\u003Cp>Ini kontra-contohnya, dan lagi-lagi dari \u003Cem>Discord\u003C/em>. Pada 2023, mereka pindah dari \u003Cem>Cassandra\u003C/em> ke \u003Cem>ScyllaDB\u003C/em>, dan \u003Ca href=\"https://discord.com/blog/how-discord-stores-trillions-of-messages\">177 node jadi 72 node\u003C/a>. P99 untuk mengambil pesan historis turun dari 40–125 ms jadi 15 ms. Insert pesan turun dari 5–70 ms jadi 5 ms.\u003C/p>\n\u003Cp>Akar masalah aslinya adalah \u003Cem>hot partition\u003C/em>, konkurensi yang nggak terkendali, dan GC di JVM Cassandra. Yang menyelesaikannya adalah \u003Cem>request coalescing\u003C/em> plus \u003Cem>consistent hash routing\u003C/em> (ditulis di Rust), serta \u003Cem>database\u003C/em> yang bebas GC. Jadi bahkan di cerita "pindah ke Rust", sebagian besar kemenangannya datang dari desain dan pilihan komponen yang tepat.\u003C/p>\n\u003Cp>Bonusnya, migrator-nya ditulis di Rust dan estimasi migrasinya berubah dari 3 bulan jadi 9 hari. Puncaknya jalan di 3,2 juta pesan per detik. Jadi Rust tetap punya tempat yang jelas, tapi tempatnya sempit dan spesifik.\u003C/p>\n\u003Ch2 id=\"kapan-rewrite-boleh-dipertimbangkan\">Kapan \u003Cem>rewrite\u003C/em> boleh dipertimbangkan?\u003C/h2>\n\u003Cp>Alasan Spolsky masuk akal: kode lama itu sudah dipakai, sudah diuji, dan ratusan \u003Cem>bug\u003C/em> sudah ditemukan dan diperbaiki. Menulis ulang berarti membuang semua pengetahuan itu. Dia juga bilang soal performa, "1% of the work gets you 99% of the bang." Kalau 1% itu belum kamu cari, jangan loncat ke 100%.\u003C/p>\n\u003Cp>Jadi rewrite itu \u003Cstrong>keputusan terakhir\u003C/strong>, bukan langkah pertama. Ada tiga pertanyaan yang harus kamu punya datanya.\u003C/p>\n\u003Cul>\n\u003Cli>Udah habis belum usaha yang lebih murah, seperti \u003Cem>query\u003C/em>, indeks, \u003Cem>caching\u003C/em>, N+1, dan \u003Cem>connection pool\u003C/em>? Ingat, Cloudflare mengevaluasi pilihannya tiap kuartal selama beberapa tahun.\u003C/li>\n\u003Cli>Bottleneck-nya kebukti berasal dari \u003Cem>runtime\u003C/em> atau arsitektur, bukan dari kode kita sendiri?\u003C/li>\n\u003Cli>Komponennya cukup terisolasi? \u003Cem>Discord\u003C/em> cuma memindahkan satu service, dan Cloudflare cuma mengganti layer proxy.\u003C/li>\n\u003C/ul>\n\u003Cp>Kalau belum bisa jawab ketiganya dengan data, jawabannya sekarang adalah belum. Dan itu jawaban yang sehat, kok, bukan tanda kamu pengecut.\u003C/p>\n\u003Ch2 id=\"kalau-tetap-harus-pindah-pilih-yang-mana\">Kalau tetap harus pindah, pilih yang mana?\u003C/h2>\n\u003Cp>Ini cuma pendapat, ya. Pilih Go kalau bebanmu didominasi I/O dan kamu butuh cepat produktif. Pilih Rust kalau bebanmu CPU-bound, kamu memegang cache besar di RAM, kamu bangun infrastruktur jaringan atau storage, atau kamu butuh p99 yang datar tanpa toleransi jeda GC.\u003C/p>\n\u003Cp>Dan kalau Python atau Node-mu masih jalan baik setelah semua usaha murah dicoba, nggak ada yang memaksa kamu pindah. Bahasa yang dianggap lambat pun bukan masalah kalau dipakai dengan benar.\u003C/p>\n\u003Ch2 id=\"minggu-ini-buka-profiler-dulu\">Minggu ini, buka \u003Cem>profiler\u003C/em> dulu\u003C/h2>\n\u003Cp>Jadi balik ke \u003Cem>endpoint\u003C/em> yang spike tadi. Sebelum nulis baris Rust pertama, buka \u003Cem>profiler\u003C/em> dulu minggu ini. Cari tahu apakah spike-nya datang dari GC, dari \u003Cem>query\u003C/em>, atau dari pool koneksi yang nggak dibagi. Kalau jawabannya satu dari dua yang pertama dan cuma bisa dibereskan dengan pindah \u003Cem>runtime\u003C/em>, kamu punya data buat meyakinkan tim. Kalau bukan, selamat, kamu baru aja hemat berbulan-bulan kerja. 😄\u003C/p>\n","\u003Cp>Pindah bahasa baru punya dasar kalau bottleneck-nya terbukti berasal dari runtime atau dari arsitektur yang nggak bisa berbagi resource, dan komponennya cukup terisolasi untuk digarap sendirian.\u003C/p>\n\u003Cul>\n\u003Cli>Yang sebenarnya kamu beli dari pindah bahasa bukan "kode yang lebih cepat", tapi hilangnya GC di kasus Discord dan kemampuan berbagi resource lintas thread di kasus Cloudflare.\u003C/li>\n\u003Cli>Discord baru pindah ke Rust setelah dua usaha tuning-nya gagal, dan Cloudflare mengevaluasi pilihannya tiap kuartal selama beberapa tahun sebelum akhirnya membangun Pingora.\u003C/li>\n\u003Cli>Instagram justru cukup mematikan GC di Python-nya dan langsung jadi 10% lebih efisien, jadi bahasa yang dianggap lambat pun bukan masalah selama dipakai dengan benar.\u003C/li>\n\u003Cli>Selama masih ada query, indeks, atau konfigurasi yang belum dibereskan, masalah yang sama cuma pindah ke bahasa baru berikut biaya belajarnya.\u003C/li>\n\u003C/ul>\n",[379,381,383,385,387,393],{"id":49,"title":50,"slug":51,"excerpt":52,"thumbnail_image":48,"tags":380},[54,55,56,57,58,59],{"id":86,"title":87,"slug":88,"excerpt":89,"thumbnail_image":48,"tags":382},[57,91,92,93,94],{"id":68,"title":69,"slug":70,"excerpt":71,"thumbnail_image":48,"tags":384},[73,74,75,76],{"id":78,"title":79,"slug":80,"excerpt":81,"thumbnail_image":48,"tags":386},[83,84,74,73],{"id":388,"title":389,"slug":390,"excerpt":391,"thumbnail_image":48,"tags":392},"104","Query-nya Tinggal 2, Tapi Response-nya Masih 1 Detik","query-tinggal-2-tapi-response-masih-1-detik","Endpoint feed yang cuma menampilkan 20 tulisan butuh satu detik, dan server database dihujani 41 query. Kamu kerjakan nasihat N+1 yang standar, query-nya turun jadi 2, dan latency-nya nggak bergerak. Ini versi \"apa adanya\" dari masalah itu, plus lab-nya.",[112,55,54],{"id":177,"title":178,"slug":179,"excerpt":180,"thumbnail_image":48,"tags":394},[93,57,182,183,94],[396,400,403,406,409,412,415,418],{"text":397,"depth":398,"id":399},"Kenapa Discord akhirnya pindah dari Go ke Rust?",2,"kenapa-discord-akhirnya-pindah-dari-go-ke-rust",{"text":401,"depth":398,"id":402},"Cloudflare: kodenya lebih cepat, atau arsitekturnya?","cloudflare-kodenya-lebih-cepat-atau-arsitekturnya",{"text":404,"depth":398,"id":405},"Jadi sebenarnya apa yang kamu beli dengan pindah bahasa?","jadi-sebenarnya-apa-yang-kamu-beli-dengan-pindah-bahasa",{"text":407,"depth":398,"id":408},"Gimana kalau masalahmu memang GC, tapi bahasanya Python?","gimana-kalau-masalahmu-memang-gc-tapi-bahasanya-python",{"text":410,"depth":398,"id":411},"Kadang bottleneck-nya bahkan bukan bahasa","kadang-bottleneck-nya-bahkan-bukan-bahasa",{"text":413,"depth":398,"id":414},"Kapan rewrite boleh dipertimbangkan?","kapan-rewrite-boleh-dipertimbangkan",{"text":416,"depth":398,"id":417},"Kalau tetap harus pindah, pilih yang mana?","kalau-tetap-harus-pindah-pilih-yang-mana",{"text":419,"depth":398,"id":420},"Minggu ini, buka profiler dulu","minggu-ini-buka-profiler-dulu",1791452891061]