Go versus Laravel: kies op workload, niet op benchmark

Go en Laravel belanden vaak naast elkaar in een benchmark alsof het verwisselbare engines zijn. Dat zijn ze niet. Go is een gecompileerde taal met een runtime, standaardbibliotheek en ecosysteem. Laravel is een opinionated webapplicatieframework op PHP. Een eerlijke vergelijking begint daarom een niveau hoger: wat bouw je, waar stapelt complexiteit zich op, wat kent het team al en welke operationele kosten zijn het waard? Zodra die vragen expliciet zijn, blijkt de keuze meestal minder ideologisch dan hij eerst lijkt.

Zet eerst de vergelijking recht

Laravel geeft een webteam een samenhangend applicatiemodel: routing, middleware, validatie, hooks voor authenticatie en authorisatie, databasetoegang, migrations, queues, scheduling, mail, notifications, caching, testhelpers en een service container. De waarde is niet dat ieder onderdeel elders onmogelijk is. De waarde is dat ze met gedeelde conventies en documentatie komen.

Go geeft een team een taal en een kleiner platformoppervlak. De standaardbibliotheek bevat capabele HTTP-, JSON-, cryptografie-, test-, profiling- en database-interfaces, maar schrijft geen applicatiearchitectuur voor en levert geen Laravel-equivalent productframework. Een Go-team kiest zelf hoe routing, validatie, migrations, authorisatie, dependency construction, jobs en observability samenkomen.

Daardoor zijn vergelijkingen op basis van regels code vrijwel waardeloos. Een korte Laravel-controller kan leunen op echt en getest frameworkgedrag. Een korte Go-handler kan productievereisten hebben weggelaten in plaats van opgelost. De enige bruikbare vergelijkingseenheid is een complete capability met tests, failure handling, deployment en ownership.

Begin bij de plek waar complexiteit terechtkomt

Een klantenportaal, marketplace, intern operationsplatform en publieke API kunnen allemaal “backend” heten, terwijl hun grootste kostenposten sterk verschillen.

Laravel is een sterk startpunt wanneer complexiteit in productregels en breedte zit: accounts, permissions, forms, workflows, relationele data, adminhandelingen, notifications, geplande taken en integraties. Het framework comprimeert het gewone loodgieterswerk, zodat het team meer tijd kan besteden aan gedrag dat specifiek is voor de business.

Go wordt aantrekkelijk wanneer complexiteit in uitvoering zit: veel gelijktijdige netwerkoperaties, streaming, protocol handling, CPU-gevoelige verwerking, strikte memorybudgetten, snelle processtart, portable command-line tools of een service die bewust een klein oppervlak moet aanbieden. Go verwijdert domeincomplexiteit niet, maar kan concurrency en procesgedrag directer beheersbaar maken.

Productbreedte, CRUD, workflows, teams die snel bewegen
  -> Begin met Laravel

Veel fan-out-I/O, streaming, klein serviceoppervlak, strak runtimebudget
  -> Onderzoek Go

Een normale webapp met ongemeten angst voor toekomstige schaal
  -> Splits hem nog niet

Eén bewezen hotspot in een succesvol Laravel-systeem
  -> Meet, isoleer en overweeg daarna Go

Waar Laravel ontwikkelsnelheid laat opstapelen

Laravel’s voordeel is het grootst wanneer een feature meerdere applicatieonderdelen kruist. Denk aan iemand uitnodigen voor een organisatie: de request valideren, de actor authoriseren, membershipstate schrijven, een notification sturen, traag werk queueën, misbruik rate-limiten, een e-mail renderen en de response testen. Laravel biedt voor elk onderdeel een gedocumenteerd pad en consistente manieren om dependencies in tests te vervangen.

Eloquent kan relationeel productwerk snel uitdrukken. Form requests, policies, API resources, events, jobs en notifications geven teams gemeenschappelijke namen voor boundaries. Artisan-commands en frameworkconventies maken onbekende delen beter vindbaar. Een volwassen package-ecosysteem kan maanden ononderscheidend werk wegnemen voor authenticatie, billing, admininterfaces, search of OAuth.

Die snelheid is niet gratis. Frameworkconventies kunnen databasequeries, container resolution, event listeners en serialisatie verbergen. Eloquent maakt een N+1-query even makkelijk om te schrijven als om te repareren. Dynamisch PHP maakt snelle iteratie mogelijk, maar grotere codebases hebben gedisciplineerde types, static analysis, tests en modulegrenzen nodig om onbedoelde coupling te voorkomen.

Laravel is dus niet de “simpele” optie. Het is de optie die een grote geïntegreerde gereedschapskist koopt. Die investering rendeert wanneer de applicatie de gereedschapskist gebruikt en het team de boundaries zichtbaar houdt.

