Which languages can a Gatling simulation be written in, and does each of those languages get its own separate SDK?

Gatling's front page states that test scenarios are "defined as code using expressive SDKs for Java, JavaScript, TypeScript, Scala, or Kotlin". Five names, and each really is a language you can write a working simulation in. What that sentence does not say — and what an interviewer is usually probing — is that the five languages are delivered by **three** layers, not five. ## The three layers behind the five names | Layer | What it actually is | Languages it serves | |---|---|---| | Scala core | the `gatling-core`, `gatling-http`, `gatling-jms`, `gatling-jdbc` and related modules, written in Scala | Scala | | Java API | the `io.gatling.javaapi` packages, written in Java and shipped as `gatling-core-java`, `gatling-http-java` and friends | Java **and** Kotlin | | npm SDK | a family of packages published under the `@gatling.io` scope, released separately from the main repository | JavaScript **and** TypeScript | Two independent measurements back this up. First, the Gatling repository contains **zero Kotlin source files and zero TypeScript source files** — there is nothing there for a Kotlin-specific or TypeScript-specific SDK to be built from. Second, Gatling's documentation site configures its code-sample tabs with **four** labels (`java`, `ts`, `kt`, `scala`), and the `ts` tab is titled "JavaScript", because one sample serves both. ## What "no Kotlin SDK" actually means It does not mean Kotlin is second class. It means something more specific and more useful: * Kotlin calls the **same** classes and the **same** methods that a Java simulation calls, because both are calling the Java API directly. * Anything true of the Java surface is true of the Kotlin surface, including method names, argument types and return types. * Kotlin's only Gatling-specific accommodations are aliases for names that collide with Kotlin keywords, which exist precisely because the underlying API is Java's. * Nothing in the Java API requires you to read, write or compile Scala, even though the engine underneath it is Scala. The same logic applies at the other end: JavaScript and TypeScript are not two SDKs. They are one SDK, and TypeScript users get type declarations for the same package family a JavaScript user installs. ## The divergence that actually bites Because the Scala core and the Java API are two separate code bases, a snippet is not portable between them by copy and paste. The injection **step names** are the same across the layers — the same builder is called the same thing in Scala as in Java — but the surrounding spellings differ. The clearest example is the duration you hand a step: 1. Java and Kotlin take a `java.time.Duration`, for example `Duration.ofMinutes(5)`. 2. Scala takes a Scala duration literal, for example `5.minutes`. 3. JavaScript and TypeScript take an object literal of the form `{ amount: 5, unit: "minutes" }`. 4. All of them additionally accept a bare number, which is interpreted as **seconds**. The entry point that registers a scenario's profile is also spelled differently on the Scala side than on the Java side. So a stale answer copied from a Scala blog post will not compile in a Kotlin simulation, and vice versa — which is why it is worth being explicit about which language a Gatling example was written for rather than talking about "the DSL" as if there were only one. ## Why this matters when you are choosing When a team is comparing load generators, "supports five languages" is often written on the comparison sheet as a differentiator. Read it correctly: * If your team writes **Java or Kotlin**, you get a typed, compiled, IDE-completed API and the JVM build tooling you already run. That is the real benefit, and it is the same benefit for both languages. * If your team writes **JavaScript or TypeScript**, you get a package-manager install and a Node-shaped project, again the same for both. * If your team writes **Scala**, you get the core surface directly. * If your team writes none of those five, the language count buys you nothing. The count is not five independent investments Gatling maintains for you; it is three surfaces mapped onto five languages. Knowing that keeps you from asking a vendor question that has no answer — such as which release the Kotlin SDK is on — and keeps you from assuming that a Scala example is a Kotlin example with different punctuation. ## The claim to get right Say "five authoring languages over two JVM binding layers plus an npm SDK for JavaScript and TypeScript". Do not say "five SDKs", "five artifacts", or "a Kotlin SDK". Every one of those overstates what is shipped, and the first person who greps the repository for a Kotlin file will find nothing there to support it.