5 Gründe, warum C# Murks (und nicht mehr so ganz zeitgemäß) ist // deutsch

Seit einigen Monaten arbeitet Golo Roden, Gründer und CTO der the native web GmbH, wieder mit C# und .NET – nachdem sein letzter Kontakt zu den beiden Technologien über 10 Jahre zurück liegt. Dabei sind ihm an C# und an .NET einige Dinge (negativ) aufgefallen, und C# wirkt auf ihn nicht mehr ganz zeitgemäß. Was ist das Problem?

00:00 – Einleitung
01:57 – Was Dich erwartet
03:11 – Umgang mit Leerstrings
07:27 – Fünf verschiedene Timer
09:59 – Viele Wege führen nach Rom
11:09 – Kein roter Faden seit C# 6
13:14 – Weniger schreiben, schlechter lesbar
14:49 – C# ist weder funktional noch einfach
16:52 – Kein yield return in try/catch
18:13 – Algebraische Datentypen
19:31 – Ko- und Kontravarianz
20:36 – Das IDisposable-Interface
22:01 – Keine vernünftige Codeanalyse
23:21 – JSON parsen
27:34 – C# ist historisch gewachsen

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[stevet]

2 Dinge vornweg...
1. Ich mag diesen Kanal wirklich gern und möchte an dieser Stelle mal Danke für viele wirklich sehr nützliche Videos sagen.
2. Ich arbeite seit Jahren mit C# und bin da sicher nicht komplett objektiv, aber vielleicht auch deswegen möchte ich manche Aussage hier nicht nicht unwidersprochen so stehen lassen. Auch wenn ich selber mit einigen Dingen bei Sprache und auch Framework nicht zufrieden bin insbesondere bei Entwicklungen der jüngeren Vergangenheit.

Insgesamt muss ich sagen, wirkt das Video leider wie einer der zahlloses Rants im Internet, wo jemand Sprache X und Y mag und viele Jahre nutzt, sich dann mal Sprache Z anschaut und diese im Vergleich "auseinander nimmt". Trifft hier nicht ganz zu, aber die Wirkung bleibt mir trotzdem beim Zuschauen erhalten.

Es werden zwar einzelne Punkte und Beispiele genannt und auch begründet, aber schon dabei werden die Sprache C# und das Framework .NET miteinander vermischt. So sind die vielen unterschiedlichen Timer kein Problem der Sprache C#, sondern ein Bestandteil von .NET und somit ein "Kann man benutzen, aber muss man nicht". Frameworks enthalten naturgemäß einige Dinge in verschiedenen Ausprägungen, man schaue sich nur mal die Möglichkeiten in Java für Parallelität und Nebenläufigkeit an.
Und mal ehrlich...Als jemand, der sich viel im Umfeld von Javascript/Typescript bewegt, würde ich mich an dieser Stelle auch nicht zu weit aus dem Fenster lehnen. Denn gerade diese beiden Sprachen bringen von Haus aus viele Dinge nicht mit, die man bei modernen Sprachen durchaus erwarten würde (z.B. Collections, eine konsistente API zum Arbeiten mit Collection, mathematische Operationen, etc.). Stattdessen muss man hier schon für triviale Funktionen auf Pakete zurückgreifen und holt sich dabei im schlimmsten Fall noch ein Sicherheitsproblem über transitive Abhängigkeiten mit ins Projekt.

Auch das beschriebene Problem mit den algebraischen Datentypen und der JSON-Serialisierung seh ich viel entspannter. Denn eine Liste, die sowohl Werte vom Typ int wie auch string enthalten soll als auch eine API, die strukturell verschiedene Daten zurückliefern kann, klingt m.M.n. nach keiner besonders guten Idee. In diesem Szenarien würde man in einigen Sprachen so seine liebe Mühe haben das sinnvoll zu verarbeiten. Sprachen und Frameworks sollen ja meist einen "Normallfall" abdecken und derartige Anforderungen klingen, zumindest für mich, eben nicht nach einem solchen. Und wenn es Sprachen gibt, die das besser können, dann ist es doch IMHO nur richtig und legitim diese zu benutzen als C# vorzuwerfen nicht genau für den eigenen Anwendungsfall die richtige Lösung zu haben.

