<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Runtime on Nalar</title>
    <link>https://nalar.dev/id/tags/runtime/</link>
    <description>Recent content in Runtime on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Sat, 19 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/runtime/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cara Runtime Bahasa Memakai Core CPU: Thread, Goroutine, Worker, dan Proses</title>
      <link>https://nalar.dev/id/cara-runtime-bahasa-memakai-core-cpu-thread-goroutine-worker-dan-proses/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/cara-runtime-bahasa-memakai-core-cpu-thread-goroutine-worker-dan-proses/</guid>
      <description>&lt;p&gt;CPU dengan banyak core tidak membuat kode aplikasi menjadi paralel dengan sendirinya. Sistem operasi memang dapat menjadwalkan beberapa thread pada saat yang sama, tetapi bahasa dan runtime menentukan bagaimana pekerjaan aplikasi mencapai thread tersebut. Perbedaan ini menjelaskan mengapa Go, Rust, C++, Java, JavaScript, dan PHP sama-sama dapat memakai mesin multicore meskipun model pemrogramannya sangat berbeda.&lt;/p&gt;&#xA;&lt;p&gt;Pertanyaan yang lebih berguna bukan sekadar apakah sebuah bahasa &amp;ldquo;multithreaded&amp;rdquo;. Yang perlu dilihat adalah bagaimana satu unit pekerjaan aplikasi berubah menjadi sesuatu yang dapat dijadwalkan oleh sistem operasi.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Go Defer Menyimpan Argumen Pemanggilan Sebelum Return</title>
      <link>https://nalar.dev/id/go-defer-menyimpan-argumen-pemanggilan-sebelum-return/</link>
      <pubDate>Wed, 16 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/go-defer-menyimpan-argumen-pemanggilan-sebelum-return/</guid>
      <description>&lt;p&gt;Statement &lt;code&gt;defer&lt;/code&gt; pada Go mengevaluasi nilai fungsi dan parameter pemanggilannya ketika eksekusi mencapai statement tersebut, meskipun fungsi yang ditunda baru berjalan saat fungsi di sekitarnya melakukan return. Mutasi di antara dua momen itu tidak mengubah secara retroaktif nilai argumen yang sudah disimpan.&lt;/p&gt;&#xA;&lt;p&gt;Pemisahan antara evaluasi dan invocation ini merupakan bagian dari semantik bahasa, bukan detail optimisasi. Setiap &lt;code&gt;defer&lt;/code&gt; yang dieksekusi mencatat sebuah pemanggilan dengan nilai yang ditetapkan pada saat itu. Proses return kemudian menjalankan pemanggilan yang tercatat dalam urutan registrasi terbalik.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Urutan Iterasi Map Go Tidak Stabil</title>
      <link>https://nalar.dev/id/urutan-iterasi-map-go-tidak-stabil/</link>
      <pubDate>Wed, 16 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/urutan-iterasi-map-go-tidak-stabil/</guid>
      <description>&lt;p&gt;&lt;code&gt;range&lt;/code&gt; pada map Go dapat mengunjungi entri yang sama dalam urutan berbeda pada iterasi berturut-turut. Spesifikasi bahasa menyatakan bahwa urutan iterasi map tidak ditentukan dan tidak menjamin bahwa iterasi berikutnya pada map yang tidak berubah akan mengulangi urutan sebelumnya.&lt;/p&gt;&#xA;&lt;p&gt;Kontrak ini lebih kuat daripada sekadar mengatakan bahwa map tidak terurut. Container yang tidak terurut masih bisa saja menampilkan urutan stabil yang bergantung pada insertion order atau layout storage. Program Go tidak boleh memberikan makna seperti itu pada traversal map.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
