Die beliebtesten Programmiersprachen 2025

(spectrum.ieee.org)

16 Punkte von GN⁺ 2025-09-29 | 8 Kommentare | Auf WhatsApp teilen

Python > Java > C++ > SQL > C# > JavaScript > TypeScript > C > Shell > Go > R > PHP > Kotlin > Rust > Dart > Swift
Laut der Untersuchung von IEEE Spectrum belegt Python auch in diesem Jahr Platz 1, während JavaScript von Platz 3 auf Platz 6 fällt
Diese Veränderung wird damit in Verbindung gebracht, dass JavaScript, das stark in der Webentwicklung genutzt wird, zunehmend durch AI-gestütztes Coding (z. B. vibe coding) verdrängt wird
Traditionelle Kennzahlen wie die Anzahl der Stack-Exchange-Fragen oder die GitHub-Aktivität sind seit der Einführung von AI stark zurückgegangen, wodurch die bisherigen Methoden zur Messung der Sprachpopularität ins Wanken geraten
Mit der breiten Verfügbarkeit von AI-Codegenerierung nimmt die Bedeutung von Syntax- und Strukturunterschieden zwischen Sprachen ab, und der Trend, sich nicht auf eine bestimmte Sprache zu versteifen, wird deutlicher
Das erschwert das Auftauchen neuer Sprachen und die Verbreitung ihrer Ökosysteme und deutet letztlich darauf hin, dass das Konzept der Popularität von Programmiersprachen selbst verschwinden könnte

Überblick

IEEE Spectrum hat die Ergebnisse einer umfassenden Analyse der wichtigsten Programmiersprachen und Trends für 2025 veröffentlicht
Das Ranking berücksichtigt verschiedene Perspektiven wie Arbeitsmarkt, Open-Source-Ökosystem, akademische Nutzung und Einsatz in der Industrie
Zusätzlich werden Merkmale der wichtigsten Sprachen, Hintergründe ihres Wachstums sowie Informationen zu nach Fachgebieten spezialisierten Sprachen bereitgestellt

Sprachranking dieses Jahres

Im Spectrum-Basisranking 2025 bleibt Python auf Platz 1, während JavaScript auf Platz 6 zurückfällt
Auch im Jobs-Ranking steht Python auf Platz 1, und SQL behält weiterhin eine starke Wettbewerbsfähigkeit auf dem Arbeitsmarkt
Die Gesamtzahl der Stack-Exchange-Fragen zu Programmiersprachen ist gegenüber 2024 auf 22 % gesunken

Kriterien für die Ranking-Berechnung

Popularität: Sie wird anhand verschiedener Online-Foren, Software-Repositories, Stellenmarktdaten und Suchtrends berechnet
Praxisrelevanz: Auf Basis von Stellenausschreibungen und der Beteiligung an Open-Source-Projekten wird analysiert, welche Sprachen im realen Markt häufig genutzt werden
Fachspezifische Analyse: Berücksichtigt werden Kriterien zur Auswahl besonders auffälliger Sprachen in Teilbereichen wie AI, Embedded, Web und Mobile
Zur Messung der Popularität wurden verschiedene Indikatoren genutzt, darunter Google-Suchvolumen, Stack-Exchange-Fragen, GitHub-Aktivität und Erwähnungen in wissenschaftlichen Arbeiten
Da Entwickler Probleme zunehmend durch Gespräche mit LLMs (ChatGPT, Claude usw.) lösen, gehen öffentlich sichtbare Datensignale jedoch zurück
Dank AI-Tools wie Cursor sinkt schon die Zahl der Fragen selbst, wodurch die Aussagekraft bisheriger Kennzahlen abnimmt

AI verwischt die Grenzen zwischen Sprachen

Da sich sowohl erfahrene Entwickler als auch Einsteiger auf AI verlassen, nimmt die Aufmerksamkeit für Syntax und Kontrollstrukturen von Programmiersprachen ab
Mit ausreichend Trainingsdaten kann AI Code in praktisch jeder Sprache erzeugen
Dadurch könnte die Wahl der Sprache zu einem sekundären Faktor werden, ähnlich wie Unterschiede zwischen CPU-Befehlssätzen in der Hardware
Künftige Debatten über die Popularität von Sprachen könnten zu einem Nischenthema auf dem Niveau von Vergleichen von Eisenbahnspurweiten werden