Ich bin aber natürlich auch weit davon entfernt zu sagen, dass C# keine Probleme hat und gerade die Entwicklungen der letzten Versionen haben die Sprache nicht unbedingt sinnvoll weiterentwickelt. Nur kann man das wahrscheinlich über jede Sprache sagen, auch neuere Vertreter wie Go oder Kotlin. Mit Kotlin hab ich selber 2 Jahre Erfahrungen in einem Projekt gesammelt und das Fazit fällt wie so oft aus. Es gibt Dinge, die würde ich gern in andere Sprachen übernehmen und Dinge, die bringen keinen Mehrwert oder halten einen sogar auf.

Lange Rede, kurzer Sinn...Ich finde einen kritischen Umgang mit C# als Sprache wahrlich nicht tragisch, sondern hoffe sogar das einige der kritisierten Punkte bei Microsoft selber ankommen. Trotzdem muss ich sagen, empfang ich das Video seit langem als eines der schwächeren, weil es eben wie ein persönlicher Rant gegen eine Sprache erscheint. Insbesondere weil die vorgebrachten Beispiele eben teils sehr speziell sind (bei yield return wird es sogar im Video erwähnt).
Am Ende find ich dann einfach das Fazit "Murks" deutlich zu extrem gewählt und ungerechtfertig, weil man damit IMHO auch recht schnell die sachliche Ebene von Kritik verlässt
(und ja, ich weiß das provokante Titel mehr Klicks bringen und sie seien euch natürlich gegönnt, aber gut find ich es halt trotzdem nicht ;) )

Trotzdem danke für das Video und die Mühe. Am Ende schadet es auch nicht, sich mal, zumindest für einen Moment, kritisch mit der Sprache auseinader zu setzen, die man öfter einsetzt ;)

Just my 2 cents

[wobuntu]

Ui, als JS dev über Inkonsistenzen, Performance, verwirrende Sprachkonstrukte, Lesbarkeit, etc. bei C# zu ranten ist hald schon mutig.

[Dr_Kurt]

Ich habe die letzten beiden Jahre mit c#/.NET Core gearbeitet und seit einem halben Jahr wieder mit Java. Das C#-Ökosystem ist Java um Lichtjahre voraus. Entity Framework Core moppt mit Hibernate den Boden und grafische Oberflächen mit Blazor Server-Side ganz ohne JS zu entwickeln ist nicht nur schnell, es macht auch verdammt viel Spaß. Und man braucht keine ulkigen Spezialkenntnisse, wie z. B. Typescript bei Angular. Ich hab mir mal ein Tutorial für Angular angeschaut und finde es einfach nur kompliziert. Allein schon die 28 verschiedenen Klammerarten.

[allinvanguard]

Vorneweg - C# ist und bleibt mein absoluter Favorite, aber über die letzte Zeit habe ich auch viel mit Kotlin und TS gearbeitet und habe definitiv gesehen, dass es einige Konstrukte gibt, welche ich durch die Auseinandersetzung mit anderen Sprachen nicht nachvollziehen kann, bzw. das fehlen davon nicht verstehen kann. Mit deinem Kommentar zu den verschiedenen Timern triffst du einen guten Punkt - Die Sprache legt riesigen Wert auf Backwards compatibility, und man merkt von Feature zu Feature, wieviel Pain points sich daraus ableiten lassen. Man ist halt auch irgendwo eine verlässliche Enterprise Sprache, aber ich frage mich, ob man irgendwann eine Schwelle erreicht, an der man sich auch mal über breaking Changes unterhalten muss, um das ganze Konstrukt C# und .Net der Zeit entsprechend auszudünnen.

[Me-clze]

20:10 natürlich geht das. Dafür musst du deinem generischen interface nur ein nicht generisches Basisinterface zur Verfügung stellen und schon kannst du alle Events als List<IEvent> abspeichern. Oder / und das generische interface als Kovariant definieren.

[AK-cnmn]

C#, hat aber auch sehr tolle Seiten, wie (Interface) Extensions, (Dynamic) Linq, DLR, Roslyn an sich und auch (nested) using Statements weiß nicht warum gerade die ein Problem darstellen sollten🤔. So Sachen wie das mit den Strings und Timern sind doch Kleinigkeiten. Natürlich ist das funktionale Paradigma irgendwie "rangebastelt" und es ist auch arm, dass die Newtonsoft viel besser als der Standard Parser ist aber gut, das sind jetzt so Sachen die man zu sehr durch die JS Brille sieht. Dafür hat man dort andere Probleme die noch gravierender sind.

[waltavista]