Waar Go de extra assemblage verdient

Go’s sterkste argument is niet dat iedere handler een microbenchmark wint. Het is dat de taal bepaalde eigenschappen op serviceniveau gewoon maakt.

Goroutines laten veel onafhankelijke operaties in een synchrone stijl uitdrukken. Context cancellation kan van een inkomende request doorlopen naar database- en outbound HTTP-calls. Interfaces kunnen dependencies klein houden zonder container. Static types maken veel interfacewijzigingen tijdens de build zichtbaar. De compiler levert vaak één zelfstandig executable op, wat packaging kan vereenvoudigen en het aantal runtimecomponenten in een image kan verminderen.

De toolchain is opvallend samenhangend: formatting, tests, fuzzing, benchmarks, profiling, tracing support, vulnerability checks en een race detector hebben standaard entry points. Die samenhang is waardevol voor infrastructuurservices, network-facing componenten, CLI’s en teams die minder keuzes op frameworkniveau willen.

De kosten verschijnen eerder in productontwikkeling. Het team moet validatie, migrations, authenticatie-integratie, authorisatiestructuur, jobsemantiek en andere conventies kiezen of bouwen die Laravel al verbindt. Dat werk over meerdere kleine services herhalen kan een intern framework creëren, maar dan met minder gebruikers, minder documentatie en een onderhoudslast die volledig bij het team ligt.

De concurrencymodellen veranderen de failure modes

Traditionele PHP-FPM-deployments geven een Laravel-request een sterk geïsoleerde lifecycle: het procesmodel en framework bouwen requeststate tussen requests opnieuw op of resetten die. Queue workers zijn long-lived en Octane houdt de applicatie bewust in memory. Beide vragen daarom aandacht voor static state, singletons, connections en memory die langer dan één werkeenheid blijft bestaan. Laravel’s documentatie benoemt deze long-lived-worker-risico’s omdat code die in een verse request onschuldig is, bij hergebruik state kan lekken.

Go-services zijn standaard long-lived en veel requests delen één proces. Goroutines delen een address space. Dat maakt gecoördineerde concurrency efficiënt, maar shared mutable data vraagt synchronization en ownership. Goroutines kunnen lekken wanneer ze eindeloos wachten, onbegrensde fan-out kan downstream services uitputten en een data race kan alleen bij een specifieke interleaving verschijnen. Go bevat een race detector, maar die vindt alleen races in codepaden die werkelijk worden uitgevoerd.

Geen van beide modellen is automatisch betrouwbaarder. Laravel maakt requestisolatie de gewone situatie en behandelt background concurrency als apart subsysteem. Go maakt concurrency een tool op taalniveau en vraagt de service om die te begrenzen. De juiste keuze hangt af van de vraag of concurrency centraal staat in de workload of slechts een implementatiedetail is.

Wees precies over performance

Voor rauw HTTP-werk, JSON-encoding of veel gelijktijdige sockets gebruikt een goed geschreven Go-service vaak minder resources en levert hij meer throughput dan een conventionele Laravel-deployment op dezelfde hardware. Die richting is gezien de execution models niet verrassend. Het is nog steeds geen capacity plan.

De meeste productendpoints wachten op een database, cache, paymentprovider, search engine of andere API. Het aantal queries, indexes, payloadgrootte, cachebeleid, connection pools en externe latency kunnen het verschil tussen runtimes domineren. Een endpoint met dezelfde N+1-query in Go herschrijven behoudt het dure onderdeel.

Laravel heeft bovendien meer dan één runtimemodel. PHP-FPM-, FrankenPHP- en Octane-deployments maken andere afwegingen. Go-services veranderen merkbaar door allocation patterns, garbage-collection-pressure, serialisatiekeuzes en concurrency limits. Een publieke frameworkbenchmark komt zelden overeen met de applicatie, data, middleware of failure modes die voor gebruikers tellen.

Een geloofwaardige vergelijking gebruikt het echte authentication path en representatieve databasedata. Meet throughput alleen naast p50-, p95- en p99-latency, memory per replica, CPU op target load, error rate, connectiongebruik, start- en shutdowngedrag en performance tijdens een trage dependency. Zet daarna het verschil in infrastructuurkosten af tegen engineering- en operationele tijd.

Als Laravel de latencydoelstelling met comfortabele headroom haalt, is een sneller synthetisch resultaat nog geen businessreden voor een rewrite.

Deployment is op verschillende manieren eenvoudiger

