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

[@stevet2321]

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

[@marcusreinicke]

Das stehe ich voll hinter, besser geschrieben als meine Wenigkeit.❤ Kritik ist immer gut, ohne sie verbessert man sich nicht, aber sie sollte sachlich sein. Das hat mir gefehlt. Trotz allem, macht Golo hier immer wieder einen sehr guten Job, da darf dann auch mal etwas schlechtes Video entstehen

[@anion21]

Ich stimm dir weitesgehend zu. Der Video-Titel ist auf jeden Fall übertrieben. C# und die offiziellen .NET-Libraries zu "vermischen" seh ich an dieser Stelle unkritisch, da beides vom selben Hersteller kommt. Das gehört halt de facto einfach zusammen. In Javascript kritisiert man ja auch (zu Recht), dass es keine konsistente API zum Arbeiten mit Collections gibt, da geh ich voll mit dir mit. Aber in C# gibt es das auch nicht builtin in der Sprache. Trotzdem kritisiert man das nicht, sondern benutzt einfach die .NET-Libraries, die die ganzen Interfaces und Funktionen enthalten. ;)

[@stevet2321]

@@anion21 Ok, Punkt für dich :) Mir ging es wirklich weniger darum aufzuzeigen, dass C# als Sprache und .NET als Framework 2 getrennte Dinge sind. Wahrscheinlich hätte ich das etwas anders formulieren sollen. Ich wollte eher herausstellen, dass man sicherlich kritisieren kann, dass ein Framework 5 Timer hat und keiner davon so richtig perfekt zu sein scheint. Aber schlimmer find ich da die Tatsache, dass eine Sprache nicht mal eine grundlegende API für das tägliche Arbeiten (z.B. mit Collections) mitbringt und man für triviale Dinge mitunter eine Vielzahl von zusätzlichen Paketen braucht. Am Ende findet sich immer ein Punkt für oder gegen eine Sprache, aber ich würde dann halt trotzdem nicht soweit gehen, diese als "Murks" komplett zu entwerten. Schmälert natürlich deinen Einwand nicht, deswegen an dieser Stelle danke für die Ergänzung und deinen Kommentar. Kann ich sehr gut mit leben :)

[@erkancimen7787]

ich schließe mich hier mit an. ^^"

[@Furz35]

Ich stimme Dir voll und ganz zu. Das ganze Video hört sich zu 90% nach Erbsenzählerei an um eine Rechtfertigung zu finden eine andere (Lieblings) Sprache zu verwenden (die evtl. sogar noch mehr Unzulänglichkeiten besitzt). Das 5 Timer existieren (meinetwegen können es 10 sein) sehe ich eher als Vorteil, so kann man den für seine Anwendung optimalen verwenden. Mit der gleichen Erbsenzählerei kann man jede Sprache zerrupfen wie ein Huhn. Demnach sind alle Sprachen Murks.

[@wobuntu]

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

[@hgloeckl]

Genau JS im Vergleich zu C# als ... bezeichnen ist echt ein Schlag unter die Gürtellinie

[@hanspeterbestandig2054]

Ich mag Beides nicht (bin Embedded Entwickler und in C/C++ unterwegs), gebe Dir aber Recht. Musste mal was mit JS machen und es war der reinste Horror.