Das Auftauchen neuer Sprachen wird noch schwieriger

Früher konnten sich Sprachökosysteme allein mit Büchern, Demos und Beispielcode verbreiten (z. B. The C Programming Language)
AI benötigt jedoch große Mengen an Trainingsdaten, weshalb neu entstehende Sprachen bei der Unterstützung benachteiligt sind
Tatsächlich wurde berichtet, dass AI bei weniger verbreiteten Sprachen schlechtere Ergebnisse liefert
Das könnte ein Umfeld schaffen, in dem es für neue Sprachen schwer ist, eine kritische Masse zu erreichen

Die Zukunft des Programmierens

Moderne Sprachen erfüllen im Kern zwei Aufgaben: Abstraktion der Datenverarbeitung und Vermeidung von Entwicklerfehlern
Der Fortschritt bei AI ermöglicht jedoch zunehmend einen neuen Ablauf: Prompt → Zwischensprache → Ausführung statt Fokus auf Sprachstrukturen
In diesem Fall könnte sich ein Ansatz etablieren, bei dem Quellcode nicht mehr gepflegt und geändert, sondern durch Anpassung des Prompts neu erzeugt wird
Die Rolle künftiger Programmierer dürfte sich weniger auf Sprachsyntax als auf Architekturdesign, Algorithmusauswahl und Systemintegration konzentrieren

Fazit und Ausblick

Das Programmieren erlebt derzeit den größten Umbruch seit dem Aufkommen von Compilern in den 1950er-Jahren
Selbst wenn ein Teil der AI-Blase platzt, dürfte der Einsatz von LLMs zur Unterstützung beim Schreiben von Code bestehen bleiben
Deshalb könnte das Konzept der „beliebten Sprache“ ab 2026 selbst an Bedeutung verlieren, und es werden neue Kennzahlen zur Messung von Popularität nötig sein

8 Kommentare

skrevolve 2025-10-09

Python ist allerdings auf dem Rückzug

shakespeares 2025-10-01

Bisher ist das Ökosystem von JavaScript noch deutlich breiter, aber ich denke, dass es durch KI Spielraum für eine Verlagerung hin zu Low-Level-Sprachen wie Rust gibt.

GN⁺ 2025-09-29

Hacker-News-Kommentar