Laravel’s deploymentoppervlak is bekend maar bestaat uit meerdere delen. Productie heeft normaal een PHP-runtime met extensions nodig, een web- of application server, Composer-dependencies, configuratie en secrets, waar nodig writable storage, databasemigrations, queue workers en een scheduler. Long-running workers moeten tijdens deployment herstarten om nieuwe code te laden. Daartegenover staan een volwassen hostingecosysteem en breed bekende operationele patronen.

Go verpakt applicatiecode en dependencies vaak in één executable. Een minimal container kan klein zijn, startup is doorgaans snel en hetzelfde artifact kan HTTP serveren en signalen direct afhandelen. Maar “single binary” betekent niet “geen operations”. De service heeft nog steeds configuratie, certificaten, migrations, secrets, observability, health checks, veilige shutdown en compatible builds nodig wanneer cgo of externe assets een rol spelen.

Operationele eenvoud hangt af van het bestaande platform. Eén Go-service toevoegen aan een bedrijf met uitstekende PHP-deployment, logging en on-call-kennis kan de totale complexiteit vergroten. Het omgekeerde geldt net zo goed.

Betrouwbaarheid komt uit ontwerp, niet uit het logo

Beide stacks kunnen transactions, idempotency, een outbox, begrensde retries, graceful shutdown, structured logs, metrics, traces en health checks implementeren. Geen van beide levert automatisch exactly-once-delivery, correcte authorisatie of veilige schemawijzigingen.

Laravel’s defaults en conventies verminderen het aantal beslissingen vanaf een leeg vel, maar een developer kan nog steeds een job dispatchen voordat een transactie commit of een niet-idempotent side effect retryen. Go’s expliciete error handling en contexts maken control flow zichtbaar, maar errors kunnen nog steeds worden genegeerd en cancellation kan nog steeds breken door detached work te starten.

De zinvolle vraag is welke failure modes het team kan herkennen en opereren. Een bekend Laravel-systeem met goede queue monitoring is veiliger dan een theoretisch efficiënte Go-service die niemand kan diagnosticeren. Een gerichte Go-service met profiles, begrensde concurrency en duidelijke ownership kan veiliger zijn dan een streamingworkload door een applicatiemodel duwen dat ertegen vecht.

Beide gebruiken kan verstandig zijn, maar de boundary moet huur betalen

Een vaak gezonde vorm is een modulaire Laravel-monolith die users, permissions, productworkflows, billingstate en back-office-operations bezit, met Go voor één smalle execution-heavy capability zoals mediaverwerking, high-volume ingestion, een protocolgateway of fan-out-aggregatie.

Die splitsing werkt alleen met duidelijke ownership. Definieer de source of truth, API- of eventcontract, authenticatie tussen services, timeout- en retrybudgetten, idempotency, observability, deploymentownership en het gedrag wanneer een van beide kanten onbeschikbaar is. Als twee services voor iedere businessactie synchrone calls nodig hebben en dezelfde tabellen delen, zijn ze niet betekenisvol onafhankelijk.

Introduceer Go niet alleen om de architectuur schaalbaar te laten ogen. Een tweede taal voegt nog een toolchain, dependencybeleid, security-updatepad, container, dashboard, runbook en on-call-skillset toe. De nieuwe boundary moet meer complexiteit verwijderen dan creëren.

Voer een keuze-experiment uit, geen debat

Kies één representatieve vertical slice en leg de acceptatiecriteria vast vóór de implementatie. Neem authenticatie, validatie, één realistische query, serialisatie, een outbound dependency, logging, metrics, tests, containerbuild, graceful shutdown en een deployment mee. Load-test het success path en een pad met trage dependency.

Leg daarna vier soorten bewijs vast:

• User outcomes: latencydoel, betrouwbaarheid en gedrag tijdens failures
• Resource outcomes: CPU, memory, connections en aantal replicas op target load
• Delivery outcomes: implementatietijd, duidelijkheid van tests, reviewinspanning en change lead time
• Ownership outcomes: deployability, debugging, upgrades, security response en on-call-confidence

Het resultaat kan Go nog steeds bevoordelen op runtimekosten of Laravel op ontwikkelsnelheid, maar de trade-off hoort nu bij jouw systeem in plaats van bij de benchmark van iemand anders. Dat is de vergelijking die de moeite waard is.

Praktische checklist

• Benoem de workload voordat je de technologie benoemt
• Vergelijk complete productiepaden, geen hello-world-handlers
• Neem ontwikkel- en operationele kosten mee
• Meet de echte applicatie met realistische dependencies
• Kies standaard Laravel voor productbreedte tenzij een constraint anders vraagt
• Kies Go wanneer concurrency, resourcegebruik of distributie echt de constraint is
• Introduceer beide alleen over een stabiele ownershipgrens