By Danny van Kooten

Jumping from PHP to Go: Blasphemy, Bravado or Common Sense?

By Danny van Kooten

This post about moving from PHP to Go was first published elsewhere, and republished here with the author’s permission.

A gopher chasing an elephpant away

Earlier this year, I made an arguably bad business decision. I decided to rewrite the Laravel application powering Boxzilla in Go.

No regrets though.

Boxzilla platform page

Just a few weeks later I was deploying the Go application. Building it was the most fun I had in months, I learned a ton, and the end result is a huge improvement over the old application. Better performance, easier deployments and higher test coverage.

The application is a fairly straightforward database driven API & account area where users can log-in to download the product, view their invoices or update their payment method.

Stripe and Braintree are used to accept subscription payments. Invoices are handled using MoneyBird and some transactional emails are sent using Mailgun.

While Laravel worked well enough for this, some things always felt overcomplicated to me. And what’s with releasing a new “major” version every few months? I’d be fine if the newer versions contained significant improvements, but a lot of the times it just felt like minor naming & directory structure changes to me.

Why Go?

Last year I’ve been moving several services over to Go, so I wasn’t completely new to the language. As a developer selling WordPress based products, part of my job is working in an ancient tech stack that is mostly focused on the end user.

If I weren’t self-employed, I would simply apply for a new job to make up for this lack of sexy tech. Being my own boss, I owe it to myself to make my day-to-day work fun and not just chase more immediate $$$. If revenue allows (and it does), why not have a little fun?

It’s a joy to write Go code, the tooling is amazing and it’s not only fast to develop in, the end result is usually crazy fast too. Just reading about the purpose of the Go project sold me on the language.

I think we’ll see a good amount of people switching from dynamically typed languages like PHP, Python and JavaScript to Go in the next few years.

Porting the Codebase

Migrating the code to Golang consisted mostly about getting the database interaction right & porting the Blade templates to something we could use in Go.

ORMs are one thing that always ends up getting in my way, so I went for a mockable data access layer and plain SQL queries. Meddler was used to get rid of some of the boilerplate for scanning query results into structs.

To support hierarchical templates and partials I open-sourced grender, a tiny wrapper around Go’s standard html/template package. This allowed me to port the Blade template files to Go with relative ease, since I could use the same hierarchical structure and partial templates.

For integrating with Stripe there is the official stripe-go package. For Braintree there is the unofficial braintree-go package, which was neglected for a little while but received renewed attention lately. Since there was no Go package to manage invoices in Moneybird yet, I built and open-sourced moneybird-go.


Comparing Apples vs Oranges

Since Go is a compiled language with a much better standard library than PHP, it is not really fair to compare the two languages like I am about to. That said, I thought it would be fun to share some numbers.


wrk was used to perform some simple HTTP benchmarks for both applications returning the HTML for the login page.

Concurrency Avg. latency Req / sec Transfer / sec
Laravel 1 3.87ms 261.48 1.27MB
Laravel 100 108.86ms 917.27 6.04MB
Go 1 325.72μs 7365.48 34.27MB
Go 100 11.63ms 19967.31 92.91MB
Go 200 37.68ms 22653.22 105.41MB

Unfortunately, the Laravel application (or PHP-FPM socket) kept falling over once I increased the number of concurrent “users” past 100.

NetData provided the following graphs to see how the server was holding up under all this load.

Golang with 100 concurrent connections
Go with 100 concurrent connections

Laravel with 100 concurrent connections
Laravel with 100 concurrent connections

Please note that I ran the benchmark from the same machine as the applications were running on, so this heavily influences both graphs.

Lines of Code

Let’s compare the lines of code in both applications, including all vendor dependencies.

find . -name '*.php' | xargs wc -l
156289 total

The Laravel version consists of just over 156.000 lines of code. This is excluding development dependencies which, with Laravel, are needed to run tests etc.

find . -name '*.go' | xargs wc -l
33624 total

The Golang version on the other hand consists of 33.000 lines of code. That’s one fifth of the code for exactly the same functionality.

Let’s exclude external dependencies in the Laravel application so we know how much lines were actually written by me.

find . -name '*.php' -not -path "./vendor/*" | xargs wc -l
13921 total

And for Golang.

