Your backend engineers are fluent in Kotlin and you must pick a load generator. Which of Gatling's properties should actually decide that, and which should not?

This is a decision with no single right answer, so the discipline is in separating the properties that change how a team works from the ones that merely sound decisive on a comparison sheet. ## Start by discounting the reason you were given "Our engineers write Kotlin" is the premise, and it is the weakest of the real arguments. Gatling supports five authoring languages across three delivery layers, and Kotlin is not one of the layers — Kotlin simulations call the Java API directly, so a Kotlin team and a Java team are looking at the same method surface. What the premise genuinely buys you is narrower and worth stating precisely: * The load code compiles in a **JVM build the team already runs**, with the same dependency management, the same CI runners and the same review process. * A mistake is a **compile error**, not a run that starts and misbehaves. * Nobody has to learn Scala, even though the engine underneath is Scala. That is real, and it is a genuine reduction in friction. It is not, by itself, a reason to choose one generator over another — several generators can be driven from a JVM build. ## The properties that should decide it 1. **Load is program text.** The injection profile is a chain of builders in a source file next to the scenario, so changing a ramp is a reviewed diff with an author and a reason. This is the property that determines whether load profiles decay quietly over a year or stay owned. 2. **The run carries its own verdict.** Assertions attached to `setUp` are evaluated after the run and a failure exits `2`, so the pipeline stage is a plain command invocation with no bespoke scoring step to maintain. That removes a whole class of home-grown fragility. 3. **The engine is asynchronous.** Virtual users are not backed by one operating-system thread each, so concurrency on the generator is not governed by a thread count. Note the shape of this claim: it removes a specific limit, it does not promise capacity. 4. **Everything lives in one repository.** Scenario, profile and pass rule sit together in a project the service team already owns, which is the thing that makes the tests survive a reorganisation. ## The costs you must price at the same time | Cost | What it means in practice | |---|---| | Narrow output contract | the exit status is the machine-readable result; the report is for people and the raw log must not be parsed | | No built-in metric streaming | cross-run trending and live dashboards are something you build or buy | | Single-generator runs | Community Edition does not spread one profile over several machines; that is an Enterprise capability | | A build is required to change load | anyone who needs to alter a profile must be able to edit, build and run a JVM project | The last row is the one that most often decides against the tool, and it has nothing to do with the tool's quality. If the people who need to change the load profile are the service engineers, the build requirement is free. If they are a separate performance team, or testers without a JVM toolchain, you have just made every change a pull request against a repository they do not own. ## What should not decide it * **The advertised language count.** Five supported languages is not five investments; it is three surfaces. You will use exactly one. * **That the engineers could learn the other languages.** Capability is not the constraint; maintenance is. Pick one surface and write the house examples in it. * **Quoted capacity figures.** A "users per machine" number with no workload attached describes someone else's scenario — which is exactly why Gatling's own FAQ attaches one. It names protocols, resource usage, user actions and script optimisation as the factors, and conditions every figure it quotes: 64,000 users per second on a local machine *if one user equals one request*, limited by the operating system rather than by Gatling, and up to 40,000 virtual users per second or the equivalent of 300,000 requests per second on an Enterprise EC2 generator. Discount a number that arrives without its workload, not one that arrives with it. * **The presence or absence of a graphical editor in an alternative.** That is a proxy for the real question — who edits the profile — and you should ask the real question instead. ## How to conclude State the decision as a conditional, because that is what it is. If the load profile will be owned by the engineers who own the service, and the pipeline needs a verdict rather than a metrics feed, the structural properties line up and Kotlin fluency makes the on-ramp short. If the profile will be owned by people outside the build, or the organisation already needs cross-run trending on day one, the same properties are working against you and the honest answer is that you would be buying a reporting layer alongside the tool. Then commit to one surface, write the house examples in it, and put a real assertion in the first pipeline stage — because a load test that cannot fail is the failure mode this decision most often produces.