[@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.

[@thenativeweb]

[gr] Danke für den Kommentar - und das wirft eine spannende Frage auf: Wie würde (oder könnte) C# aussehen, wenn man es heute einmal neu designen würde? Also was würde man beibehalten, was würde man entfernen, was würde man anders lösen? Das finde ich eine sehr spannende Frage …

[@lokthar6314]

@@thenativeweb vermutlich wäre es ein Kotlin-# :-)

[@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.

[@Dr_Kurt]

@@sven2529 was genau ist an Blazor Mist? Zu langsam, zu einfach, zu...?

[@aptfx]

@@Dr_Kurt die Latenz ist grottig und wenn man das lösen will schreibt man eh wieder JS im Frontend - da kann man es auch gleich richtig tun.

[@Me-cl2ze]

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 abspeichern. Oder / und das generische interface als Kovariant definieren.

[@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.

[@AK-cn3mn]

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.

[@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

[@onionware1]

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.

[@thenativeweb]

[gr] Bin gespannt, was Du nach dem Video sagst …

[@lars7898]

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.

[@DynamicSun]

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

[@thenativeweb]

[gr] Tja, auch ein blindes Huhn … 😉 Freut mich, wenn wir mit dem Video Deinen Geschmack getroffen haben 😊

[@FilmfanOliver1992]

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

[@thenativeweb]

[gr] Ja, das ist definitiv wahr - im Grunde sind sich C# und Java als Sprachen ja doch sehr, sehr ähnlich.

[@Benexdrake]

C#

[@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 ;-)

[@anion21]

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.

[@cod3r1337]

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.

[@troi951]

Ich wollte schon schreiben, den guten Golo das gleiche Video nicht für Java produzieren zu lassen :D Ich kenne zwar C# nicht aber einige der hier aufgezählten Probleme sind in Java ebenso vorhanden. Wobei mich das Parsen mit Jackson als externe Dep. nie störte. Die Problematik zu ADT kann ich nicht ganz nachvollziehen, gilt das nicht für alle statisch typisierten Sprachen? Für mich ist einer der Vorteile von statischer Typisierung, die Lesbarkeit. Ich bin zwar in der Regel als Backendler unterwegs aber jedes Mal wenn ich mir JS anschauen muss, habe ich tatsächlich Schwierigkeiten dem Programmfluss zu folgen mitunter wegen diesem Problem. Nur eine Meinung von einem Frontend-Laien.

[@cod3r1337]

@@troi951 1. Nein, das gilt nicht für alle statisch typisierten Sprachen. ADT werden z.B. von der statisch typisierten Sprache F# direkt unterstützt; TypeScript kann wie im Video erwähnt etwas Ähnliches in Form von Union Types. ADT eröffnen Möglichkeiten für Domainmodellierung, die mit klassischem OOP-Ansatz 100x komplizierter und geschwätziger sind. Ein verwandtes Thema ist strukturelle Typisierung bzw. Duck Typing; die Idee ist, dass eine Datenstruktur bzw. ein Objekt einen abstrakten Typ implementieren können, ohne dass die Implementierung von diesem abstrakten Typ irgendetwas wissen muss. Das erlaubt enorme Flexibilität, die viele moderne statische Sprachen (wie z.B. TypeScript oder Go) erlauben, in C# oder auch Java aber wohl immer ein Wunschtraum bleiben. 2. Du kannst statische Typisierung in der JS-Welt haben, und zwar in Form von TypeScript. Und ganz ehrlich, wer will heute noch Vanilla JS coden, wenn man TS haben kann :-)

[@sevensolutions77]

Da bin ich aber gespannt...

[@thenativeweb]

[gr] Ich auch 😉

[@itvbfk8716]

Bin auch sehr gespannt :) Vor allem auf das "nicht mehr so zeitgemäß".. Was das wohl bedeuten mag?

[@thenativeweb]

[gr] Ich hoffe, das Video konnte ein bisschen Licht ins Dunkel bringen … 😊

[@itvbfk8716]

@@thenativeweb Ja, verstehe deine Punkte und kann zumindest die Inkonsistenzen nachvollziehen. Mein "Glück" ist aber, dass ich bisher mit keinem dieser Probleme wirklich in Berührung gekommen bin (bis dato) 🤭

[@wonkothesane3807]

Schöne Halloween-Folge. 😁

[@thenativeweb]

[gr] Haha, danke 😊

[@sokrat009]

Danke für der sehr aufschlußreiche Beschreibung der C# Probleme, die mich teilweise stark an Java-Erlebnisse erinnert haben. Wie sieht es deiner/eurer Meinung nach mit Python aus? Kann man Python (auch) für kleine Server-Projekte einsetzen?

[@thenativeweb]

[gr] Zu Python kann ich leider nicht wirklich viel sagen, da ich mich nie größer mit Python beschäftigt habe. Sicherlich eignet sich Python auch für Server-Projekte, aber ich habe keine Ahnung, wie gut oder schlecht das funktioniert, wo da die Stärken und Schwächen liegen, insofern muss ich an der Stelle leider passen …

[@techniksupportskp3374]

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

[@christophholler9997]

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!

[@thenativeweb]

[gr] Warten wir es ab 😉 Und zum Thema Clickbait: kzbin.info/www/bejne/Z3m9pGWejK-Bnrc

[@christophholler9997]

@@sven2529 Welche Programmiersprache ist denn wirklich gut? Und vor allem warum und was macht sie so viel besser als C#? Würde mich wirklich interessieren!

[@christophholler9997]

@@sven2529 Danke für deine Antwort, ich seh es genau so man muss das richtige Werkzeug für den jeweiligen Verwendungszweck wählen. Ja C# fühlt sich groß an und hat einen gewissen Overhead. Ich schreibe aber recht gerne APIs mit C#. Ich war noch nie ein Fan von JS und auch wenn TS besser ist, bin ich froh, dass sich das bei mir auf das Frontend (Angular) beschränkt.

[@sixmilesout1054]

Welche Sprachen würdest du empfehlen?

[@thenativeweb]

Kommt immer darauf an, was Du machen möchtest. Grundsätzlich, ohne nähere Details zu kennen: Go und/oder Rust.

[@sixmilesout1054]

@@thenativeweb Als Ersatz / Alternative für C#? Sehe ich keinen Sinn.

[@thenativeweb]

Deswegen sag ich ja, es kommt darauf an, was Du machen möchtest.

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.

[@thenativeweb]

[gr] Danke - und gerne 😊

[@boredstudent9468]

Ich weiß nicht ob es es besser oder schlimmer macht, aber man kann mit Algebraischen Datentypen in C# arbeiten, weil es sie in F# gibt und über die CLR compatibel

[@UnitedOneDE]

Ich mag deine Videos sehr, aber die aufgeführten Beispiele sind so banal und nebensächlich, dass es irgendwie wie ein gekünzeltes C#-Bashing wirkt :-D

[@shioli3927]

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.

[@thenativeweb]

[gr] Danke für Deinen Kommentar. Tatsächlich ist die API, die wir ansprechen, genau so gebaut - der Rückgabewert hat die Form { "type": "…", "data": { … }} Und im type-Feld steht, welche Struktur man in data zu erwarten hat. Und genau das, was Du vorschlägst, würden wir dementsprechend gerne machen - nämlich an Hand des Wertes von type den passenden Deserializer auswählen. Das einzige Problem ist nur: Um type auslesen zu können, muss man ja zumindest (partiell) schon deserialisieren. Dass das in JavaScript und TypeScript problemlos möglich ist, wäre hier kein gutes Argument, denn dort ist JSON ja quasi Kernelement der Sprache. In Go kann ich aber zum Beispiel folgende Struct definieren: type Result struct { Type string Data json.RawMessage } und dann mit var result Result json.Unmarshal(…, &result) auslesen. Danach kann ich typisiert auf result.Type zugreifen (ein string), den Typ auslesen, und danach einfach noch mal Unmarshal mit result.Data als Argument aufrufen, mit dem passenden Strruct, abhängig vom Typ - und fertig. In C# artet das in größeren Aufwand aus. Es ist nicht so, dass es keine Lösungen dafür gäbe (siehe zB manuc66.github.io/JsonSubTypes/), aber das eben wieder eine externe Abhängigkeit für etwas, das nicht besonders ausgefallen ist und (meiner Meinung nach) in die Sprache bzw das Framework an sich gehört. Übersehe ich hier etwas?

[@shioli3927]

@@thenativeweb Hätte ein Beispiel vorbereitet das nur System.Text.Json benützt. Jedenfalls weiß ich nicht wie ich dir das senden soll, weil jeder meiner Kommentarversuche der externe Links beinhaltet automatisch gelöscht wird. Das codebeispiel ist 63 Zeilen, wobei die eigentliche implementation nur 20 zeilen code sind. Dann kommen halt noch 3 klassen, beispiel json und benützung von dem ganzen. Mit zwischenobjekten hat man dabei in seinem code nix zu tun. System.Text.Json muss sicher intern da irgendwas machen, aber das is ja an der stelle einem egal außer man will die maximale performance raushohlen. GGF wenn ich es nicht schaffe dir den link irgendwie zuzuschicken. Es gibt ein JsonDerivedType attribut mit dem du das angeben kannst. Aber du kannst damit die property nicht deffinieren, diese ist immer $type mit dem attribut ansatz. Daher habe ich im beispiel einen JsonTypeInfoResolve implementiert. Wenn man DefaultJsonTypeInfoResolver ableited gibt es eine funktion GetTypeInfo. Die basisfunktion macht die hauptarbeit, also einfach aufrufen. Dann kann man für den basistyp "Animal" die PolymorphismOptions umschreiben und dort kann man auch den property namen ändern auf z.B. type. Die Dokumentation ist etwas mau halt. Aber es geht ohne irgendwelchen dependencies ohne großer hexerei.

[@shioli3927]

​@@thenativeweb Nvm, das ganze JsonDerived feature gibts erst seit .net 7 also eher Zufall das es bei mir jetzt geklappt hat. Dachte weil 6.x.x vorm package steht dass das auch mit .net 6 geht aber dem ist wohl nicht so. Gibt auch noch ein JsonPolymorphic attribut mit dem kann man den property namen auch ändern ohne type resolver. Klarerweise mit newtonsoft ging das schon viel viel früher. Den neuen parser gibts ja noch nicht lange.

[@djchrisi]

Also seit NET 7 kann System.Text.Json polymorphe Typenhierarchie Serialisierung und Deserialisierung. Golo hat wohl eine alte Version erwischt. In NET 6 steht dieser Hinweis tatsächlich. Jetzt ist das ein zusätzliches Atribt in dem man den type discriminator angibt und fertig.

[@andreasmewald2439]

Top level statements und global usings sind wirklich unnötig. Hab ich als C# Dev auch nie verstanden warum man das released hat.

[@thenativeweb]

[gr] Das ist einer der Punkte, die mir in C# sehr stark aufgefallen sind … für jeden Quatsch wird ein neues Schlüsselwort eingeführt, statt das Problem mit den bestehenden Schlüsselwörtern auf konzeptioneller Ebene zu lösen. Und das führt im Lauf der Zeit zu einer immer stärker aufgeblähten Sprache … In C# sind es inzwischen weit über 100 (!) Schlüsselwörter (siehe learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/), in Go (zum Vergleich) sind es 25. Diese Strategie macht die Sprache IMHO nur vordergründig und kurzfristig "besser". Langfristig führt es dazu, dass man immer mehr Altlasten mit sich herumschleppen muss, weil man die aus Abwärtskompatibilitätsgründen nicht streichen mag …

[@andreasmewald2439]

Grad die using statements sind was, dass ich beim Code lesen eher ausblende. Somit habens mich nie gestört. Die Einbindung der jeweiligen Dependency übernimmt die IDE eh mehr automagisch. Somit ists useless.

[@hippyphippi]

@@thenativeweb Das bedeutet ja nicht, dass man alle 100 benutzen muss. Statische Code-Analyse konfigurieren und gut ist. Habe selber noch nie goto verwendet und nur 1x unsafe code geschrieben. Es gibt aber Leute da draussen die, diese Features benötigen.

[@nothingisreal6345]

C# hat sicher einge Macken. Aber: Python = nicht typisiert, inakzeptabel langsam; JavaScript = nicht typisiert, inakzeptabel langsam, gruselige inkosistenzen; TypeScript = keine vollwertige Sprache; C++ = super mächtig aber auch sehr fehleranfällig inklusive sicherheits relevante Fehler; Java = gefühlt vor 10 Jahren stehen geblieben. Über den andern Total Murks wie PHP oder Perl braucht man gar nicht zu reden. Das sich MS in den letzten Jahren bei den Python und JS Scriptern anbiedert (global usings, File-scoped namespace declaration, top level statements) zeugt nicht gerade von Selbstbewusstsein, ist aber eher Kleinzeug. Aber ansonsten werden regelmäßig neue Features umgesetzt, die tatsächliche Verbesserungen bedeuten. z.b. records für DTO oder aber static virtual Members in Interfaces die jetzt endlich so etwas wie INumeric ermöglichen (was dann z.B. den Aufruf des + Operators für generische Methoden ermöglicht). Die größten Schwachpunkte, nämlich unnötig schlechte Performanz und unzureichende Unterstützung von nicht-Windows Systemen wurden in den letzten Jahren konsequent angegangen und gelöst. Da gibt es ganz andere Sachen bei MS die viel mehr schmerzen...

[@giol.8220]

Würde ich gelten lassen, wenn sich c++ über die Jahre nicht stark weiterentwickelt hätte. Dadurch ist c# einfach über.

[@nothingisreal6345]

@@giol.8220 Ja stimmt - C++ hat sich stark weiter entwickelt. Habe ich persönlich aber nicht wirklich verfolgt - alles was ich mache geht sehr gut in C#. Und die turnaround Zeiten sind bei C# ziemlich gut. Allerdings ist das ein Punkt der sich in den letzten Jahren nicht ausreichend verbessert hat und daher viele Entwickler zu Python und JS treibt. Da speichert man und kann sofort überprüfen ob es tut. Bei C#: kompilieren (ein paar Sekunden), evtl. funktioniert sogar hot reload. Bei C++: kompilieren kann Minuten dauern. Sollte mich wohl mal wieder tun mit modernem C++ beschäftigen.

[@thomasschroter3802]

@@sven2529 Entschuldige, aber C# war nie gedacht um Web-Frontend zu bedienen! Außer zum Zusammensetzen von dynamischen Webseiten (ASP). Mittlerweile gibt es mit Blazor allerdings neue Wege.

[@Alex-lu4po]

Wann hast du das letzte Mal mit PHP gearbeitet?

[@KaterMedia]

"C# kennt kein dynamisches Typsystem" - das stimmt nicht so ganz. Man hätte zum dynamic Typ parsen können. Es wird aber nicht empfohlen. Sicherlich gibt es auch irgendeine library die das kann. Randnotiz: Newtonsoft Json war lange Zeit die offiziell empfohlene library für Json. Erst kürzlich wurde System.Text.Json verbessert / eingeführt.

[@thenativeweb]

[gr] Ja, das mit dynamic stimmt - und das hatten wir ironischerweise auch so, bevor wir es dann schließlich mit object gelöst haben, denn dynamic und JSON gehen auch nicht so wirklich Hand in Hand, da rennt man in ziemlich hässliche Probleme rein … Dass System.Text.Json noch relativ jung ist, war mir gar nicht bewusst, aber ist interessant zu wissen 😊

[@hippyphippi]

Früher war ich auch der Meinung, dass dynamic absolut überflüssig ist. Hab das inzwischen in Integrationtests schätzen gelernt

[@M_B_80]

Ich hatte auch mal mit C# angefangen. Anfangs hat es noch Spaß gemacht, mittlerweile frustriert es nur noch. Es wird alles viel zu komplex, für Kleinigkeiten (z.B. als eine einzige *.exe kompilieren) muss man tausend zeilen code schreiben und konfigurieren. SVG kann immer noch nicht nativ in die UI eingebunden werden (WPF) ... Alles ist irgendwie nur halb fertig, zig Baustellen und nichts was wirklich durchdacht und vollständig ist. Warum kann man neue Ansätze nicht einfach halten? Warum muss richtiges Multithreaduing derart aufwändig sein? Warum kann Microsoft da nicht das Framework so gestalten, dass auch Anfänger damit zügig zurecht kommen, weil es in einem Gesamtpaket vorhanden ist und miteinander verknüpft ist, Task hier, IProgress dort, CancelToken da drüben und pausieren und fortssetzen ist dann wieder ein anderes Thema. Das kann man sicher benutzerfreundlicher aufarbeiten.

[@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.

[@fynderde]

Vielen Dank für das Video. Das sind (leider) alles valide Punkte und auch große Ärgernisse für mich. Natürlich kann man um all das irgendwie herumarbeiten, aber man fragt sich tatsächlich an vielen Stellen: Was hat Microsoft sich dabei gedacht? Das "schlimmste" an C# finde ich allerdings, dass inzwischen so viele Wege nach Rom führen, dass man nicht mehr weiß, welchen man gehen soll. Man fühlt sich wie vor dem Supermarktregal mit Ketchup - erschlagen von der schieren Auswahl und geht dann ganz ohne nach Hause. Für mich geht es in erster Linie um die Produktivität einer Sprache, also: In welcher Entwicklungszeit kann ich bestimmte Aufgaben lösen und natürlich darum, ob die jeweilige Sprache das richtige Tool für den Job ist. Dazu gehört auch das Deployment von Anwendungen (Auslieferung, Installationsaufwand, Upgrades). Obwohl ich als Entwickler natürlich am Ball bleiben und mir neue Technologien ansehen MUSS, fehlt mir hierfür oft die Zeit. Hier kann C# insofern punkten, dass man so ziemlich alles damit machen kann: Professionelle Webservices, Grafische Oberflächen (Cross Platform!), Smartphone Apps, kleine Kommandozeilentools aber auch große Plugin basierte Enterprise-Grade-Anwendungen und über Blazor oder AvaloniaUI sogar Webseiten oder -anwendungen. Sprich: Wenn man C# kann und Workarounds für die Schwächen kennt, kann man in der Sprache nahezu alles ganz brauchbar umsetzen, ohne zuviel Zeit zu investieren. Dabei ist C# aber nicht unbeweglich, sondern versucht neue Entwicklungen zu integrieren, ohne die "alten Hasen" zu verprellen. Besonders gelungen finde ich in dem Zusammenhang: Konzeptvielfalt, Tasks/async/await, IEnumerables/Extension Methods und die neuesten Bemühungen AOT Kompilierung zu ermöglichen (Performance). JavaScript / TypeScript ist im Web-Bereich sehr gut (Server und Client), aber Kommandozeilentools oder grafische Oberflächen (Electron) fühlen sich meist wie ein aufgeblasener ungeordneter Scripthaufen an. Außerdem bewegt sich das Ökosystem so schnell (Frameworks + Transpilation Boilerplate), dass man irgendwann müde wird, WIEDER das neuste Zeug auszuprobieren. Python ist auch toll - ebenfalls ein Allrounder ähnlich C# aber eben auch konzeptionell etwas in die Jahre gekommen und kann ohne Klimmzüge auch wieder nur als "Scripthaufen" ohne wirklich gute Performance ausgeliefert werden (unkompiliert). Go hingegen ist prima für Kommandozeilentools, Systemsoftware und Webservices - im Frontend (GUI, WebApps) ist allerdings noch viel Nachholbedarf. Ich finde auch das Modulsystem / Abhängigkeitsmanagement und das Error-Handling grausig. Jedoch halte ich Go für mit die "produktivste" Sprache, in der ich je entwickelt habe und daher auch für von euch klug gewählt. Dart hat mit Flutter (grafische Oberflächen / Apps) seine Nische gefunden, aber sonst nirgendwo richtig Fuß gefasst. Rust ist super, aber die Lernkurve ist extrem steil und somit war die Sprache für mich zu "unproduktiv", wenn auch genial von den Konzepten. Es gibt für C# sogar eine sehr kleine nbekannte Bibliothek (gnaeus OperationResult), die das Error-Handling von Rust nachbildet, die ich sehr gerne einsetze, weil die Anwendung damit oft fast ohne Exceptions auskommt (Performance!). Ich persönlich würde mir eine Sprache mit der "Einrückung" von Python, dem Compilerspeed und toolset von go, der Syntax und Konzepten von TypeScript und dem Thread-Modell von C# wünschen - und einen googlebaren Namen ;-) Alles in allem sehr gelungener Content, weiter so und gerne mehr davon!

[@bretzel30000]

Ich finde die Kritikpunkte in diesem Video zwar berechtigt, aber hier wird ja nicht NUR c# kritisiert. Sondern die dotnet runtime plus die windows spezifische standardlib plus die dotnet core runtime. Es ist eine philosophische frage, wenn er c# mit golang vergleichen will, dann muss er die stdlib von c# mitreinehmen bzw. die dotnet runtime. schwierig, ohne die stdlib ist es ein vergleich äpfel mit birnen.

[@halvarf]

Richtig gut und berechtigt fand ich den Punkt zum JSON-Parsing, das nervt mich auch sehr. OK, Newtonsoft.JSON ist jetzt wirklich nicht "irgendeine" Abhängigkeit zu einer externen Library, sondern hat schon sehr lange eine Sonderrolle gespielt, und erst vor ein paar Jahren hat sich MS dann doch mit dem Autor uüber den zukünftigen Weg zerstitten und was Eigenes gemacht, das allerdings immer noch nicht richtig so ist, wie es sein müsste. Eine wichtige Voraussetzung dafür wären die algebraischen Typen. Die wären schon lange fällig gewesen und wurden vom C#-Team ja auch schon länger zumindest implizit versprochen. Dass sie in C#11 immer noch nicht drin sind, ist schon sehr schade. Da hilft auch nicht, wie hier in anderen Kommentaren, zu sagen, dass ein JSON-File, bei dem das ein Problem ist, einfach schlecht definiert ist. JSON ist nun mal ein Austauschformat zwischen sehr verschiedenen Technologien, und Javascript ist dabei bedeutend. Auch der Status von IDisposable nervt, ja, vor allem nervt dabei, dass es immer noch so oft an Stellen benötigt wird, wo man sich fragt, warum die jetzt eigentlich Unmanaged Code brauchen. Viele andere Punkte in dem Video finde ich aber ziemlich irrelevant nach einer initialen Lernphase. Ja, man muss sich anfangs als Team etwas an sie gewöhnen, und sie sind der langen Geschichte von C# geschuldet. Aber mit dem Motto "we try to not break your old code", das insgesamt hervorragend durchgehalten wurde, hat das C#-Team den Entwicklern andererseits auch einen großen Gefallen getan, von dem man natürlich erstmal (!) nichts hat, wenn man neu in die Sprache einsteigt. Jeder (oder jedes Team) sucht sich halt mal einen Umgang mit Leerstrings oder Timern oder was auch immer für Framework-Klassen aus, und dann ist das Thema auch durch, in fast allen Fällen ist selbst inkonsistente Nutzung im Code irrelevant, die Performancediskussionen sind es sowieso, wie in Video ja auch gesagt wird. Ich freue mich über die neuen funktionalen Einsprengsel, die zum Teil sehr nützlich sind, aber in erster Linie ist und bleibt C# halt eine typisierte OOP-Sprache, und das finde ich auch nicht falsch. Zumal es mit F# eine sehr schöne funktionale Alternative gibt für Codeteile, für die das sinnvoller ist. Deshalb: inwiefern Funktionen mit globalem oder Namespace-Scope in einer OOP-Sprache irgendwie eine gute Idee sein sollen, kann ich für mich nicht nachvollziehen. Da ist "using" auch nicht nur ein Workaround, sondern die bessere Lösung. Wobei ich zu den globalen usings, gar in einer Config-Datei, die Meinung von Golo teile, das ist eine schlechte Idee. Was im Video noch gar nicht erwähnt wurde, aber für mich auch reingehört hätte, sind die nachträglich reingepfropten Konstrukte zur Nebenläufigkeit, die auf den ersten Blick einfach aussehen, aber wenn man sie wirklich benutzen möchte, auf eine Reihe von tiefen Fallen und technischen Details führen, mit denen man sich als Anwendungsentwickler eigentlich nicht beschäftigen möchte. Code, der erstmal harmlos und korrekt aussieht, führt zu Deadlocks oder race conditions, populäre Sprachkonstrukte sind nicht mit Nebenläufigkeit kompatibel, und wenn man verstehen will, was man machen darf und was nicht, findet man sich plötzlich auf einer technischen Ebene wieder, die der einladenden Einfachheit der Syntax Hohn spricht. Das ist in Go einfach von Anfang an in die Sprache reingedacht und entsprechend weniger reich an Fallen. Ich finde das Programmieren mit C#/dotnet insgesamt aber sehr angenehm, das Tooling (Rider und VS) ist gut, Roslyn hilft extrem dabei, von Anfang an fehlerfreien Code zu schreiben. Man kann damit mehr unterschiedliche Dinge machen als mit vielen anderen Sprachen. Der Lernaufwand lohnt sich definitiv, wenn man im weitesten Sinn im Business-Umfeld programmiert.

[@andreasmewald2439]

Warum gibts in JS == und === 😅

[@thenativeweb]

[gr] Gutes Beispiel dafür, dass andere Sprachen auch nicht perfekt sind … 😉

[@hugochavez6170]

== vergleicht nur den Inhalt === vergleicht auch den Variablentyp. 2=="2" -> true 2==="2" -> false

[@anyaplays7150]

Und da habe ich vor diesem Video noch ein Video von dir zum Sicherheitsproblem bei NPM gesehen und war froh, das Problem mit .NET in diesem Maße nicht zu haben ;) Tja und dann jetzt das. Hm, ich arbeite nun schon mehr als 15 Jahre ununterbrochen auf Basis von C# (und Clipper ;)) und sehe bei meinen Ausflügen in andere Gefilde wie Go, Python und JavaTypescript, das MS in .NET versucht, wie diese Sprachen auszusehen (Stichwort: minimal API). Wahrscheinlich wegen Rückwärtskompatibilität geht es nicht, alles alte loszuwerden. .NET/C# ist nun mal eine sehr häufig verwendete Sprache für Businessanwendungen (ERP) und da auch schon sehr lange. Das sind zum Teil monströse Monolithen. Wie will man das denn ständig auf neue/geänderet Sprachkonstrukte anpassen müssen/wollen? Ich kann MS also schon verstehen, wieso das so "lustig" aussieht, wenn ich gerne bloß einen dummen Timer hätte. Und was man auch merkt an deinen Videos zum Vor-Nachteil einiger Sprachen: Microservices (auch die alle auf einem PC per docker-compose liegen) haben definitiv den Vorteil, versch. Sprachen/Umgebungen mixen zu können und dann such man sich eben das Werkzeug aus, das zum Problem passt.

[@deterdamel7380]

Bei Go würde ich mir aber auch wünschen, dass die mit den Go 2.0 mal in die Pötte kommen. Das scheint so schnell nicht zu passieren.

[@thenativeweb]

[gr] Ja, da bin ich auch mal gespannt, wie das so (zeitlich) weitergeht … 😊

[@suchtendolp644]

Die Sprache selbst mag ich ganz gerne, jedoch fehlen mir 2 bestimmte Sachen: - Eine vernünftige Unterstützung für Cross-Platform UI Apps (Avalonia ist ganz gut, bietet aber leider keine Unterstützung zum Ressourcenladen mit x:Uid oder das Material 3 Designsystem) - Unterstützung für native Kompilierung (nur für Konsolen-Apps, gibt sehr große Binärdateien aus, funktioniert schlecht auf Android und im Web)

[@Tekay37]

Verstehe ich es richtig, dass bei "Algebraische Datentypen" und "Ko-/Kontravarianz" dein eigentlicher kritikpunkt ist, dass C# keine dynamisch typisierte Programmiersprache ist?

[@thenativeweb]

[gr] Nein, mein Kritikpunkt ist tatsächlich, dass C# keine algebraischen Datemtypen kennt (und es gibt durchaus Sprachen mit statischem Typsystem, die das beherrschen, zB Rust, TypeScript und AFAIK Haskell).

[@maxron6514]

Was schlägst du denn konkret vor als angenehmere Alternative zu asp dotnet core, außer die JS Familie…?

[@MultiSteve1978]

Du hast den PeriodicTimer vergessen 😂

[@thenativeweb]

[gr] War klar, dass es nicht einfach nur fünf sein konnten … das wäre zu wenig 🙈🤣

[@bsdooby]

Als interessante Alternativen (fokussiert aufs Wesentliche) wäre z.B. Beef (beeflang) oder D (dlang).

[@thenativeweb]

[gr] Danke für Deinen Kommentar - Beef kannte ich noch gar nicht, D nur dem Namen nach.

[@k3v1n0x90]

Dieses Feature für „easy“ hello World ohne Main hat Java auch eingeführt 😄, wer hat sich von wem inspirieren lassen 🤷‍♂️

[@thenativeweb]

[gr] Gute Frage … 😉

[@nothingisreal6345]

Alle hecheln den Kids hinterher: Python und JS sind hipp. Und da geht das - also muss man sich da anbiedern.

[@ThomasJunkOS]

Danke für das Video. Ich selbst habe die Entwicklung von 3.5 zu 4 mitgemacht. Damals fand ich C# große Klasse. Als dann 5.0 kam, habe ich das aus dem Augenwinkel beobachtet - war selbst aber schon woanders. Heutzutage bin ich im Python Universum bzw. Javascript zuhause und stelle mir ein "zurück" zu den statisch typisierten Sprachen creepy vor. Insofern: Respekt 👍

[@cdoubleplusgood]

Oha, da hat sich aber einer ordentlich in Rage reredet! 😁 Im Ernst, alle Punkte kann man natürlich nachvollziehen, ein paar finde ich aber ein bisschen aufgesetzt. Z.B. deine Kritik, dass man System.String und string schreiben kann. Da könnte man auch kritisieren, dass es int und System.Int32 gibt. Vieles ergibt sich aus der Historie von C# und der Tatsache, dass C# eine statisch typisierte Sprache ist. C# war als "besseres Java" geplant, und Java entstand in einer Zeit, als Objektorientierung DAS Paradigma schechthin war. Alles ist eine Klasse, und wenn es keine ist, machen wir trotzdem eine statische Klasse drumherum. Und dann muss man halt Math.Sin(x) schreiben statt einfach Sin(x) - so ein Blödsinn. Insofern finde ich, das using static lange überfällig ist, denn es stellt syntaktisch klar, dass einige statische Klassen eigentlich nur Namespaces sein sollten. Das mit JSON ist schlimm, da stimme ich zu. Das hat MS verpennt - nach wie vor nehmen die meisten Newtonsoft her, soweit ich das beurteilen kann. Die Sache mit yield return in try-catch ist merkwürdig. Vielleicht haben sich die Leute, die die State Maschine hinter yield entworfen haben, verrannt und wagen nun nicht mehr, den Code anzufassen? Man sieht, dass das Ganze nicht so einfach ist, wenn man mal einen Iterator von Hand implementiert, also mit GetEnumerator, MoveNext etc. Jon Skeet hat das in seiner Antwort auf StackOverflow ein bisschen angerissen. Was mich seit der ersten Zeile C# anfrisst, ist die fehlende "const correctness". Unnötigerweise muss man dauernd spezielle read-only-Klassen schreiben, damit der Anwender keinen internen Status falsch setzen kann. Aber das ist ja in den meisten Sprachen so. Und ja, ich komme von C++ her, da ist das ganz einfach.

[@Philip-Lorenz]

Sehr interessantes Video :) Nur ein kurzer Verweis darauf, dass du die einmalige Chance verpasst hast bei Minute 21:25 folgenden Clip einzubringen: kzbin.info/www/bejne/bpSrY42wbZKXgq8 :D

[@thenativeweb]

[gr] Haha 😊

Hey Golo, wieder mal ein sehr schönes und ehrliches Video. Gefällt mir sehr, der Blick von deiner Seite. Ich kann C# auch nur mit Python, Javascript/Typescript vergleichen. Und wie du sagst haben alle Sprachen ihre Stolpersteine. Wenn man mit vielen anderen Sprachen arbeitet sind die Stolpersteine in C# natürlich größer/auffälliger, weil Vergleiche möglich sind. Das bringt mich immer wieder zu meiner Aussage, dass Sprache nur ein Werkzeug ist und nicht für jede Aufgabe passen muss :-)

[@djchrisi]

10:03: 'xy == null' vs 'xy is null'. Hier kann die Sprache nur verlieren: Wenn man objekte nicht auf null matchen kann würde Golo auch: "Inkonsistent" rufen, wenn man es kann sagt Golo: "Warum gibt es zwei Wege auf null zu vergleichen?"

[@thenativeweb]

[gr] Sehr guter Punkt, gut aufgepasst 😊 Prinzipiell hast Du recht. Meine Antwort darauf wäre zweiteilig: - Alles, was mit "is null" geht, ging auch vorher mit "== null". Das heißt, es wurde neue Syntax für praktisch nichts eingeführt. Das hat die Situation nicht besser, eher schlimmer gemacht. - Dass es vorher auch nicht konsistent war, ist richtig, aber da würde ich C# noch zu Gute halten, dass es mit der Gleichheit vs Identität bei Werte- und Referenztypen in sehr vielen anderen Sprachen genauso aussieht (was es allerdings nicht besser macht, genau genommen).

[@anion21]

"is" und "==" haben ja unterschiedliche Bedeutungen. Mit "is" prüft man auf einen Typ, mit "==" vergleicht man auf einen Wert. Nun ist null weder Typ noch Wert, also wie prüft man auf null? Eines von beiden wird wohl nötig sein (oder man führt dafür einen extra Operator ein). Meines Erachtens ist "xy == null" intuitiv und durchaus konsistent (weil null auch sonst oft wie ein Wert behandelt wird, etwa bei Zuweiseungen) und folglich ist das einzig inkonsistente an C# bei dem Beispiel, dass "... is null" valide Syntax ist, obwohl man mit "is" hier nicht auf einen Typ prüft.

[@djchrisi]

@@anion21 Fair enough. Das ganze Thema 'vergleichen' ist ein riesen großer Clusterfuck in c#. Du hast - die üblichen ==, !=, , = Operatoren - Equals() - ReferenceEquals - IEquatable - IComparable Dann muss man auf Value, Reference, und Record Gleichheit achten. Oh und mein Favorit, delegate Gleichheit: Action a = () => Console.WriteLine("a"); Action b = () => Console.WriteLine("a"); Console.WriteLine(a == b); // False Console.WriteLine(a + b == a + b); // True Console.WriteLine(b + a == a + b); // False Aber sag's nicht Golo weiter!

[@thenativeweb]

@@anion21 [gr] Tatsächlich ist null in C# ein Wert - und zwar der einzig mögliche Wert von einem Typ, der ebenfalls null heißt, der sich aber anderweitig nicht instanzieren lässt.

[@heinrichschiller4673]

Bei Code-Magie sehe ich genauso wie Golo. Es ist schön wenn man paar Zeilen kann. Aber wenn man den Code dadurch schwerer nachvollziehen kann, hat man schlicht nichts gewonnen.

[@marcusreinicke]

Hallo Golo. Ich bin ein wenig enttäuscht von Dir. Du machst sonst immer so eine tolle Arbeit. Aber hier geht mit dir das Blut etwas durch. Jeder darf seine geliebte Sprache benutzen, mehr Sachlichkeit, als eine Rosa Brille für seinen Favorit steht Dir dann doch besser. Unsere Welten gehen halt komplett auseinander. Es ist schade, nur weil es Dich stört, muss es nicht falsch sein. Ich z.B. hasse Deine ach so,geliebten Algebraischen Datentypen. C# ist als eine hart Typenorientierte OOP Hochsprache entwickelt worden. Daher waren Funktionen außerhalb von Klassen, kein Thema. Und was Du sagst, dass C# sich nur an JAVA angelehnt hat, ist faktisch falsch. Es sollte als Pondon zu Java entwickelt werden. Viele Einflüsse beruhen nun mal auf c/c++ wie bei Java auch. Sehr viel mehr Einfluss (nicht die Syntax, aber die Struktur und der Aufbau) hat Delphi gehabt, weil schon der Erfinder von Delphi von Borland zu Microsoft gewechselt ist, um diese Sprache zu entwickeln. Delphi = ObjectPascal ? Rein OOP. Ich denke das sollte Dir noch ein Begriff sein. Java war zu dem Zeitpunkt, einer der schlechtesten und langsamsten interpretersprachen überhaupt, weit verbreitet, wegen der dynamischen Laufzeitumgebung, aber langsamer als so fast alles andere was es gab. C# ist eine strikte OOP Sprache, weshalb es keine Funktionen außerhalb von Klassen gibt, das war von Anfang an so gewollt, um die Probleme aus C/ C mit Klassen und dann C++ einzudämmen, denn C++ ist und bleibt ein Hybride, der OOP und prozeduralen, heute wohl die Funktionale Programmierung ermöglicht. Und mal Ehrlich, Du willst doch nicht wirklich Java Script, mit einer OOP Sprache vergleichen. Nein nicht Dein Ernst😢 Da wo die Größte sch… Variablen sind, die von einem unterschiedlichen Typ sein können. Du sagst es ist wunderbar, ich sage es ist Müll, weil der Code überhaupt nicht mehr lesbar ist. Was ist es jetzt, ein Int, ein String? Oh Gott, was für ein - ach ich wiederhole mich. Algebraische Strukturen oder Verweistypen? Junge, wer soll das mal so eben lesen können? Wie soll man den Code lesen können, wenn man keine IDE zur Verfügung hat, die einem dabei hilft. Gruselig, einfach Gruselig. Jede Programmiersprache nimmt Altlasten mit. Das beste Beispiel GOTO. in fast jeder Programmiersprache enthalten, wird von so gut wie von allen Programmierern ignoriert(zum Glück), weil es Müll ist diesen Befehl zu nutzen. Es macht den Code unleserlich. Das C# nicht die beste Sprache ist, wird so sein, aber es wird mit Deinen Aussagen Äpfel mit Birnen verglichen sorry, da hätt ich nunmehr etwas mehr Professionalität von Dir erwartet. Microsoft hat wirklich sehr sehr viel verschlimmbessert in den letzten Jahren. Ich frag mich auch öfter warum, aber das liegt auch daran, weil Umsteiger gerne Funktionalitäten haben wollen, die nie vorgesehen waren, die auch gar nicht zur Philosophie von C# passen. Aber es sind Sachen, die muss man nicht nutzen. 5 Timer jo, siechste mal, auch Microsoft macht Müll. Analyse? Funktioniert super. Ja es gibt EINE Datei, mit der ich arbeite. Projekte innerhalb einer Solution, bekommen einen Link dazu. Ich benutze StyleCorp, und bisher habe ich keine Projektdatei händisch dafür angepasst. JSON klar - fest typisiert -hatten wir gerade schon. Algebra.. Datentypen, nicht fest typisiert, wird von Haus aus abgelehnt, was gut ist. Es lässt sich einiges Abfagen mit Interfaces / Contracts damit gehts wunderbar, nur mit dem Unterschied, dass ich sofort sehe mir welchem Typen ich arbeite. DI und Polymorphie Aber wie gesagt, jeder darf das tun und verwenden was er mag. Du hast gesagt, es spiegelt Deine Wahrnehmung, bzw. Deine persönliche Abneigung wieder. Ja ist ok, das merkt man auch. Da es Deine persönliche Meinung ist, kann man es Dir nicht vorwerfen, aber wie gesagt, ich hätte mir hier ein wenig mehr Proffessionalität gewünscht, vor allem, Weil ich es so von Dir gewohnt bin. Ansonsten spiegelt es das typische Klischeedenken der Java und der .Net Faktion wieder. Was schade ist, denn wir alle versuchen das beste zu machen.

[@thenativeweb]

[gr] Danke für Deinen ausführlichen Kommentar. Natürlich finde ich es schade, dass Du das Video als dermaßen unprofessionell empfindest - denn eigentlich habe ich mich bemüht, nicht einfach nur zu sagen "C# ist doof", sondern konkrete Punkte zu benennen, und sie argumentativ zu belegen.

[@marcusreinicke]

@@thenativeweb lieber Golo, ich möchte noch mal sagen, dass es nix persönlich ist. Du weißt glaub ich, dass ich von Dir eine sehr gute Meinung habe und dass ich sehr viel von Dir halte. Fachlich gesehen und wie Du in den Videos rüberkommst. Persönlich kennen wir uns ja (noch) nicht. Und genau da liegt der Knackpunkt. Für mich bist Du jemand, der fachlich begeistern kann. Viele Leute nehmen Deine Meinung ernst und übernehmen sie. Auch ohne sich eine eigene Meinung zu bilden. Das polarisiert und steuert durch Deine Reichweite. Leider kam es für mich so rüber, dass C# es nicht mehr Wert ist. Aber dem ist nicht so. Wenngleich Microsoft in den letzten Jahren, mühe gibt und C# kaputt verbessert. LG Marcus

[@yahmk3978]

Vielen Dank!

[@thenativeweb]

[gr] Gerne 😊

[@KaterMedia]

2. Beispiel warum geht das nicht: einfach eine klasse dafür implementieren die von beiden Typen in einen gemeinsamen Typen parsen kann. Oder dynamic. Oder irgendeine andere Lösung, gibt schon ein paar Möglichkeiten.

[@thenativeweb]

[gr] Wir hätten halt gerne so etwas gehabt wie List … wo Du also eine Liste hast, die garantiert nur Strings, nur Zahlen, oder beides enthält - aber eben keine boolschen Werte zum Beispiel. Und das kann man nicht mit List lösen, da muss man dann zu object greifen - oder man nutzt dynamic und verzichtet auf jegliche Typisierung, oder ja … also ja, "Lösungen" gibt es schon, aber wirklich gut ist keine davon, und es wäre halt so einfach, wenn C# so was wie Union-Types unterstützen würde …

[@Hofer2304]

@@thenativeweb Disjunkte Typen gibt es ja schon in Pascal. Wenn man glaubt darauf verzichten zu können, sollte man in einem Rationale erklären warum.

[@BenjaminWagener]

Ich hatte mal überlegt tiefer in C# einzusteigen, es dann aber verworfen, weil es zu dem Zeitpunkt noch nicht konsequent nativ cross-platform war. Mit dem Video jetzt bin ich sehr froh, mich so entschieden zu haben. Ich fühlte mich bei dem Vortrag aber auch des öfteren an die Probleme erinnert, die ich gerade so beim Lernen von JavaScript, insbesondere als Fullstack-Sprache erlebe. Für zig Sachen ist man von zusätzlichen Bibliotheken oder ganzen Frameworks abhängig, damit sie bequem laufen, die dann aber die Dinge jeweils völlig unterschiedlich lösen und wo es dann von Version zu Version viel zu häufig Probleme mit der Kompatibilität innerhalb der Versionen oder mit anderen Paketen gibt , sodass man ein Projekt nie einfach nur fertig stellen und nur hier und da mal Sicherheitsupdates einspielen muss, sondern immer wieder rumfrickeln muss. Weshalb ich schon beim Lernen jegliche Lust verloren habe mit JavaScript bzw. auf Node basierend ein langfristiges Projekt aufzubauen. Das ist aber auch alles nicht verwunderlich, denn schließlich kennen wir ja die Story wie überhastet JS enstanden ist und dass es für die Menge an Anwendungsfällen, wozu es heute so alles genutzt wird, nie vorgesehen war.

[@BH-pk6ng]

"OMG Leute C# is rückwertskompatible, ich bin verwirrt!!!1!" Wenn man aus einer Welt kommt in der diese Woche 3 neue Frameworks released wurden von denen zwei wieder veraltet sind kann ich verstehen das man C# verwirrent finded. Weil sachen da wiederverwendet werden können und nicht immer weggeschmissen und neu gemacht werden wie in JS.

[@thepaulcraft957]

Koenntet ihr mal ein Video zu python in der cloud machen? Ich finde python ist eine super sprache und mich wuerde eure meinung als profis dazu interessieren.

[@thepaulcraft957]

@@sven2529 ok, ich verstehe den Punkt mit geschweiften klammern aber ansonsten find ichs eigentlich super. Das typsystem ist aehnlich strikt (mit ner richtigen IDE) wie das von ts und es fuehlt sich sehr in sich geschlossen an.

[@wizardgamer1005]

das ding ist JavaScript hat genauso viele inkonsistenten und ausnahmen, aber da gibt es schon viele punkte die bei c# einfach nicht so sein müssten da hast du recht.

[@bernderbabo]

Ich mag Go.

[@thenativeweb]

[gr] Das ist schön 😊

[@valeridause]

Ich finde solche Vergleiche mit anderen Sprachen sehr kontraproduktiv. Als ob ich jetzt Deutsch und Englisch vergleichen würde. Denn viele Fälle, Adjektive, trennbare Verben usw. - spricht was gegen Deutsch. Dennoch genau wie mit c# - Millionen Menschen wenden sie an, auch, wenn sie nicht perfekt ist. Denn es gibt weder perfekte Programmiersprache noch menschliche Sprache..daher - es sieht nach Haarspalterei aus..

[@thenativeweb]

[gr] Ich habe auch nicht gesagt, dass andere Sprachen perfekt wären - ich habe nur aufgezeigt, was die Punkte sind, die mich persönlich an C# besonders stören. Und das sind im Vergleich zu den Sprachen, mit denen ich sonst zu tun habe, auffallend viele Dinge. Und wie ich auch eingangs gesagt habe: Es gibt auch Dinge, die mir an C# gefallen, nur um die ging es im Video halt nicht. Ich kann aber verstehen, dass Du solche Vergleiche nicht magst. Wobei es letztlich auch kein Vergleich war, ich finde es ganz unabhängig davon, wie Go, TypeScript oder sonstwer gewisse Probleme lösen, einfach "unschön", dass C# derartige Probleme mit JSON, mit algebraischen Typen, mit yield, … hat. PS: Millionen Menschen gehen auch bei rot über die Straße, das macht's aber nicht besser 😉

[@valeridause]

@@thenativeweb Danke für die Antwort. Der Vergleich mit "auf rot zu gehen passt zwar nicht", denn das kein normales Vorgehen ist, und ja, du hast es auch erwähnt, dass du c# nicht ins schlechtes Licht führen möchtest. Doch genau das machst du es - mit all den Aussagen wie "seit Jahrzehnten haben sie es das oder das andere nicht hingekriegt". Du hast Recht dazu, deine Meinung dazu zu sagen. Jedoch von der Seite sieht es ein wenig "kindisch" aus, als ob dir zu wenig von der Muttermilch übrig gelassen wurde und deswegen bist du irgendwie sauer. Als ob du sauer sein muss. Du vermisst Funktionen ohne Klasse, viele wiederum finden das richtig, Du brauchst ein Array mit unterschiedlichen Datentypen, ich wiederum würde sagen - so was dürfte gar nicht geben usw. Wie du aus meinen Beispielen entnehmen kannst - ich finde c# sehr gut. Auch, wenn man sich dort einiges vorstellt, bedeutet es nur, ob es schwerwiegend ist, so dass man eventuell eine andere Sprache für die Lösung seiner Probleme wählen sollte. Z.B. Auch, wenn ich mit c# Office Add-Ins schreiben kann, wird sehr oft trotzdem zu VBA zugegriffen. Auch, wenn die Sprache und der Editor grausam sind. In der deutschen Sprache werden seit Ewigkeit plus ein Tag die Zahlen rückwärst ausgesprochen - zwei und zwanzig, und es gab schon einige Versuche, es zu ändern - doch es bleibt vorerst so wie es ist. Sich drauf fest zu nageln, führt meiner Meinung nach zu nichts. Ich bin der Meinung - man soll die Sprachen nicht gegeneinander vergleichen, sondern aufzeichnen, welche Sprachen was besonderes haben - angefangen von Assembler. In jeder Sprache gib es etwas, was die Sprache von der besseren Seite ausmacht. Und, wenn man die Konzepte dahinter lernt, dann wird es auch einfacher, in nicht unbedingt "passenden" Sprachen sich trotzdem zu Recht zu finden. Denn darum geht es doch in der Entwicklung - Erfahrungen sammeln, um komplexe Probleme von Morgen besser lösen zu können. Ein anderes Beispiel für "ähnliche" Kritiker von der Gesellschaftsform "Demokratie" - die Worte von Winston Churchill - "Demokratie ist die schlechteste aller Regierungsformen - abgesehen von all den anderen Formen, die von Zeit zu Zeit ausprobiert worden sind." Denn in allen Sachen kann man vieles finden, was negativ aussieht, doch manchmal reicht es vollkommen aus, was man bereits hat. Danke dir trotzdem! Deine Art Videos zu machen ist sehr spitze! Sehr professionell. Ein Abo bei dir ist wertvoll!

Abgesehen davon, dass auch gesprochene Sprachen miteinander verglichen werden können, können und müssen Programmiersprachen miteinander verglichen werden - sie sind Ergebnis eines Designprozesses mit einem bestimmten Ziel. Dieses Design (und das dadurch entstehende Ökosystem) sollte dazu passen, wie und was ich mit meiner Anwendung erreichen möchte. Eine Programmiersprache ist Teil meiner Technologieentscheidung und wird so zu einem Teil meiner Architektur. Es gibt Sprachen, die passen besser zu dem, was ich tun möchte - andere Sprachen passen weniger. Auch, wie eine Sprache mich beim Erreichen meiner Ziele unterstützen kann (oder dabei für Verwirrung sorgt), berücksichtige ich bei meiner Entscheidung. Es geht nicht um die perfekte Programmiersprache - es geht um die Sprache, die mich beim Erreichen meiner Ziele bestmöglichst unterstützt. Und da wird es mehrere geben - deren Features müssen gegenüber gestellt werden. Dabei könnte auch interessant sein, wie Programmiersprachen sich entwickelt haben, was die getroffenen Designentschiedungen waren.

[@valeridause]

@@sven2529 danke für deine Antwort. Ich sehe es anders. Vergleiche mit Straftaten und Fleischkonsum und anderen schädlichen Sachen passt nicht zu "c# ist Murks, weil...". Golo macht schon n.-Sendung, wieso c# schlecht ist. Mensch, er kann doch aufhören, in dieser Sprache zu programmieren. Es gibt doch bessere. Ihn zwingt doch keiner. Doch immer wieder sich die c# anzuknüpfen, um etwas darin schlecht zu finden - es scheint, dass er das irgendwie sehr persönlich annimmt. Daher sage ich - einseitige Betrachtung. Und dadurch - wenig hilfreich. Aber - es ist meine persönliche Meinung. Diese muss du nicht teilen. Danke und LG,

[@pantolein]

Ich glaub das ist einer meiner ersten KZbin Kommentare überhaupt. Aber der Rand gegenüber C# find ich persönlich sehr lächerlich, teilweise echt sehr oberflächlich. Hier werden persönliche Eindrücke aus gefühlt einem Projekt wiedergegeben? Da werden vergleiche mit Typescript und Javascript gemacht ohne zu verstehen, dass des ein Vergleich zwischen Motorboot und Hobbyflugzeug ist? Hier werden Typen wie Any angepreißt, die der in meiner persönlichen Sicht der größte Schmutz aus der Javascript Welt ist. Das ganze Video klingt einfach in jedem Kapitel nach "ich will dreckigen Dirrty Code schreiben, warum geht das mit C# nicht". Ja, weil die Typisierung dafür sorgt, dass Leute aus der Welt, selbst mit wenig Ahnung von C# die Datei noch lesen können ( gesetz dem Fall, man hält sich auch an zb. den Microsoft Spezifikationen). Auf die einzelen Punkte will ich erst gar nicht eingehen. Reg ich mich gerade viel zu sehr auf. Es gibt so unfassbar viel, was man bei C# kritisieren kann. Aber die genannten Punkte sind teilweise Probleme aus dem ersten Lehrjahr. "Das Video soll nicht dafür da sein C# nieder zu machen, aber ..." .... und dann im Titel "Warum C# murks ist" rein hauen. Sind wir auf solchem Click Bait Niveau angekommen? Natürlich versteht man, wenn man aus der Javascript / Typescript Welt kommt die Grunkonzepte von C# nicht. Weils eben nicht so "anarchistisch" wie Javascript ist. Und man sich an Regeln halten muss / soll. Die wiederrum dazu führt, das Code einfacher, lesbar, wartbar und pflegeleichter werden soll. Sorry, aber das Video ist wieder nen Paradebeispiel dafür, wie man unsachlich versucht Fachthemen zu zerreissen, nur weil man persönlich nen Problem hat. Es gibt genug Punkte, wo man C# in der Luft zerreissen kann. Aber die Argumentation in die hier gebracht wurde, ist in meinen Augen einfach lächerlich und vorallem unsachlich einseitig.

[@jeyt436]

Ich nutze C# (noch) nicht. Deswegen kann ich dazu nichts sagen.

[@thenativeweb]

[gr] Wäre mal interessant, zu sehen / hören, wie jemand, die oder der die Sprache (noch) nicht kennt, sie einschätzt, wenn man mal anfängt, sich mit ihr zu befassen … 😊

[@jeyt436]

@@thenativeweb ja

[@fflecker]

Ich mache Java und frage mich, wie überhaupt bei solchen Fehlern C# professionell einsetzbar ist. Das fasse ich doch im Leben nicht an.

[@espiat9505]

war es schon immer

[@thenativeweb]

[gr] Das ist böse, aber im Hinblick auf gewisse Punkte hast Du nicht ganz unrecht 😉

[@WolfgangEgger]

C# hat mich noch nie interessiert ;-) Ich wünsche mir aber ein TypeScript für Fortgeschrittene in 90 Minuten DeepDive - Video

[@mkienle5460]

Jetzt ist mir klar, dass ich C# nie lernen werde. Vielen Dank.

[@halvarf]

Vielleicht erstmal das Video gucken, Golo's Clickbait-Titel sind ja bekannt ... C# ist ne gute Sprache mit gutem Tooling und sehr breiten Verwendungsmöglichkeiten.

[@halvarf]

@@sven2529 Haha, der Spruch "eher so Boomer Ding" ist halt auch eher so'n Zoomer-Ding. Zumal sowas auch gerne von Leuten kommt, die irgendwo an der Uni wissenschaftlich irgendwas mit Machine Learning programmieren und die Bedürfnisse, die C# deckt, noch nie gesehen haben. Richtig traurig ist es, wenn sowas von Leuten kommt, die Javascript für toll halten, 60 bis 80% ihrer Zeit mit Debugging verbringen und einfach wie Blinde von der Farbe reden.

[@themacaroni8460]

Das Video ist der richtige murks. Sorry

[@TheOnlyDominik]

Was hat eine Timerfunktion in einem .Net Framework mit der Programmiersprache C# zu tun! Themaverfehlung, setzen 6.

[@TheOnlyDominik]

Mach mal bitte ein Video "5.000.000 Gründe, warum JavaScript scheiße ist"! Ich versteh dieses sinnlose Video nicht. Ich kann in C# alles machen, von der Entwicklung von Spielen bis zu Business-Software als WebApp oder App für Android oder bäh Apple. Diese sinnlosen Diskussionen braucht kein Mensch. Es ist eine professionelle flexible Programmiersprache. Das einzige was mich an C# stört ist, das es wie C++ allmählich verbastelt wird. Bald kann man den Code nicht mehr vernünftig lesen, aber man muss ja nicht alle Features verwenden, was ich empfehle!

[@pinkeHelga]

Ich bin ja noch von der ganz alten Schule, und mich stört z.B. auch, daß nicht konsequent self:: / this. Pflicht ist. Im Gegenteil, empfohlen ist sogar die Auslassung.