find . -name '*.go' -not -path "./vendor/*" | xargs wc -l
6750 total

The result is slightly more even when just looking at managed lines of code. Still, it’s the exact same application with half the amount of code.

Test Coverage

Testing is a first class citizen in Golang, and test files live right next to the actual source files.


This makes it incredibly convenient to apply test driven development.

In our Laravel application we mostly had integration tests that checked whether the request handlers returned a proper response. Overall test coverage was quite low, mostly due to tight coupling which in turn was mostly my fault. Writing the same application a second time really helps here too.


I did something you should never do: rewrote an application in a different language because I felt like it. Had lots of fun and got a much smaller and faster application in return.

  • Victor Osas Ighalo

    Great job. You took a hard task and u completed it. Bravo!
    I only wonder how the plug-in written in Go will be compiled to work in WordPress

    • Hey, it’s actually not the plugin itself that was rewritten in Go but the website that handles selling the plugin licenses (subscriptions) & plugin updates.

  • Zhilevan Ibra

    Not interested. you keep your way. good luck :D

    • Todd Zmijewski

      Agreed. You’re better off going with a JavaScript stack. Everyone is eating that shit up these days. Go has a limited shelve life. No large w lol known PHP projects will be switching to go. Waste of time.

      • Hah, absolutely disagree but to each his own. Enjoy your JavaScript stack.

  • brzuchal

    Those are not the ways of counting LOC!

  • Michel Chouinard

    The article isn’t bad but the title should be:

    “Jumping from Laravel ( PHP ) to Go: Blasphemy, Bravado or Common Sense?”.

    The point is that you went from a BIG PHP Framework to a completely different programming language. Laravel isn’t suitable for all projects, it’s a tool like others. There are so many framework in PHPland that you could use for such a simple task. Think of Slim ( ) for example.

    You could even use plain PHP with some libraries for routing, etc…
    Use of PHP 7 also…

    P.S.: I do not have anything against Go. Mather of fact it’s in my learning goal path this year.

    • Such a simple task? I didn’t really say anything about the scope of
      the application but please know that this is a full blown application
      utilising most of Laravel’s features like routing, event listeners, Blade templates,
      Eloquent, Redis queues, etc. Sure it could be build using Slim and hand-picked libraries, but I
      doubt the performance would be much better than it would be using

      But you’re absolutely right that this is comparing
      apples vs. oranges. The article clearly states that too. People
      shouldn’t really take these numbers seriously, it’s just fun to
      benchmark the exact same application built in 2 different ways.

  • Excellent that you switched. Hope more open source applications written in PHP do the same. Especially next cloud.

  • Stef Pe

    I’m so sorry but this article isnt worth a penny. You’re counting lines of a full blown web framework and compare it with a native go lang implemented app. You’re also talking about strict typing, did you ever check php7?
    The only thing I agree on this article is, that go uses less memory and is able to serve more requests, but everyone knows that….
    Regarding the future you should be careful with switching to go, because php is improving really a lot currently and php8 is going to have a jit, so performance will get better. For all my running php apps in real world, there is a caching layer, so performance is not the problem, most developers have more problems by designing database structures or profiling their code to find bottlenecks…

    • I know, but PHP is still an interpreted language and it really helps
      to have a compiler do your type checking for you instead of it happening
      at runtime. Not to mention the enormous performance bonus.

      Not sure what’s unfair about counting the same application built in two different ways. The Go application has dependencies too, which are included in the LOC count…

      anyway, you really shouldn’t be switching or rewriting your application
      for just any of these reasons. I had time and I wanted some fun, and
      fun it was.

  • The Informer

    To solve your PHP-FPM problem, this could be the issue:

    In config file:

    Increase this variable to your concurrency level (e.g. 1024):
    pm.max_children = 1024

    this is for Ubuntu 16.04.2 LTS with php7.1

  • really interesting is always great if you can compare a real world application..maybe you could write it in node and java and post the results :D

  • Mistajolly

    Rewriting any application would normally result in a better design. Was there any particular aspect of the original Laravel application that went through a significant change in the porting process?

  • De Pi

    Hi, this so great, may I ask how it possible deploy Go to shared hosting likes PHP ? is it a drawback ?

Get the latest in PHP, once a week, for free.