Programmeertalen in het AI-tijdperk: een greenfield-reset

Oorspronkelijk geschreven voor het onderzoeksproject programming-languages-ai-era.

De vraag die senior engineeringleiders moeten kunnen verdedigen

Als je vandaag een nieuw project zou starten, welke taal zou je dan kiezen? En hoe verdedig je die keuze nu AI-agents een steeds groter deel van de code schrijven?

De meeste teams grijpen naar de taal die ze al in productie draaien. Volgens mij stelt dat de vraag verkeerd. Rangschik tien talen op elf gewogen dimensies onder een bewuste greenfield-framing, zonder krediet voor de installed base en zonder zwaartekracht van de gevestigde taal, en het resultaat dat senior lezers verrast is dit: TypeScript en Go delen de top op 4.01, het gezamenlijke plafond van het cohort op gewogen totaal, maar de sterkste toekomstinzet van het cohort is .NET, dat vandaag 0.02 lager staat op 3.99 en de hoogste score van het cohort draagt op weerbaarheid tegen afhankelijkheidsrisico (4.5, geen andere taal haalt dat) plus de hoogste reachability-score van het cohort (4.5, eveneens alleen). Vrijwel niemand positioneert het zo. Ik wel, en de rest van dit stuk is het betoog dat ik zou houden tegenover een CTO die tegengas geeft.

Waarom een greenfield-reset

Een greenfield-framing is een bewuste beperking, geen naïviteit. Redeneren vanuit de installed base beantwoordt een andere vraag, namelijk hoe je onderhoudt wat er al staat, en beloont een andere set eigenschappen: legacy-zwaartekracht, vertrouwdheid in de trainingsdata, de kosten van porten. Senior leiders die die eigenschappen hun beslissingen over nieuwe projecten laten sturen, breiden uiteindelijk een landschap uit dat ze vandaag niet meer zouden beginnen.

De greenfield-framing zet de onderhoudsvraag tussen haakjes en stelt de strategische vraag: welke toekomstgerichte eigenschappen wil je, als je vandaag een nieuw project voor het AI-tijdperk start, onder de AI-agents hebben die meer van de code gaan schrijven dan je mensen? De dimensies die ertoe doen zijn de kwaliteit van governance, toekomstbestendigheid, vertegenwoordiging in het AI-trainingscorpus, de snelheid van het ecosysteem en de weerbaarheid van dragende afhankelijkheden. De dimensies die er niet toe doen zijn de hoeveelheid code die al geschreven is en de traagheid van de gevestigde taal.

Critici zullen dit lezen en zeggen dat ik de legacy-realiteit negeer. Dat doe ik niet, ik zet haar tussen haakjes. Onderhoudslandschappen vragen om andere rekensommen, en dat zeg ik expliciet: teams wier hoofdtaak het onderhouden van grote bestaande landschappen is, moeten de gewichten herzien, en dan verschijnt legacy-zwaartekracht in die vraag weer als voordeel. Dit is die vraag niet.

Als installed base alleen voldoende was om strategische levensvatbaarheid te dragen, zou het schrappen van legacy-krediet de score van geen enkele gevestigde taal hebben verschoven. Het verschoof er meerdere.

Thomas Kuhn noemde het een paradigmawisseling en bedoelde iets smallers dan het woord is gaan betekenen. Dit is de smalle versie: de vraag veranderde, dus de oude antwoorden hielden op bewijs te zijn.

De elf dimensies

Ik scoor tien talen, C++, .NET, Elixir, Go, Java, Kotlin, Python, Rust, Swift en TypeScript, op elf gewogen dimensies, elk op een schaal van 1.0 tot 5.0 in stappen van 0.5. De dimensies groeperen zich netjes:

• Cognitie. Human Cognition (15%), leesbaarheid en governance, en Machine Cognition (15%), hoe schoon compilers, analyzers en AI-systemen over de code kunnen redeneren.
• Agentic. AI-Agent Operability (20%), hoe schoon een AI-codeeragent door de code kan navigeren en haar kan bewerken, testen en verifiëren. De zwaarst gewogen dimensie.
• Runtime. Runtime and Ecosystem (10%) en Strategic Viability (5%). Kan het productiesystemen draaien, en blijft het relevant.
• AI-systems. AI-Systems Native (7.5%), wat de steward van de taal zelf first-party levert, en AI-Systems Ecosystem (7.5%), wat derden leveren.
• Structured output. Structured-Output Native (5%) en Structured-Output Ecosystem (5%). Schema-gevalideerd parsen en het genereren van schema’s uit types, opnieuw gesplitst in een steward-helft en een ecosysteem-helft.
• Risico. Ecosystem Dependency Risk (5%), de weerbaarheid van het maintainerschap van dragende libraries, waarbij hoger een lager risico betekent, en Reachability to Top Tier (5%), de plausibiliteit dat elke cel onder de 5 binnen een horizon van 3 tot 5 jaar wordt gesloten.

De splitsing native/ecosysteem is de methodologische keuze die het meeste werk doet. Een 5.0 met Microsoft erachter leest niet hetzelfde als een 5.0 met drie open-source-vrijwilligers erachter. De as van afhankelijkheidsrisico legt het verschil in de huidige toestand vast; de reachability-as legt het verschil in traject vast.

De matrix en de rangorde