Mit Hilfe von AI kümmern sich Programmierer immer weniger um bestimmte Sprachen oder Details, aber am Ende ist es ihr Schicksal, dass ein kleines Problem mit allen möglichen Komplexitäten verknüpft ist und sie wieder tief hineingräbt. Nicht jeder strebt wie ein Code-Golfer von ffmpeg nach der Assembler-Ebene, aber es gibt wohl einen Grund, warum Programmiersprachen der dritten Generation weiterhin präsent sind. Letztlich ist es ein Trade-off zwischen Ausdruckskraft und Präzision, also eine Frage des Gleichgewichts zwischen dem, worauf wir uns konzentrieren wollen, und den Details, die wir delegieren möchten. Wenn man für schnellere Resultate die Brille (Transparenz) aufgibt, braucht man eine robuste alternative Sonde, mit der man überprüfen kann, was danach passiert.
- Man sollte berücksichtigen, dass dieser Artikel von der IEEE stammt. Die Zielgruppe der IEEE sind eher Wissenschaftler als Programmierer. Aus Sicht von Wissenschaftlern ist Code ein Mittel, um ihre Ideen auszudrücken, und wenn sie ihre Ideen möglichst schnell ausdrücken können, kümmern sie sich wenig darum, ob der Code unordentlich ist oder wiederverwendet werden kann. Zum Beispiel erwähnen Wissenschaftler Arduino als Sprache, und für sie ist das etwas Natürliches. Wissenschaftler, die Arduino verwenden, kennen nicht unbedingt C++, sind aber stolz darauf, dass sie in „Arduino“ programmieren können.
- Das sind eindeutig sehr unterschiedliche Fälle. Wenn ein Compiler für eine bestimmte Architektur ein falsches Ergebnis liefert, kann man einen Bug-Report einreichen und Hilfe aus der Community oder von außen bekommen. Solche Dinge sind bei populären Bibliotheken oder Sprachen tatsächlich selten, und wenn man sich in so grenzwertige Bereiche vorwagt, bedeutet das ohnehin, dass man mit solchen Edge Cases umgehen kann. Wenn AI aber ein falsches Ergebnis liefert, muss man alles selbst herausfinden. Man kann OpenAI oder Anthropic nicht einfach fragen: „Warum macht ihr das?“ Im ersten Fall kann es manchmal in Ordnung sein, etwas nicht zu wissen, im zweiten Fall absolut nicht.
- Wenn den meisten Entwicklern die CPU-Befehlssätze oder die Eigenheiten der Hardware wirklich egal wären, hätte man sich die Generierung von Sprachsyntax gespart und direkt Maschinencode für die Chip-Architektur erzeugt. Vielleicht hätte man sogar nur Prompts hochgeladen und eine AI-VM den Ziel-Maschinencode erzeugen lassen. Eines Tages könnte das so sein, aber im Moment leben wir ganz sicher nicht in so einer Zeit.
- AI in Bereichen einzusetzen, die man nicht gut kennt, ist wirklich gefährlich, und ich finde nicht, dass man das fördern sollte.
- Sie haben lediglich das „breite Brett über dem Abgrund“ verlängert.
Eine gute Quelle für solche Daten zu finden, ist sehr schwierig. Auch StackOverflow ist im Abwärtstrend, und die Methodik der IEEE ist immerhin halbwegs realistisch, aber alle verwendeten Datenquellen haben ihre eigenen Mängel. Die Anzahl der Google-Suchergebnisse ist das volatilste indirekte Signal. Suchergebnisse enthalten fast alles, was die betreffende Anfrage erwähnt, und es gibt keine Garantie, dass das tatsächlich für 2025 repräsentativ ist. Menschen, die eine Sprache benutzen, sagen normalerweise auch nicht explizit „Programmiersprache X“. Die gesamte mediale Sichtbarkeit als Sichtbarkeit einer „Top-Sprache“ zu zählen, ist konstruiert. TIOBE verwendet diese Methode ebenfalls und gibt die Popularität unverfroren mit zwei Nachkommastellen an. Betrachtet man ältere Daten, dann halbierte sich die Popularität von „C“ innerhalb von nur zwei Jahren und verdoppelte sich im nächsten Jahr wieder. Im realen Markt hatte sich jedoch überhaupt nichts verändert. Die Fehlerrate dieser Methode liegt bei ±50 %.
- Um die tatsächliche Nachfrage nach Sprachen zu messen, sind Stellenanzeigen-Daten am praktischsten und nützlichsten. Diese Daten zeigen zwar nicht direkt die Menge an Code, die tatsächlich in Unternehmen läuft, aber in den meisten Fällen geben sie den direktesten Einblick in reale Nutzung, Nachfrage und Branchentrends. Wenn es große Organisationen gibt, wie etwa Banken mit COBOL, in denen kaum jemand den Job wechselt, taucht das möglicherweise nicht in den Daten auf, aber trotzdem gibt es kaum eine bessere Datenquelle.
- Solche Quellen sind oft selbstverstärkend und selbstreferenziell. Man hält es für besser, das beste Tool zu verwenden, das Tool, das man selbst am besten kennt, oder das Tool, das Kunden wollen oder das am meisten Umsatz bringt. Ada, COBOL, FORTH, Lua und andere passen in diesen Kontext. Abgesehen von SEO ist Popularität letztlich kein besonders aussagekräftiges Maß.
- Bei TIOBE ist Perl dieses Jahr plötzlich in die Top 10 gekommen, aber ich habe noch nie einen neuen Perl-Entwickler gesehen. Mit Ada ist es ähnlich. Ich frage mich, wo all die Ada-Entwickler eigentlich sind.
- Was ich an solchen Statistiken mag, sind Sprachstatistiken nach öffentlichen GitHub-Repositories. Dort gibt es seit 2012 für jede Sprache Zahlen zu öffentlichen Repos und PRs.
- Vielleicht sind LLM-Abfragestatistiken inzwischen sogar die beste Datenquelle. Im Hauptartikel (TFA) wird das auch ausführlich behandelt.
Ich dachte, JavaScript würde auf Platz 2 stehen, aber offenbar hat TypeScript ihm den Rang abgelaufen. Persönlich sehe ich JavaScript und TypeScript fast als dieselbe Familie, daher finde ich, dass man ihre Werte zusammenrechnen sollte.
- Bei solchen Auswertungen sollte man beide zusammenfassen, erst dann wäre es wirklich Platz 2.
- Diese beiden sollten auf jeden Fall zusammengelegt werden, und außerdem verstehe ich nicht, warum Arduino in dieser Liste enthalten ist.
- Sehe ich auch so, es gibt sicher noch weitere Einträge, die man zusammenfassen müsste, und es wäre auch sinnvoll, BEAM-basierte Sprachen als eine Gruppe zu behandeln.
- Wenn man auch Java & Kotlin oder C & C++ zusammenlegen würde, wäre JS&TS vielleicht gar nicht auf Platz 2.
Wer überrascht ist, dass Java so weit oben steht: Habt ihr vielleicht eure ganze Karriere nur nodejs-Backends in 10-Personen-Startups gebaut? Habt ihr noch nie in Großunternehmen gearbeitet, besonders nicht in Enterprise-Software-Firmen?
- Java ist inzwischen das neue COBOL. Der Großteil der Finanz-, Versicherungs- und Gesundheitsbranche ist schon vor Jahrzehnten auf Java aufgesprungen und migriert bestehenden COBOL-Code weiterhin nach Java.
- Es gibt auch etwas Seltsames daran. Ich habe über fünf Jahre bei Google gearbeitet und weiß aus Statistiken, dass es dort enorm viel Java-Code gibt, aber ich selbst habe vielleicht nur dreimal direkt Java-Code angesehen. Es wirkt so, als würde Java viel genutzt, aber in Unternehmen in isolierten Bereichen. Irgendwo in einem bestimmten Abschnitt der wirtschaftlichen Wertschöpfungskette scheint es abgeschottet zu sein.
- Wer über den hohen Rang von Java erstaunt ist, arbeitet wahrscheinlich nicht im Finanzbereich. Natürlich heißt Enterprise nicht automatisch Java; es gibt auch große Unternehmen außerhalb des Finanzsektors, in denen Microsoft, .NET und C# dominieren.
Ich arbeite als Fintech-Backend-Entwickler und finde es schwer, eine sinnvolle Zielsprache für einen Wechsel zu finden. Ich habe mit Node und Ruby gearbeitet, aber das Fehlen eines statischen Typsystems hat mich immer wieder gestört. Auch TypeScript hat mit Dingen wie der non-strict-Option seine Grenzen. Sprachen wie Java/.Net oder Go wirken altmodisch, Rust klingt spannend, passt aber nicht so recht zu meinem Hintergrund. Mich würde interessieren, ob jemand eine empfehlenswerte Sprache nennen kann.
- Wenn du im Fintech bleiben willst, bleiben im Grunde nur Java, C#, C++, TypeScript und Ähnliches. Etwas außerhalb davon gibt es gelegentlich auch Unternehmen mit Haskell, F# oder Scala. Solche Sprachen werden oft für Workflow-DSLs verwendet. Falls dich Array-Sprachen interessieren: Der Finanzbereich ist eines der wenigen Felder, in denen sie noch leben. Solche Stellen sind allerdings schwer zu finden. Dyalog (APL), J, BQN, Kdb+ (Q) sind ebenfalls einen Blick wert, ebenso die Arraycast-Ressourcen.
- Scala ist die beste Sprache, die ich je benutzt habe. Sie vereint die Vorteile von TypeScript mit den Stärken von Java und Rust. Außerdem ist Fintech eine der wenigen verbliebenen Nischen, in denen man mit Scala noch einen Job finden kann.
- Rust ist eine universelle Sprache, also kann man damit alles machen. Aber wie immer gilt: Das richtige Werkzeug ist entscheidend. Das Ökosystem ist der Knackpunkt, und wichtig ist, was du konkret entwickeln willst.
- Ich habe gerade dieselbe Überlegung und habe das Gefühl, dass Gleam am besten passt. Es verbindet die Einfachheit von Go mit dem Komfort von Kotlin.
- Java ist langsam, aber die Syntax wird besser, und es bildet das Rückgrat vieler mittelgroßer und großer Unternehmen. In kleinen Firmen findet man eher JS, Ruby oder Python, vermutlich weil dort Produktivität und Engineering-Kosten stärker zählen. Dadurch kommt es zu dem Effekt, dass interpretierte Sprachen bei der Nutzung Enterprise- und Performance-Sprachen übertreffen.
Die Umfrage sagt, dass es mehr Nutzer von PHP und Ruby als von HTML gibt, und schon dass HTML überhaupt als Programmiersprache auftaucht, erscheint fragwürdig. Auch dass Elixir unter OCaml liegt, überrascht mich. Ich habe schon große Unternehmen mit Elixir gesehen, aber OCaml schon länger nicht mehr.
- Vielleicht kam dieses Ergebnis zustande, weil nur wenige Menschen bei „Programmiersprache, die ich benutze“ HTML auswählen.
- Als meine Kollegen aus dem ersten Job, alles Java-Entwickler, im Park tranken und die Polizei sie nach ihrem Beruf fragte, antworteten sie „Programmierer“. Der Polizist reagierte darauf mit: „Ach so, HTML also.“
- Auf die Frage, ob PHP und Ruby mehr Nutzer als HTML haben: Nach meiner Erfahrung gibt es viel mehr Backend-/Systementwickler als Frontend-Entwickler, etwa im Verhältnis 3:1 bis 20:1. Das hängt von der Unternehmensgröße ab, aber wenn man nur Backend macht, kann es gut sein, dass man mit HTML fast nie zu tun hat. Selbst bei webzentrierten Diensten gibt es in der Praxis viele Leute, die HTML gar nicht anfassen.
- HTML ist streng genommen schon eine Programmiersprache, wird aber fast nie allein verwendet. Dass HTML als eigener Eintrag in der Liste auftaucht, ist etwas sinnlos.
- Jeder lebt in seiner eigenen Bubble. Ich halte Scala immer noch für eine sehr populäre Sprache.
Ich finde es immerhin erfreulich, dass Haskell überhaupt im Ranking auftaucht, auch wenn es ungefähr auf dem Niveau von LabView liegt, was etwas schockierend ist. Der Artikel selbst ist allerdings nicht besonders interessant.
- Haskell ist immerhin eine interessante Sprache. Ich freue mich auch, dass meine Lieblingssprache Julia dieses Jahr in der Liste steht. Das ist ein Zeichen dafür, dass es für interessante Sprachen noch Hoffnung gibt. Nach der SoC-Zusammenarbeit von Intel und NVIDIA werden Python und C++ die Liste wohl auch künftig weiter dominieren.
- Schon der Vergleich von Haskell mit LabView ist ziemlich unfair.
Ich frage mich, was „Arduino“ eigentlich sein soll. Wenn damit das DIY-Arduino gemeint ist, das wir alle kennen, dann ist das keine „Sprache“, sondern einfach C++.
- In der Arduino-Dokumentation wird zwar von einer eigenen „Arduino programming language“ gesprochen, aber in Wirklichkeit ist das nur C++ mit ein paar zusätzlichen typedefs. Warum, weiß ich auch nicht.
- Das ist derselbe Kontext, in dem HTML und CSS als Sprachen klassifiziert werden oder Bibliotheken für C/Fortran als „Python“-Bibliotheken bezeichnet werden.
- Diese Unterscheidung ist seltsam und mindert die Glaubwürdigkeit des Diagramms. Wenn man das so macht, müsste man konsequenterweise auch die Punkte von C++ dazurechnen.
Ich hatte einen ähnlichen Gedanken und habe mich gefragt, ob LLM-Assistenten die heutigen Programmiersprachen verfestigen werden. Nach meinen Tests gilt: Je populärer eine Sprache ist, desto besser kommt ein LLM damit zurecht, vermutlich wegen der Menge an Trainingsdaten. Dadurch könnte es noch schwerer werden, neue Sprachen einzuführen. Wenn ins LLM-Training nur objektorientierter Code eingeflossen wäre, wäre die Entwicklung anderer Paradigmen vermutlich schon jetzt deutlich schwerer.
- Ich habe kürzlich mit einer weniger bekannten Sprache wie Hare gearbeitet, und Claude war dabei trotz Halluzinationen nützlicher als klassische Suchmaschinen. Deshalb habe ich das Gefühl, dass LLMs vielleicht doch keinen so großen Einfluss auf die Verfestigung von Sprachen haben, wie man denkt.
- Nach meiner Erfahrung kommen LLMs mit populären Sprachen besser zurecht, aber nicht nur das: Sie wiederholen auch unnötig oft Antworten, die bekannte Sprachen oder Tools verwenden. Wenn man sie darauf hinweist, korrigieren sie sich mit etwas wie: „Stimmt, das ist nicht unbedingt nötig. Ich gebe Ihnen ein klareres und passenderes Beispiel …“ Es wäre schön, wenn sie das gleich von Anfang an täten, aber der Code ist oft unnötig komplex. Wenn man kein erfahrener Entwickler ist, ist es schwer, solche Dinge herauszufiltern. So landet dann merkwürdiger Code im Git-Repo oder sogar in Deployments. Man bekommt fast den Eindruck, als hätten große Unternehmen ihre eigenen Plugins oder ihren eigenen Code in die erste Antwort hineingedrückt. Diese Struktur könnte in Zukunft ein sehr ernstes Problem werden. Die Werbebranche dürfte bei diesem Trend schon sabbern, und wenn künftig Werbung in LLM-Modelle einfließt, wird das ein noch größeres Problem.
  - Ich hoffe auf offene Modelle, bei denen Trainingsdaten und Gewichte klar offengelegt sind und sich per reproducible-build-Ansatz, ähnlich wie mit Nix, anpassen lassen.
  - Es braucht Möglichkeiten, Modelle in der Inferenzphase zu debuggen, etwa über transparente Elemente wie Tags.
  - Ich frage mich, ob es Verfahren zur formalen Verifikation von Modellinferenz gibt.
