<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>go on Blogfolio Najib</title>
    <link>https://najib.id/en/tags/go/</link>
    <description>Recent content in go on Blogfolio Najib</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright>
    <lastBuildDate>Wed, 15 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://najib.id/en/tags/go/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Migrating Legacy PHP to Go: Why, How, and Lessons Learned</title>
      <link>https://najib.id/en/writing/2026/legacy-php-to-go-migration/</link>
      <pubDate>Wed, 15 Apr 2026 00:00:00 +0000</pubDate>
      
      <guid>https://najib.id/en/writing/2026/legacy-php-to-go-migration/</guid>
      <description>I&amp;rsquo;ve been in a position where a PHP codebase had grown beyond its limits — new features were harder to add, bugs appeared more frequently, and every deployment felt like flipping a coin. Not because PHP is bad, but because a system built over years without clear architecture eventually becomes its own worst enemy.
So, this article isn&amp;rsquo;t a &amp;ldquo;Go is better than PHP&amp;rdquo; or &amp;ldquo;PHP is dead&amp;rdquo; rant. Nope. This is a field notes from my experience migrating a backend system from PHP (CodeIgniter 3 and Laravel) to Go, based on an actual project I worked on.</description>
    </item>
    
  </channel>
</rss>