Vielen Dank für das Video. Ich programmiere fast ausschliesslich in C# und die genannten Probleme (bis auf das JSON-Thema) sind für mich keine. Das liegt aber sicher daran, dass ich es eben nicht als Problem kenne oder mir als Feature anderer Sprachen nicht bekannt ist.
Zu JSON: Newtonsoft.Json war jahrelang der Standard. Das Nuget-Paket wird meineswissens am häufigsten runtergelanden und es gab die Spekulation, dass es Nuget kaputt machen, wenn es > Int32 mal runtergeladen wird (Hat es nicht:))
Für Microsoft war wohl JSON jahrelang nicht wichtig, die wollten sicher eher XML. Dann musste wg. Web APIs irgendwann doch JSON direkt von MS unterstützt werden und als Tec-Konzern können die natürlich nicht sagen: "Nehmt Newtonsoft.Json, das ist besser."
Das führt nun dazu, dass ich immer überlege, welches Paket ich nehme und mache mal so und mal so.

[onionware]

Bin ich mal gespannt. Habe mein OnionMedia-Projekt in C# geschrieben. Klar gibts auch ein paar Drawbacks aber an sich mag ich die Sprache eigentlich.

[StephanHaubenberger]

Hallo Golo, ich finde Deinen Kanal extrem super! Auch dieses Video ist grundsätzlich interessant, weil Du einige Punkte aufzeigst, die aus deinem Blickwinkel nicht gut sind. Aber bzgl. „is null“ und „==null“ ( vgl: Sekunde 600 ff) liegst du aus meiner Sicht falsch. Diese zwei Vergleiche sind grundsätzlich unterschiedlich. „==“ kannst du überladen, während „is null“ garantiert Dir, dass nach NULL geprüft wird, egal ob „==“ überladen worden ist. Vgl: z.B: learn microsoft -> csharp -> language-reference -> operators -> patterns#constant-pattern -> „The compiler guarantees that no user-overloaded equality operator == is invoked when expression x is null is evaluated.“
Oder versteh ich da was falsch?
LG aus Österreich

[MrMelatonin]

Ein sehr wichtiger Punkt ist für mich, dass mich die Sprache (IDE, Compiler) vor Fehlern schützt und mir auch gut kontextbezogen helfen kann. A) Ich finde String.Empty besser, weil es Fehler vermeidet. Wenn sich bei "" aus versehen ein Zeichen in die Anführungszeichen einschleicht, ist dies trotzdem ein gültiger String. Bei einem String.EmXpty wäre dies nicht der Fall. Das dies nicht überall genutzt werden kann, finde ich auch schade. B) Eine Liste die aus Strings und Integern besteht, finde ich etwas merkwürdig. Was ist die fachliche Beschreibung des Inhalts der Liste? Für mich wirkt dies eher wie eine Art Sammelsurium. Für mich ist TS eine Verbesserung zu JS, aber ich würde trotzdem Java/C# bevorzugen. Als Murks würde ich aber keine der Sprachen bezeichnen ;-)

[FilmfanOliver]

Was mir an C# ganz gut gefällt ist wenn man aus der Java Welt kommt ist man mit einwenig Übung drin 🙂

[lars]

Ich bin hauptsächlich Java Entwickler, mache aber auch hin und wieder was mit C#. Ich mag C# dahingehend, dass man durch die ähnliche Syntax direkt umsteigen kann, ohne sich groß umzugewöhnen. Finde aber auch, das C# sehr überladen ist, aber finde auch wiederum, dass das nicht schlimm ist, da man die ganzen Features ja nicht unbedingt nutzen muss. Ich kann C#-Anwendungen im gleichen Stil wie mit Java schreiben.

In zwei Punkten möchte ich widersprechen: 1. Keine Methoden auf der grünen Wiese. Das ist bei Java auch so und sollte bei jeder objektorientierten Programmiersprache so sein. Eine Datei, eine Klasse, eine Verantwortlichkeit. Keine globalen Variablen oder Methoden. Einen globalen Namen kann man nur einmal vergeben und dann geht es schnell mit Präfixen los, wie bei C in den 90ern. Richtige Objektorientierung heißt für mich, alles an Code wohnt in einer Klasse.

2. Externe Bibliothek für Json. Entschuldigung, aber wie ist das bei rohem JS? In C# kann ich mit 0 Abhängigkeiten eine einfache Anwendung erstellen. In JS brauche ich für nahezu alles ein Framework. Alleine schon fürs Frontend. Wer programmiert den heutzutage mit rohem JS ohne irgendwas? JSON ist einer der wenigen Aspekte bei. NET, wo man immer eine externe Abhängigkeit braucht, sonst ist man mit .NET schon gut bedient.