- Die Hürden für die Einführung neuer Sprachen werden tatsächlich höher werden. Aber schon jetzt gibt es für Nischen-Sprachen im Wesentlichen nur diese Gründe:
  1. vorhandene Codebases und Bibliotheken
  2. Orte, an denen sich Experten eines bestimmten Fachgebiets sammeln. Nur weil LLMs gut in Java sind, wird nicht plötzlich jeder Java verwenden. Spaß oder Lebenslaufgründe sind noch einmal etwas anderes.
- Eine populäre Sprache zu wählen, war schon immer vorteilhaft, etwa für die Rekrutierung. Eine weniger populäre Sprache zu wählen, war immer ein Risiko, und das ist auch heute noch so.
Dass Python auf Platz 1 steht, finde ich eher frustrierend. Meiner Erfahrung nach möchte ich Python außer für Skripte oder Solo-PoCs kaum verwenden. Ich könnte mir nicht vorstellen, Python für Code mit mehr als 1.000 Zeilen, für Projekte mit mehreren Maintainers oder für Programme einzusetzen, deren Ausführung länger als ein paar Sekunden dauert. Dadurch, dass Python an US-Universitäten zur Standardsprache für Nicht-Informatiker geworden ist, tragen viele kluge Leute zum Ökosystem bei. Ich wünschte aber, diese Anstrengungen würden stattdessen in andere Sprachen oder robustere kompilierte Sprachen fließen. Ich empfehle kompilierte, statisch typisierte Sprachen mit Unterstützung für Multithreading.
- Stimme ich vollkommen zu. Ich nutze es wirklich nur für Skripte. Letztes Jahr wollte ich etwas ML machen, habe Python aber so gehasst, dass ich nach einem Monat aufgegeben habe. Ich verstehe nicht, warum Ruby nicht populärer ist. Weil Python zur Standard-Erstsprache geworden ist — bei mir war es genauso — würde ich eher Ruby empfehlen.
- Sehe ich genauso. Python fühlt sich „matschig“ an. Die statisch typisierten, kompilierten Sprachen, die ich kenne, sind Rust, C und C++, und jede hat ihre eigenen Nachteile. Ein C mit dem Tooling von Rust und einem Modulsystem wäre großartig.
- Auch die Syntax ist nicht besonders gut. Vielleicht funktioniert es gut genug, aber es ist einfach keine interessante Sprache.

3ae3ae 2025-09-29

JS und TS sind fast dieselbe Sprache, daher frage ich mich, ob man sie nicht zusammenfassen sollte.

beoks 2025-09-29

Es ist schon etwas seltsam, dass HTML in der Rangliste auftaucht.

jjpark78 2025-09-29

Ich kann kaum glauben, dass Java auf Platz 2 ist.

passerby 2025-09-29

Java und C# sind damals wie heute der Standard in Enterprise-Webserver-Umgebungen.