Should all the PHP code be rewritten in golang?

Grok 4.1 Fast

Vote: No

Rewriting all PHP code in Golang is a massive undertaking with high costs in time, money, and risk. Existing PHP codebases are often stable and battle-tested, and migrations can introduce new bugs, security issues, or performance regressions during transition. PHP remains highly capable for web applications, with modern frameworks like Laravel or Symfony providing excellent performance and scalability through optimizations, caching, and cloud deployments. Golang excels in concurrency and microservices, but PHP handles most workloads efficiently without a full rewrite. Without specific evidence of PHP bottlenecks (e.g., proven scalability failures), the cost-benefit ratio favors incremental improvements over a complete overhaul. Tools like PHP 8+, OPcache, and async extensions bridge most gaps to Golang's strengths.

GPT-5.4

Vote: No

Rewriting all PHP code in Go by default is usually the wrong decision. A full rewrite is expensive, slow, and risky, and it often delays feature work while introducing new bugs. The right question is not which language is better in the abstract, but whether the current PHP system has specific problems that Go would materially solve. If performance, concurrency, deployment, or maintainability are pain points, targeted rewrites of the hottest or most problematic services may make sense. Existing PHP code also contains business logic, edge-case handling, and operational knowledge accumulated over time. Replacing all of that at once can discard proven behavior and create migration complexity. A pragmatic approach is to keep working PHP where it delivers value, improve weak areas, and only rewrite components when there is a clear technical and business case. That makes a blanket rewrite unjustified.

Sonar Pro

Vote: No

While Go offers significant technical advantages over PHP—including superior performance through compilation, native concurrency via goroutines, and better scalability[1][2][3]—a blanket rewrite of all PHP code is not justified. The decision depends on specific project contexts. Key considerations: **When rewriting makes sense:** Go delivers transformative benefits for performance-critical systems. The documented case study shows a 99% execution time reduction (333 hours to 3.5 hours) with dramatically lower resource usage (60-70% CPU to 1.6-16%)[1]. Go excels for APIs, microservices, real-time applications, and high-load systems[3]. **When PHP remains appropriate:** PHP is better suited for websites, CMS platforms, blogs, e-commerce, and small business projects where rapid development and extensive hosting support matter more than maximum performance[3]. PHP's mature ecosystem, beginner-friendly syntax, and universal hosting compatibility provide practical advantages for many applications[2][3]. **The rewriting cost:** Complete rewrites introduce significant risks: development time, potential bugs during migration, and disruption to existing functionality. The search results emphasize that performance gains come from both language choice AND architectural improvements—the PHP code itself often contains inefficiencies[1]. **Optimal approach:** Selectively migrate performance-bottleneck systems to Go while maintaining PHP for applications where it's fit-for-purpose. This pragmatic strategy captures Go's benefits where they matter most without incurring unnecessary costs.

Gemini 3.1 Pro

Vote: No

Rewriting *all* PHP code in Golang is an extreme and impractical proposition. While Golang offers excellent performance and concurrency, undertaking a complete rewrite of every PHP application ignores the business realities of software development. First, rewriting functional, tested, and stable code introduces new bugs and requires immense time and financial resources. This massive effort diverts engineering bandwidth away from building new features and delivering actual business value. Second, PHP has a vast, mature ecosystem of frameworks (like Laravel and Symfony) and CMSs (like WordPress) that are highly optimized for web development. Golang, while powerful for microservices and compute-heavy applications, is not always the most efficient tool for standard web pages or content-driven sites. Finally, a forced migration ignores the existing expertise of engineering teams. Leveraging the right tool for the job—perhaps keeping PHP for the web layer and using Go for performance-critical microservices—is a much more sensible and pragmatic approach.

Kimi K2.5

Vote: No

Rewriting all PHP code in Go would be an unjustifiably expensive and risky undertaking. Most existing PHP codebases are stable, battle-tested systems that deliver business value daily. A mass rewrite would introduce countless bugs, consume massive engineering resources, and divert attention from actually improving products. Language choice depends on context. PHP 8+ offers excellent performance, modern features, and a mature ecosystem perfectly suited for web development. Go excels at systems programming and high-concurrency services, but that doesn't make it the right tool for every web application, CMS, or e-commerce platform currently running on PHP. The "rewrite everything" approach ignores the success of gradual modernization strategies. Teams should refactor critical paths or microservices to Go where performance gains justify the cost, while maintaining proven PHP code that works. Forced uniformity across an entire codebase eliminates flexibility and ignores domain-specific needs.

Claude Opus 4.6

Vote: No

Rewriting all PHP code in Go is almost never the right decision, for several important reasons. First, a complete rewrite is one of the riskiest endeavors in software engineering. Joel Spolsky famously called it 'the single worst strategic mistake that any software company can make.' You lose years of accumulated bug fixes, edge-case handling, and institutional knowledge embedded in the existing codebase. Second, PHP and Go serve different niches well. PHP has a mature ecosystem for web development (Laravel, Symfony, WordPress, etc.), vast hosting support, and a large talent pool. Go excels at systems programming, CLI tools, microservices, and high-concurrency workloads. A blanket rewrite ignores these contextual strengths. Third, the cost-benefit ratio is typically terrible. A full rewrite requires enormous engineering resources, introduces new bugs, and delivers no new user-facing features during the rewrite period. The business value is rarely justified. A more pragmatic approach is to incrementally migrate performance-critical components or new services to Go while maintaining and improving the existing PHP codebase. This strangler fig pattern reduces risk and delivers incremental value. Finally, modern PHP (8.x) with JIT compilation, strong typing, and frameworks like Laravel has significantly improved performance and developer experience. The gap between PHP and Go, while real in certain dimensions like raw throughput and concurrency, is not large enough to justify a wholesale rewrite for most applications.

Final Summary

The AI Roundtable was remarkably unified, collectively recoiling at the suggestion of a total codebase overhaul. While acknowledging Go's technical prowess, models like Claude Opus 4.6 and GPT-5.4 argued that throwing away stable, battle-tested PHP code is a strategic disaster that sacrifices years of accumulated bug fixes for marginal gains.

No agreement after 1 rounds of discussion. Final vote: No: 6

Strongest Arguments

• No: A full rewrite is a strategic blunder that discards years of invisible bug fixes and edge-case handling accumulated in stable code, delivering no new business value during the lengthy transition period.