Programmiersprachen

Einordnung

Dieses Dokument bewertet Programmiersprachen, die unter den bisher festgelegten MUSS-Randbedingungen für dieses Projekt grundsätzlich infrage kommen.

Wichtige Annahmen für dieses Dokument:

Die Datenerfassung auf Smartphones (iOS/Android) bleibt Teil des Gesamtsystems, wird aber für die Programmiersprachenwahl des Kernsystems nicht berücksichtigt, da ein MDM vorhanden ist und mobile Apps organisationsweit verwaltet und auch am App-Store vorbei verteilt werden können.

Die Programmiersprachenwahl wird daher auf diese Umgebungen konzentriert:

Windows-Clients (Windows 10/11 LTSC) für Analyse, Führung, Datenmanagement und Visualisierung
Serverbetrieb on-premise, mindestens unter Debian (falls Linux genutzt wird)
optional: Windows-Server (z. B. in Umgebungen mit Thin-Clients)

Relevante Randbedingungen stehen in:

Konsequenz aus der Architektur-Tendenz

Aus den bisherigen Dokumenten ergibt sich als Tendenz:

Windows-Arbeitsplätze und Lageanzeigen profitieren stark von einem Web-UI (Browser oder Desktop-Shell mit Web-UI).
Der Serverteil ist on-premise zu betreiben und muss langfristig wartbar sein (Jahrzehnte, Hauptamt-Betrieb).
Offline-Installation, Updates, nachvollziehbare Artefakte sowie die Umsetzung gemäß BSI IT-Grundschutz sind zwingend.

Damit ist für das Kernsystem ein Multi-Language-Stack realistisch: mindestens eine UI-Technologie plus mindestens eine Servertechnologie. Dieses Dokument bewertet Sprachen daher nach ihrer typischen Rolle.

Kandidaten

(Nur Sprachen, die die MUSS-Kriterien grundsätzlich erfüllen)

TypeScript / JavaScript

Typische Rolle:

UI auf Windows (Edge/Firefox), inklusive Kiosk-/Lageanzeigen
optional: Serverdienste mit Node.js (nicht zwingend)

Vorteile:

Sehr großes Ökosystem und viele UI-Komponenten
Einheitliche UI über Windows-Clients und Anzeigen möglich
Gute Eignung für modulare Oberflächen (Analyse, Visualisierung)

Nachteile:

Supply-Chain-Risiken durch große Dependency-Trees; muss aktiv beherrscht werden (Lockfiles, Mirrors, Scans, Signierung)
Serverseitig sind Enterprise-Betrieb, Observability und Security gut machbar, aber stark von Disziplin und Standards abhängig

Eignung im Projekt:

Sehr wahrscheinlich als UI-Sprache (Browser-UI) gesetzt oder zumindest stark bevorzugt.

Hier gibts mehr zu TypeScript.

C# / .NET

Typische Rolle:

Serverdienste (Windows und Debian)
Windows-nahe Client-Komponenten (falls kein reines Browser-UI)
Betrieb in typischen Verwaltungs- und Enterprise-Umgebungen

Vorteile:

Sehr großes Ökosystem und viele Dienstleister
Sehr gute Windows-Integration, starke Toolchain
Serverseitig auch unter Linux gut betreibbar
Gute Wartbarkeit bei klarer Architektur, gut geeignet für lange Lebensdauer

Nachteile:

Wenn zu viel Windows-spezifische Technik genutzt wird, sinkt die Portabilität nach Debian (muss bewusst vermieden werden)
Abhängigkeit von Framework- und Runtime-Lebenszyklen erfordert eine disziplinierte LTS-Strategie

Eignung im Projekt:

Sehr starker Kandidat für Serverkern und ggf. Desktop-Clients.

Java (JVM)

Typische Rolle:

Serverkern auf Debian, modularer Monolith naheliegend
optional: Desktop-nahe Komponenten (selten zwingend)

Vorteile:

Sehr großes Ökosystem, besonders im Behörden-/Enterprise-Umfeld
Reife Betriebs- und Observability-Toolchains
Langfristig stabile Plattform, geeignet für jahrzehntelange Systeme
Viele erfahrene Entwickler und Dienstleister verfügbar

Nachteile:

UI auf Windows ist möglich, in der Praxis aber oft unattraktiver als modernes Web-UI (meist eher Rollentrennung als echter Nachteil)
Laufzeit kann ressourcenintensiver sein als sehr schlanke Binaries, ist on-premise aber typischerweise gut beherrschbar

Eignung im Projekt:

Sehr starker Kandidat für den Serverkern.

Kotlin (JVM)