[christophholler]

Hört sich ein wenig nach Clickbait an! Am Ende wird Golo sagen, dass C# eigentlich gut is, aber gewisse Sachen besser sein könnten! Aber das kann man halt über jede Sprache und jedes Framework sagen!

Ich persönlich finde C# angenehmer als Typescript und bin froh das ich mein Backend nicht in TS schreiben muss!

Ich habe viele Jahre mit C# (in Net Framework) gearbeitet. Alle Zertifizierungen gemacht (MCTS, MCPD), sogar als MCT doziert. Und dann irgendwann damit aufgehört, weil mir die Lösungen viel zu komplex wurden. Mit Core hoffte ich auf Vereinfachung. Dies wurde mir nicht erfüllt. Selbst für einfache APIs sind die Best Practices so unerträglich kompliziert, dass ich keine Lust mehr hatte.

Seit 6 Monaten mache ich jetzt Java und stelle dort fest, dass alles, was mir bei C# (und Nuget) so nervig war, mit Java total einfach und übersichtlich ist. Das mag aber auch sicherlich an Spring (und Maven) liegen. Das Handling von Dependancy Injection - zum Beispiel - ist so, wie ich es mir immer bei C# gewünscht hätte.

Dank Dir, lieber Golo, mache ich mittlerweile alles, was (neue Sachen) REST APIs betrifft, mit Node.js und Express.

[codr]

Grüße aus der JVM-Welt, auf die man den Großteil dieser Kritik 1:1 übertragen kann. Auch hier gibt es keine ADT (nein, sealed classes sind kein vollständiger Ersatz dafür!), JSON erfordert eine externe Dependency (Jackson, in 99, 999% der Fälle), die Standardbibliothek hat oft 5 oder mehr historische Wege, das gleiche Problem zu lösen), etc... Und dad Schlimmste: 20 Jahre, nachdem .NET vorgemacht hat, wie man Generics und Value Types sinnvoll umsetzt, sind sie in Java immer noch Murks (Abhilfe via Project Valhalla immer noch in gefühlt ferner Zukunft).
Kotlin löst MANCHE der Probleme mit Java (allen voran die generelle Geschwätzigkeit); die schlimmsten Limitierungen und Altlasten können aber nur von der Plattform gelöst werden, und da gehen aktuelle Initiativen zwar in die richtige Richtung, aber viel zu langsam.

Und doch werde ich auf absehbare Zeit bei Java/Kotlin bleiben, aus einem ganz einfachen Grund: Ökosystem und Community rund um Spring suchen Ihresgleichen, es gibt keinen Ersatz dafür. Nicht einmal Node.

[anion]

Interessantes Video.
Ok, ich finde, die angesprochenen Punkte sind teilweise valide Kritikpunkte. Das sind aber zugleich auch alles keine großen Probleme meines Erachtens. Das Video ist schon Kritik auf höherem Niveau. Jede Programmiersprache, die modern ist, aber zugleich ein gewisses Alter hat, ist irgendwie historisch gewachsen. Ich denke solche oder ähnliche Probleme findet man bei jeder (älteren) Programmiersprache. Und bei C# ist vieles im Vergleich meines Erachtens sogar noch relativ gut gelöst. Ich denke da gibt es, wie du ja auch gesagt hast, in Sprachen wie Javascript, Python und PHP viel mehr Inkonsistenzen und Momente wo man sich denkt "Warum geht das nicht?! Und warum wird das mal so und mal so gemacht?".
Ein paar kleine konstruktiv gemeinte Anmerkungen noch:
- Das Beispiel mit den Generics bei Events: Ja, Generics bringen teils komplexe Situationen für den Compiler oder auch für den Entwickler. Aber geht das denn in anderen Programmiersprachen? Ich hab jetzt noch nicht in Go oder so programmiert, aber in einigen anderen Sprachen vermisse ich (typsichere) Generics generell. Ich kenne leider keine Programmiersprache, wo Typen von Parameter oder Generics immer und überall spezialisierbar sind. C# hat aber immerhin das where-Keyword, um zumindest an einigen Stellen Typ-constraints für Generics zu definieren.
- Was du technisch an dem IDisposable-interface auszusetzen hast, ist mir in dem Video ehrlich gesagt nicht so ganz klar geworden.
- Wegen der JSON-Deserialisierung: In C# wurde die Designentscheidung getroffen, ein statisches Typ-System zu benutzen: Ein Objekt hat immer genau einen konkreten Typ und der ist fest definiert und kann zur Laufzeit nicht geändert werden. Einen polymorphen Deserializer für JSON-Daten zu entwickeln, ist dann >in der Theorie< schwierig, das liegt in der Natur der Sache (Wer in C# schonmal ein Dictionary deserialisieren wollte, weiß, was ich meine.), das kann man im Allgemeinen nicht für beliebige Typen machen. Und nein, wenn man polymorph deserialisiert, weiß man eben nicht, welche Datenstruktur da kommt. Es kann dann (z. b. wenn die Datenstrukturen sehr ähnlich sind) mehrere mögliche Parsing-Ergebnisse geben, die alle valide sind, aber man weiß nicht, welches Ergebnis das gewünschte ist. Das kriegt Newtonsoft.Json zwar in gewissem Rahmen hin, aber intern sicherlich auch nicht ohne Gefrickel und vor allem werden dann Kompromisse gemacht, die die C#-Entwickler offensichtlich nicht eingehen wollten. Newtonsoft.Json ist >in der Praxis< die führende Library für JSON-Handhabung und macht diesen Job auch echt gut, und ich hab den Eindruck, das hat Microsoft einfach eingesehen und versucht da nicht, das Rad dahingehend nochmal neu zu erfinden. Basic JSON-Handhabung kann C#, ja, aber für alles weitere dann Newtonsoft.Json. Der Ansatz von Go ist natürlich interessant. Wenn sich das als gut erweist und etabliert, trau ich Microsoft zu, dass das so oder ähnlich in C# noch kommen wird.