Taal	HC	MC	AO	RE	SV	AIN	AIE	SON	SOE	EDR	RCH	Gewogen
TypeScript	4	4	5	4	4	1.5	5.0	2.5	5.0	3.0	4.0	4.01
Go	5	4	5	4	4	2.0	3.5	3.0	3.0	3.5	3.5	4.01
.NET (C#)	4	4	4	4	4	4.0	3.5	4.0	3.5	4.5	4.5	3.99
Kotlin	4	4.5	4	4	4	3.0	3.0	3.5	3.0	4.0	4.0	3.85
Python	4	3	4	5	4	1.5	5.0	2.5	5.0	2.5	3.5	3.71
Rust	3	5	4	4	5	1.5	4.0	2.0	4.0	3.5	3.5	3.71
Java	3	4	3.5	4.5	3	2.0	4.0	3.0	3.5	4.0	3.5	3.50
Swift	4	4	3	4	3	4.0	2.0	4.0	2.0	3.5	3.0	3.42
Elixir	4	3	3	4.5	3	3.0	2.0	1.5	2.5	3.0	2.5	3.10
C++	2	3	2	4	2	2.5	3.0	1.0	2.0	3.0	2.0	2.46

Drie dingen om op strategisch niveau te lezen. De top is dicht opeengepakt: TypeScript en Go delen het cohortplafond van 4.01, .NET staat 0.02 daarachter op 3.99, Kotlin 0.16 daarachter op 3.85, vier talen binnen een band van 0.16. Het midden is gelaagd: Python en Rust delen 3.71 (0.30 achter de koplopers, vijfde en zesde in het cohort), Java alleen op 3.50, Swift alleen op 3.42, elk 0.08 tot 0.21 van zijn buren gescheiden. De onderkant staat alleen: Elixir op 3.10 en C++ op 2.46, de enige twee talen onder 3.42 en respectievelijk de enige twee onder 3.10, met een gat van 0.64 punt ertussen dat geen enkel ander buurpaar in de matrix evenaart. De compressie aan de top is het interessantere strategische feit: de koploper is een inzet met drie opties, geen winnaar.

Drie bevindingen die er op strategisch niveau toe doen

Bevinding A: de top is een inzet met drie opties, geen enkele winnaar

Go, TypeScript en .NET zitten binnen 0.02 van elkaar op gewogen totaal, drie talen binnen een band van 0.02, met de dichtstbijzijnde buur (Kotlin op 3.85) nog eens 0.14 lager. Het zijn niet dezelfde inzet, en ze als uitwisselbaar behandelen is de duurste fout in het cohort.

Go is de inzet op backend-services. Zijn sterkste afzonderlijke score is Human Cognition, hoe makkelijk code voor een mens te lezen en op schaal te besturen is, waar het HC=5 haalt, alleen aan het cohortplafond, met zes andere talen een trede lager op 4, dankzij een bewust klein oppervlak. Het haalt ook het cohortplafond op AI-Agent Operability, hoe schoon een AI-codeeragent door de code kan navigeren en haar kan bewerken, testen en verifiëren, met AO=5, op kracht van go build, go test, go vet en go mod als één canoniek commando-oppervlak, gofmt als de enige canonieke formatter en gopls als de officiële implementatie van het Language Server Protocol. AO=5 deelt het alleen met TypeScript; geen andere taal haalt het plafond op AI-agent-operability. De agent-loop sluit sneller op Go dan op welke andere taal in het cohort ook. Het grootste deel van de dragende infrastructuur van de Cloud Native Computing Foundation, etcd, containerd, Helm, Prometheus, Kubernetes zelf, is in Go geschreven. Als de komende vijf jaar draaien om backend-systemen die op schaal door agents worden geschreven en aangepast, is Go de platforminzet die rendeert.

TypeScript is de inzet op AI-applicatiewerk. Het raakt het cohortplafond op AI-Systems Ecosystem, wat derden leveren voor AI-integratie, met AIE=5.0, alleen gedeeld met Python; geen andere taal haalt het, en de eerstvolgende zijn Java en Rust samen op 4.0. De libraries eronder zijn de officiële TypeScript-SDK van Anthropic, de OpenAI Node SDK, LangChain.js, de officiële MCP TypeScript SDK met Anthropic als mede-steward en een TypeScript-distributie van LlamaIndex. Het deelt ook met Python het cohortplafond op Structured-Output Ecosystem, wat derden leveren voor het parsen van LLM-output, met SOE=5.0; de eerstvolgende is Rust op 4.0. De libraries eronder zijn Zod als de facto standaard voor schemavalidatie, de Vercel AI SDK met generateObject en streamObject, en zod-to-json-schema dat tool-call-definities voedt. TypeScript en Python zijn de enige twee talen in het cohort die op beide ecosysteem-helften het plafond raken; geen andere taal haalt een van beide. Als de komende vijf jaar worden gedomineerd door AI-versterkte applicatieoppervlakken, chatinterfaces, agent-orkestratie, structured-output-pipelines, dan is TypeScript de platforminzet die rendeert.

.NET is de inzet op het toekomstige traject. Het raakt het cohortplafond op AI-Systems Native, wat de steward van de taal zelf first-party levert, met AIN=4.0, op kracht van Microsoft Semantic Kernel, Microsoft.Extensions.AI (dat in de .NET 9-distributie landde), ONNX Runtime .NET en de MCP C# SDK, die Microsoft samen met Anthropic onderhoudt. AIN=4.0 deelt het alleen met Swift; geen andere taal haalt het, en de eerstvolgende zijn Kotlin en Elixir op 3.0. Het neemt ook de hoogste score van het cohort op Ecosystem Dependency Risk met EDR=4.5, alleen aan het plafond; de eerstvolgende zijn Java en Kotlin samen op 4.0. Vrijwel het hele dragende AI-oppervlak, runtime, taal, AI-primitieven, structured-output-oppervlak, MCP, is Microsoft-first-party. Het neemt ook de hoogste score van het cohort op Reachability to Top Tier met Reach=4.5, eveneens alleen aan het plafond; de eerstvolgende zijn TypeScript en Kotlin samen op 4.0. Microsoft investeert in elke cel onder de 5, met een jaarlijkse cadans van grote releases. .NET is de enige taal in het cohort die beide kronen pakt, het EDR-plafond en het Reach-plafond, en geen andere taal draagt er een van. Als de komende vijf jaar concentratie van stewardship en leveranciersgebonden supply chains belonen, is .NET de platforminzet die rendeert.

De CTO-framing is direct: als je verkeerd inzet op welke workload gaat domineren, zet je verkeerd in op de taal. Het redelijke antwoord is niet er één te kiezen en te doen alsof de andere niet bestaan. Het is weten welke workload je platform werkelijk draagt, en daarnaar kiezen.

Deze bevinding is fout als een vierde workloadklasse, accelerator-gebonden of fouttolerant, blijkt te domineren. In dat geval herordenen Rust of Elixir de vraag. De matrix legt de inzet bloot; ze doet niet alsof ze die wegneemt.

Bevinding B: afhankelijkheidsrisico is reëel en vrijwel niemand prijst het in

Pydantic heeft meer macht over de AI-positie van Python dan Microsoft over die van .NET. Dat is geen metafoor. Het is een structureel feit, en de meeste teams prijzen het niet in.

De Structured-Output Ecosystem-score van Python is 5.0, het cohortplafond, gedeeld met TypeScript en door geen andere taal geëvenaard. De score rust op Pydantic, Instructor en Outlines. Pydantic wordt onderhouden door een kleine groep actieve contributors, niemand fulltime in dienst op het project, niemand gesteund door een commerciële leverancier; de Rust-kern (pydantic-core via PyO3) is zelf een meertalig supply-chain-artefact dat op dezelfde kleine groep rust. Instructor heeft één maintainer (Jason Liu). Outlines is klein-commercieel. De samengestelde score op Ecosystem Dependency Risk voor Python is 2.5, alleen op de cohortvloer voor EDR. Geen andere taal zit onder 3.0; de eerstvolgende laagste zijn TypeScript, Elixir en C++ samen op 3.0.

Het contrast met .NET is het punt. De Structured-Output Native van .NET is 4.0 (cohortplafond, alleen gedeeld met Swift) uit System.Text.Json met source generators en JsonSchemaExporter, allemaal onder stewardship van Microsoft. De AI-Systems Native van .NET is 4.0 (ook cohortplafond, alleen gedeeld met Swift) uit Semantic Kernel, Microsoft.Extensions.AI en ONNX Runtime .NET, allemaal onder stewardship van Microsoft. EDR=4.5, alleen aan het cohortplafond. Als één Pydantic-maintainer morgen vertrekt, heeft het AI-applicatieverhaal van Python een probleem. Als één Microsoft-engineer morgen vertrekt, heeft het AI-applicatieverhaal van .NET dat niet.

Dezelfde lens geldt verderop in de matrix. TypeScripts EDR=3.0 zit in het onderste derde deel van het cohort (alleen Pythons 2.5 is lager) en wordt teruggehouden door de concentratie op één maintainer bij Zod: Colin McDonnell draagt de last, en het stewardship van Microsoft over TypeScript strekt zich niet uit tot Zod. De EDR=3.0 van C++, gedeeld met TypeScript en Elixir op de op één na laagste trede, mengt commerciële first-party-steun van CUDA en ONNX Runtime met concentratie op één maintainer bij llama.cpp (Georgi Gerganov) en nlohmann/json (Niels Lohmann). Dragende libraries met één maintainer zitten één bus-factor-gebeurtenis verwijderd van een strategisch probleem.

Senior teams denken al zo over cloudleveranciersconcentratie: multi-region, multi-account, exit-kostenanalyse. Dezelfde lens geldt voor library-stewardship, en vrijwel geen enkel team past haar toe. Het sterkste bezwaar is “maar ons team kan het forken.” Dat bezwaar is waar de meeste architecture decision records ophouden, en het klopt niet meer zodra de fork in dezelfde week een CVE-respons, een API-drift upstream en een SDK-wijziging van een frontier-model moet opvangen.

Deze bevinding is fout als community-multi-maintainer onder druk weerbaarder blijkt dan stewardship door één leverancier. De empirische onderbouwing daarvoor is dun. Als Pydantic vóór 2027-05-02 drie extra actieve maintainers krijgt, gaat de EDR van Python omhoog en trekt de these zich samen rond de libraries die dat niet deden.

Bevinding C: reachability scheidt “waar het staat” van “waar het heen gaat”

Een rangorde van de huidige toestand is een momentopname. De dimensie Reachability scoort de plausibiliteit van het traject: hoe bereikbaar is 5.0 op elke cel onder de 5 binnen een horizon van 3 tot 5 jaar. Voor platforminzetten van vijf jaar weegt reachability zwaarder dan de rangorde van dit jaar.

.NET staat vandaag op #3 op gewogen totaal maar alleen op #1 op Reach met 4.5, het cohortplafond, dat geen andere taal haalt. Microsoft investeert in vrijwel elke cel onder de 5 in de .NET-rij, met een jaarlijkse cadans van grote releases die het traject ondersteunt. De toekomstinzet is de sterkste in het cohort, ook al blijft het gewogen totaal van vandaag slechts 0.02 achter op de koplopers.

C++ staat vandaag op #10 op gewogen totaal en alleen op #10 op Reach met 2.0, de laagste trajectscore die ik aan enige taal toeken, met de eerstvolgende (Elixir op 2.5) een half punt hoger. De druk rond memory safety stapelt zich op tegen C++ vanuit vier instituties die op dezelfde conclusie uitkomen. De Software Memory Safety Cybersecurity Information Sheet van de Amerikaanse National Security Agency adviseert weg te bewegen van memory-onveilige talen en noemt C en C++ expliciet. Het rapport Back to the Building Blocks van het Amerikaanse Office of the National Cyber Director herhaalt dat advies op het beleidsniveau van de uitvoerende macht. Het Security Response Center van Microsoft rapporteert dat ongeveer 70% van de door Microsoft toegewezen CVE’s memory-safety-problemen zijn. Het Chromium-project rapporteert onafhankelijk dat ongeveer 70% van de ernstige beveiligingsbugs memory-safety-bugs zijn: andere codebase, ander team, hetzelfde getal. Android-telemetrie laat zien dat memory-safety-kwetsbaarheden afnemen naarmate nieuwe native code verschuift naar memory-veilige talen. De meeste cellen van C++ onder de 5 zijn structureel aan het taalontwerp en sluiten niet binnen de planningshorizon.

Het andere uiteinde van de matrix laat dezelfde logica zien. TypeScript en Kotlin scoren allebei Reach=4.0, samen tweede achter .NET, onder stewardship van een leverancier, met zichtbare paden om gaten te dichten. Elixir scoort Reach=2.5: set-theoretische types zitten nog in onderzoek, de voetafdruk van het ecosysteem is klein, het gat is breed; alleen C++ zit lager. Reachability is de dimensie die vage claims over het toekomstige traject afstraft en specificiteit beloont.

Deze bevinding is fout als een taal zonder leverancier als steward een structurele stapverandering levert, een Python-typesysteem dat at runtime wordt afgedwongen, een first-party AI-runtime voor Rust, die de Reach-scoring niet had voorzien. De kans is niet nul. Ik leg toch een getal vast, omdat een trajectclaim die weigert zich vast te leggen geen claim is.

Drie voorspellingen waarop ik over 12 maanden beoordeeld wil worden

Ik schrijf acht falsifieerbare voorspellingen, elk met een datumstempel, elk met een meetbare controle, elk gekoppeld aan een frameworkscore. Drie dragen het meeste signaal voor senior lezers:

1. Pydantic krijgt vóór 2027-05-02 ten minste drie actieve maintainers erbij, of de EDR van Python zakt richting 2.0 in de volgende grote frameworkrevisie. De controle zijn de GitHub-statistieken over maintainer-activiteit voor pydantic/pydantic: het aantal gemergde PR’s per maintainer over zes maanden.

2. Microsoft levert vóór 2027-11-02 een first-party Anthropic SDK voor .NET, wat de AIN van .NET met ten minste 0.5 verhoogt. De controle is een repository onder microsoft/ of Anthropic/ met een .NET SDK-label en attributie aan Microsoft-engineering.

3. Het greenfield-aandeel van C++ in beveiligingsgevoelige domeinen blijft jaar op jaar dalen tot en met 2027-05-02. De controle zijn de genoemde industrie-enquêtes, CNCF, JetBrains, RedMonk, GitHub Octoverse, beperkt tot het greenfield-signaal waar de enquête dat uitsplitst.

De beoordeling gebeurt in het openbaar. Het v1.1-reviewmoment is 2027-05-02, waarbij elke voorspelling wordt gemarkeerd als opgelost (ja / nee / gedeeltelijk). Als een voorspelling tegen mijn commitment in uitpakt, dien ik de scorecorrectie in en leg ik het nieuwe bewijs vast. Als het totale slagingspercentage van de voorspellingen onder de 60% zakt, zijn de dimensiegewichten en de rubriekankers het eerste wat ik herzie.

Een framework waarvan de voorspellingen uitkomen, verdient het recht om een mening te hebben. Een framework waarvan de voorspellingen missen, moet opnieuw worden verankerd.

Wat het framework kan ontkrachten

Eerlijke grenzen, in volgorde van hoe waarschijnlijk elk de matrix verschuift.

De gewichten zijn werkaannames. Een redelijke senior lezer kan runtime/ecosysteem zwaarder wegen (in het voordeel van Python en de JVM-talen), AI-Agent Operability zwaarder (in het voordeel van Go en TypeScript), afhankelijkheidsrisico zwaarder (in het voordeel van .NET en Java) of reachability zwaarder (in het voordeel van .NET en de talen onder leveranciers-stewardship). De matrix is robuust tegen kleine verstoringen van de gewichten. Niet tegen grote.

De scores zijn kalibratie door één beoordelaar. Fase 2 van het v1.0-plan introduceert scoring door meerdere beoordelaars. Als die scoring cellen oplevert met meer dan 0.5 verschil, herzie ik liever dan dat ik het verschil verberg.

De splitsing native/ecosysteem is gevoelig voor hoe “steward van de taal” wordt gedefinieerd. Randgevallen, CUDA als taal-van-de-stack voor accelerators, de relatie van Dashbit tot de governance van Elixir, zitten op de grens. Ik trek de grens bij de entiteit die de canonieke toolchain van de taal levert en de aanroepen documenteert.

Als je me een dragende claim kunt laten zien die fout is, verschuif ik de score. Dat is de inzet.

Tot slot

De greenfield-matrix zegt dat de koplopers gelijk staan, dat het traject aan .NET toebehoort en dat de supply chain grotendeels onzichtbaar is. Kies de inzet die je over vijf jaar kunt verdedigen, niet die je maandag kunt verdedigen.

Abonneer je op rutgerhemrika.substack.com voor de stukken 2 tot en met 8: de splitsing TypeScript-of-Go, de Python-paradox, de .NET-sleeper, memory safety als regulatoire druk, de afhankelijkheidsrisico-these over het hele cohort, reachability als discipline voor toekomstinzetten en de acht voorspellingen waarop ik beoordeeld zal worden. Wil je de onderliggende data, claims en bronnen, dan staat het framework open op github.com/hemrika/programming-languages-ai-era.

---

Kies eerst de workload, dan de taal, en verdedig de inzet op de cellen, niet op het totaal.

And now for something completely different: een talenranglijst die de zittende taal geen krediet geeft voor het feit dat ze geïnstalleerd is. De uitkomst irriteerde precies de mensen die ze moest irriteren.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• Monty Python’s Flying Circus: “And now for something completely different”.
• Thomas Kuhn, The Structure of Scientific Revolutions (1962): paradigm shifts.