Typische Rolle:

Alternative zu Java für Serverkern oder einzelne Module
besonders dort sinnvoll, wo moderne JVM-Features gewünscht sind

Vorteile:

JVM-kompatibel kann in denselben Betriebsmodellen laufen wie Java
Moderne Sprache, gute Lesbarkeit, gute Entwicklerproduktivität

Nachteile:

Entwicklerpool in Behördenprojekten typischerweise kleiner als Java (aber im JVM-Umfeld gut anschlussfähig)
Einige Teams bevorzugen aus Supportgründen „Plain Java“

Eignung im Projekt:

Kandidat, wenn JVM gesetzt ist und Kotlin bewusst als Standard akzeptiert wird. Sonst: Java als konservativere Basis.

Go

Typische Rolle:

Serverdienste auf Debian, Hilfsdienste, Gateways, lokale Dienste
attraktiv, wenn sehr einfache Deployments priorisiert sind

Vorteile:

Sehr einfache Deployments (einzelne Binaries möglich)
Gute Performance und überschaubare Laufzeitumgebung
Toolchain relativ einfach, Betrieb gut beherrschbar

Nachteile:

UI muss separat gelöst werden (typisch: TypeScript im Browser)
Entwicklerpool und Dienstleisterbasis im Behördenumfeld oft kleiner als bei Java/.NET
Für sehr große Fachsysteme braucht es disziplinierte Architektur, sonst droht ein „großer Monolith ohne Struktur“

Eignung im Projekt:

Guter Kandidat für Serverteile, wenn der Betrieb maximal simpel bleiben soll und ausreichend Know-how gesichert ist.

Python

Typische Rolle:

Automatisierung, Import/Export, Werkzeuge, Analyse-Hilfstools
optional: bestimmte Serverkomponenten (mit disziplinierter Packaging- und Security-Strategie)

Vorteile:

Sehr großer Entwicklerpool und riesiges Bibliotheksangebot
Sehr produktiv für Werkzeuge und Datenverarbeitung
Gut für Prototyping und Hilfsdienste

Nachteile:

Packaging und Offline-Deployment können komplex sein, wenn es als Kernserver eingesetzt wird (muss hervorragend standardisiert werden)
Für sehr langfristige Kernsysteme ist die Wartbarkeit stark von konsequentem Engineering abhängig (Dependencies, CVEs, Wheels)

Eignung im Projekt:

Sehr sinnvoll als Neben-/Tool-Sprache.
Als Kernserver möglich, aber im Behördenbetrieb oft risikoreicher als Java/.NET, wenn Support über Jahrzehnte gedacht werden muss.

C / C++

Typische Rolle:

Spezialkomponenten, performancekritische Module, Treibernähe
optional: sehr schlanke lokale Dienste oder Kiosk-Software

Vorteile:

Sehr stabiler Unterbau, sehr lange Lebensdauer
Maximale Kontrolle über Ressourcen, sehr hohe Performance
Viele Entwickler vorhanden

Nachteile:

Höherer Entwicklungs- und Wartungsaufwand
Höheres Risiko für sicherheitskritische Fehler (Speicher- und Pointer-Klassen)
Für ein großes Fachsystem meist zu teuer und zu risikoreich als Hauptstack

Eignung im Projekt:

Eher für Spezialfälle, nicht als Kernsprache.

Sprachen, die hier bewusst nicht aufgeführt sind

Sprachen, die typischerweise an den MUSS-Kriterien scheitern oder in diesem Projektkontext kein tragfähiges Ökosystem für Betrieb und Langfristigkeit erwarten lassen, werden hier nicht behandelt.

Dazu gehören insbesondere Sprachen mit sehr kleinen Entwicklerpools oder ohne realistischen Support-/Dienstleistermarkt im öffentlichen Sektor.

Zusammenfassung

Unter der Annahme „Smartphone-Stack ist entkoppelt“ verbleiben für das Kernsystem (Windows-Clients + on-prem Server) im Wesentlichen folgende realistische Sprachfamilien:

TypeScript/JavaScript als UI-Standard für Browser-Oberflächen
Java oder C#/.NET als sehr starke Kandidaten für den Serverkern
Go als Serveroption, wenn Deployments maximal simpel sein sollen
Kotlin als JVM-Variante, wenn bewusst akzeptiert
Python als Tool-/Automation-Sprache (Kernserver nur mit Disziplin)
C/C++ für Spezialfälle, nicht als Hauptstack

Der nächste Schritt ist die formale Bewertung dieser Kandidaten gegen alle MUSS/SOLL/KANN-Kriterien in:

Programmiersprachen-Bewertung