[shioli]

Das mit der JSON serialization ist definitive etwas, was oft vorkommt. Jedoch finde ich das auf API Ebene auch in JS und TypeScript eine API zu bauen die verschiedenste Objekte zurückgibt nicht wirklich gutes API Design ist. Manchmal ist es legitim. Sollte aber ein Ausnahmefall sein. Wenn notwendig ist es eine gute Idee ein Feld hinzuzufügen dass den typ des Objektes angibt (type: 'Dog' für den Hund und type: 'Cat' für die Katze). Anhand dessen ist es auch in Sprachen mit einem statischen Typsystem möglich ohne großem Kopfzerbrechen einen JSON Serializer dynamisch auszuwählen ohne Zwischenobjekte bzw. halb/gar nicht deserialisieren im 1. Schritt. Ziel einer guten API soll ja genau sein dass sie von beliebigen Programmen und Sprachen benützt werden kann. Das inkludiert C# auch wenn deine API nicht in C# geschrieben ist. Aber man verbringt schon mehr Zeit damit als sein müsste.

[techniksupportskp]

Vor ein paar Jahren habe ich Java und Adobe Extendscript (Javascript) entwickelt. Nun seit rund 3 Jahren bin ich Filemaker-Entwickler. Neulich wollte ich für mich privat etwas Programmieren, entsprechend ungeübt kam ich in Java kaum noch zurecht (bin eben FileMaker-verseucht). Nach einigen Stunden in Java, habe ich dann C# probiert und war doch sehr fasziniert, wie einfach ich mir dort eine kleine Serveranwendung programmieren konnte. Ich musste Visual Studio installieren und los gings. Bei Java hat man dieses ganze geraffel mit der JRE und bei JavaScript etc. gibts gar nichts auf den ersten Blick einfach zu konfigurierendes. Solange man nicht besonders modern sein muss und einfach eine simple Umgebung braucht, die funktioniert, ist C# genau das richtige

[DynamicSun]

herrlich, das jemand ein Video darüber macht, über was man sich selbst ärgert. PolymorphDeserialisierung, habs preParsing genannt :-)

[DanielOpitz]

Mein Eindruck von C# ist, dass Microsoft versucht, mit anderen Sprachen schrittzuhalten und übernimmt daher viele Features und Paradigmen (z.B. FP) daraus. Über die Jahre entwickelte sich die Sprache daher zu so einer Art "Frankenstein" ;-) Trotzdem ist C# immer noch einer der besten Programmiersprachen die es gibt. Das .NET "Ökosystem" wirkt derzeit wie eine halb-gerupfte Gans auf mich. Man muss auch nicht gleich jedes neue Sprachfeature nutzen, sondern man sollte das immer abwägen und ggf. einfach auf den Einsatz bestimmter Sprachfeatures verzichten. Das mit dem schlechten JSON-Support kann ich unterschreiben. Was ich an C# frustrierend finde, ist das umständliche Handling mit NullReferenceException.