Interessante Überlegungen/Argumente zu den einzelnen Sprachen! Was ich bislang mache: Die Klassiker (Hauptsächlich C#, Typescript, Javascript, Python) Was ich interessant fänd: Rust, Go, WebAssembly
Ich verwende beruflich (Common) Lisp. Das hört sich nach Deiner Erläuterung sonderbar an, hat aber seinen Grund: Man kann in Lisp durch Metaprogrammierung sehr einfach DSLs (Domain Specific Languages) bauen. Das hilft mir sehr dabei, Software zu machen, die große Datenmengen flexibel und schnell untersuchen kann.
Naja, wenn man mal recursiv absteigende Parser programmiert hat, dann macht man das immer noch am liebsten direkt in C 🤣. Aber Lisp Performance ist halt bei grossen Datenmengen total untauglich mit modernen CPU Architekturen wegen voellig fehlender Cache Locality. Arrays, arrays, arrays und nicht Listen sind gefragt.
@@llothar68 Exakt falsch. Ich erreiche mit einer Analysesprache für Logfiles einen Durchsatz von 130000 Datensätzen pro Sekunde, da die auf der Console eingegbenen Queries direkt in nativen x64 Code umgesetzt werden. Das Zauberwort heißt Homoikonizität.
Sehr gut, danke! Ein tolles Video! Schöne Auswahl von Sprechen, speziell Lisp als Impulsgeber für spätere Sprachen. Bei Go hätte ich noch einen Hinweis auf die einfach einzusetzende Nebenläufigkeit erwartet. Meine aktuellen Sprachen: C++, C#, Python, Go. Deiner Bartfarbe entnehme ich, dass wir vermutlich ähnlicher Jahrgang sind, und ich habe auch viele andere Sprachen probiert. Du hast vollkommen recht, dass jede neue Sprache einfacher zu lernen ist als die vorhergehende. Prolog fand ich aber trotzdem echt schräg, und als jahrzehntealter C++-Nerd hatte ich bei Python massive Einstiegsprobleme. Ich habe mich allerdings durchgebissen, weil mir die Vorteile klar waren, und bereue es nicht -- es war im Gegenteil sehr erhellend und nützlich! :) Go war dagegen ein Klacks, auch dank eures Einstiegsvideos (und jeder Menge On- und Offline-Doku) Alles Gute!
Aktuell bin ich mit Python unterwegs. Go hört sich so spannend an - einfach weil es in mein Umfeld passen könnte. Als kleine Geschichtsstunde werde ich mir Lisp ansehen.
Ich bin aktuell dabei JavaScript bzw. TypeScript und darauf aufbauende Frameworks zu lernen, einfach weil das der aktuelle Status Quo in der Webentwicklung it, dass man da nicht dran vorbei kommt insbesondere spätestens, wenn es ums Frontend geht, da kann WebAssembly NOCH nicht hinreichend Ersatz leisten. Als nächstes hatte ich dann Kotlin auf dem Schirm, weil aktuell die Hauptsprache für Android-Apps und weil die JVM halt immer noch ein gewichtiges Thema im Web-Backend-Bereich spielt. Und dann habe ich Rust auf der Roadmap, weil es für mich einfach DIE Sprache der Zukunft ist, wenn es um Ressourcen-sparende Lösungen geht. Ich denke, mal sie wird langfristig auch im Endanwenderbereich mehr eine Rolle spielen, wenn erstmal die ganzen Laufzeitumgebungen usw. alle mit Rust stabilisiert wurden und der Freiraum da ist, sich dann in den Frontend-Bereich zu gehen. WinUI, Qt, GTK dürften da entsprechend portiert werden...
Ich bin aktuell dabei Rust zu lernen, da aktuell immer häufiger Tools in Rust geschrieben werden. Bisher ist sind das typsystem und borrow checker zwei tolle Eigenarten der Sprache.
Ich habe mich auch an Rust probiert, komme von Java, C++ und ein paar Frontend-Frameworks und... irgendwie habe ich enorme Probleme mit dem Borrowchecker, keine Ahnung warum.
Professionell verwende ich hauptsächlich C#. Privat ebenfalls, und dazu noch das gute, alte C++. Aber ich habe mir in den letzten Monaten auch Rust und WebAssembly angesehen, vor längerer Zeit auch Go, und mit Lisp habe ich in meiner Jugend herumgespielt. Womit ich noch keine Erfahrung habe, ist Julia.
Wieder ein sehr interessantes Thema! 👌 Oft könnten Eure Videos nur ein paar Praxisbeispiele verbssern. Hier zim Beispiel: Quelltextauszpge und Ergebnisse zeigen, wäre super interesssnt gewesen.
Aktuell verwende ich Go in Verbindung mit dem Gin-Framework als Backend/REST-Service und React im Frontend-Bereich. Spannend finde ich Rust. Allerdings denke ich, dass ich mit Go für die Webentwicklung besser aufgehoben bin. Mit Gin und Echo gibt es hier zwei etablierte Frameworks. Bei Rust ist das Feld noch etwas übersichtlich - soweit ich das beurteilen kann. Anwendungsfälle in denen man jedes Byte noch mit seinem Vornamen ansprechen muss, habe ich kaum. :-)
@@lokthar6314 Auf der Website von Gin wird es aber als Web Framework beworben. Ebenso bei Echo: High performance, extensible, minimalist Go web framework. Dann haben die das wohl falsch hingeschrieben. 🙂
[gr] Vielen Dank 😊 Ja, den Hoodie (und auch die T-Shirts) kann man bestellen - wenn Du Interesse hast, melde Dich einfach kurz per E-Mail bei uns, unter hello [at] thenativeweb [dot] io 😊
Год назад+1
Was hältst Du denn von Dart / Flutter? Ist das eine glaubwürdige Alternative? Oder meinst Du (oder Dein Team), dass React Native eine bessere Basis (für Cross-Platform APP-Gedevelope) ist? Kurze Frage: Was haltet Ihr von Dart?
Mit Go werd ich nicht so richtig warm, allein schon, weil es eine "no-go" Formatierung vorschreibt. (Was für ein Wortspiel 😅) Deine Ausführungen sind aber treffend. Mittlerweile zweifele ich sogar schon den Sinn von OOP an. Es wird ja immer die Kapselung gelobt. Im Endeffekt ist es aber nichts anderes als das Mißtrauen gegen sich selbst und den Rest des Teams. Ich fand es auch lange Zeit toll, alles private und protected zu deklarieren, wobei Vererbung - der ursprüngliche Sinn von OOP - mittlerweile ja auch schon verpönt ist, also gilt protected auch schon wieder als böse. Es werden häufig also lieber komplexe Strukturen entworfen, statt einfach zu vererben. Statt alles streng zu kapseln, kann man auch Namespaces verwenden und Namenskonventionen, die anzeigen, daß etwas nicht für den externen Zugriff angedacht ist. Manchmal macht es aber dennoch Sinn, direkt einzugreifen, statt einen riesigen Workaround zu schreiben und die Komplexität weiter zu erhöhen. Das muß ja nicht geschehen, wenn das Modul noch in der Entwicklung ist und Änderungen wahrscheinlich sind. Darüber hinaus gibt es dann noch den sealed Schutz. Solange das die Laufzeit maßgeblich verbessert, ist es ja nachvollziehbar, aber es wird für meinen Geschmack auch zu exzessiv eingesetzt. Rust ist eine interessante Alternative, die ich mir bislang nur ganz kurz mal angesehen habe. Garbage-Collection ist sowieso nicht mein Ding. Ich behalte die Verantwortung für die Speicherbelegung lieber unter Kontrolle. So kann man auch Speicherbereiche unterschiedlich interpretieren, ohne Bitoperationen Hi/Lo Teile einzeln lesen/schreiben etc. Mir gefällt hardwarenahe Operation, das bedeutet einen maximalen Grad an Freiheit. C++ hatte ich mal gerne programmiert, aber mittlerweile werden mir da zu exzessiv Makros für jeden Furz eingesetzt. Julia klingt sexy, kannte ich noch gar nicht. Ein kompilierter Pythonverschnitt wär mal was.
Ich finde es sehr angenehm, dass bei Go die Formatierung vorgegeben ist. Dort lässt sich auch nicht so viel machen, da das Ende der Zeile klarmachen muss, ob es in der nächsten Zeile weitergeht.
Год назад+1
also bei LISP und Rust bin ich dabei :) - Julia denke ich nur wenn man schon Python kennt (sonst lieber das) ... bekommen wir jetzt vielleicht klassisches SICP ;P Wer sich Richtung Typsystem (also z.B. Rust) interessiert, dem würde ich je nach dem woman her kommt Haskell (da bekommt man "fast" alles) oder gar eine dependent-typed Sprache wie Agda empfehlen. Ansonsten denke ich sowohl LISP als auch RUST dürften die meisten Entwickler deutlich länger als ein Jahr beschäftigen - vor allem wenn man die "Ideen" wirklich verstehen will. Go geht vielleicht schneller (?) WebAssembly lernen? Hmm IMHO nur wenn ich z.B. zu Sprachen contributen will, die das (zukünftig) als Target haben. Ansonsten IMHO ähnlich sinnvoll wie Assembler zu lernen - nicht verkehrt aber praktisch oft nicht sooo relevant.
Assembler ist nicht so furchtbar kompliziert. Und da ja heute sehr viel über Systemaufrufe und Bibliotheken passiert, spielt die Sprache ansich im Endeffekt auch nicht mehr so die große Rolle - nur eben die Standardbibliothek, die eine Hochsprache von Hause aus mitbringt. Da hat Assembler halt keinen "built-in". An ASM weiß ich aber zu schätzen, daß man viel mehr Strukturen entwerfen kann als die klassischen Standardkonstrukte der Hochsprachen, und auf Bitebene arbeiten ebenso. Will man nur für berufliche Zwecke eine Sprache lernen, ist ASM natürlich nur mehr eine Nische für embedded systems und ansonsten kaum gefragt.
Год назад
@@pinkeHelga Ich weiß - ich glaube meine ersten Assembler-Programme habe ich vor 30 Jahren geschrieben ;) - aber gebraucht hab ich das abgesehen von Spielereien, ein paar Jahren für Systemaufrufe in MSVC++ und die letzten 20 Jahre vielleicht noch für ein paar Advent-of-Code Aufgaben nie mehr ;)
Sehr gut du kommentiert, ich glaube, die ganzen Programmiersprachen sind nichts für mich. Ich muss wohl mehrere Jahre warten, bis eine Programmiersprache herauskommt, das besser zu mir passt. Mal sehen, ich schaue mir Lisp mal an, aber ich glaube, dass ich damit auch nicht klarkomme.
Bisher C# (meist BE mit ASP) und TS (meist FE mit Svelte). Besonders spannend find ich GO, Rust und Julia Ich würde mich auch gerne mal mit C beschäftigen, aber nur aus Neugier.
C ist auch gar nicht mal schlecht. Im Prinzip läßt sich auch alles damit machen, und das quasi auf jedem System, vor allem auch enbedded systems. Ist halt back to the roots ins prozedurale Zeitalter, was auch nicht verkehrt ist . Ich bekomme nach Jahrzehnten OOP allmählich Zweifel, ob das nicht in eine falsche Richtung geführt hat. Oft erlebe ich Overengineering. Etwas gewöhnungsbedürftig ist, wenn man Sprachen auf höherem Level gewohnt ist, daß es keine Strings kennt. Man arbeitet mit Zeigern direkt auf Speicherbereichen und hat keinen Schutz, daß man über reservierte Speichergrenzen hinaus schreibt. Dafür ist man selbst verantwortlich. C++ hat dagegen eine CString Klasse.
"NSA Releases Guidance on How to Protect Against Software Memory Safety Issues" ist ein lesenswertes Dokument. Lange Zeit galt C noch als Sprache, die man für den Linux-Kernel benötigt, aber es sieht nun doch so aus, als würde das schrittweise durch Rust ersetzt werden. Im Prinzip hat die NSA sich hierin deutlich gegen C/C++ ausgesprochen: "NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible."
@@pinkeHelga Das mit der OOP kann ich gut nachvollziehen. C# versucht hier mit weiteren Features häufige Muster etwas zu kürzen, aber ich persönlich verwende dann doch sehr häufig bewusst die umständlichere Schreibweise. Die etwas direktere Art und Weise von Go gefällt mir auf dem ersten Blick sehr gut. C++ wirkt in der Hinsicht eher abschrecken auf mich. Hab kürzlich ein Video gesehen in der eine kurze Funktion mit einer Schleife und 2 Ifs mittels ranges::accumulate, rv::iota und rv::filter "verbessert" wurde. Man hätte mit einer weitere Funktion und einem early return eine völlig unmissverständliche Lösung bauen können. Das was da rauskam war ein rech fremdes konstrukt. In Go baue ich darauf, dass sowas eben nicht entsteht.
@@pinkeHelga Overengineering - ein wahres Wort. Habe gerade zwei Anwendungen mit Go und dem Gin-Framework am Start, nachdem ich vorher längere Zeit mit Spring Boot und Java gearbeitet habe. Go und Gin, einfach super-pragmatisch und unglaublich schnelle Startzeiten. Cross-compiling finde ich auch eine tolle Sache - unter Windows für Linux kompilieren.
Die Fehlerbehandlung in Go ist fehleranfällig, da man Fehler ganz einfach ignorieren kann. Was das mit guten Sprachdesign zu tun hat, ist mir ein Rätsel.
Grundsätzlich ist es ziemlich utopisch zu behaupten man könne 5 Sprachen und ist auch bei allen up to date, kennt die gängigen Framesworks etc. Eine Sprache zu können erfordert mMn. etwas mehr als "ich kenne die Syntax und kann sie lesen und schreiben". Vorausgesetzt man zählt "sich sehr ähnliche Sprachen" nicht einzeln.
Ja. Ich bin jetzt auch nicht professionell tätig und für eine einzige Sprache (was ja durchaus evtl. sinnvoll wäre) kann ich mich definitiv nicht entscheiden. Das hatte ich schon versucht. Also schaue ich mal wie weit ich komme mit den 2.5, die ich jetzt festgelegt habe. JavaScript habe ich übrigens rausgeschmissen, weil ich da einiges zu gesehen hatte und das hat mir einfach nicht gefallen, sowohl vom Tempo der Vortragenden, als auch von der allgemeinen Attitüde, die ich da so mitgenommen hatte. Wahrscheinlich können viele von Euch schon JavaScript, aber ich werde dann sehen, ob ich drum herum komme...
@@claus7555 Hab ich das richtig verstanden: Du machst es also vom "Tempo der Vortragenden" und deren "Attitüde" abhängig, ob du eine Programmiersprache lernst?
Die Verbindung zwischen OOP + FP mit Scala finde ich weiterhin genial. Leider lässt das Ökosystem etwas zu wünschen übrig - die IDE-Überstützung war lang nicht optimal. Das Build-Toll sbt ist auch nur so mittelprächtig.
Ich warte noch immer darauf, dass mir ein realer use case über den Weg läuft, den ich mit TypeScript / JavaScript nicht zur Zufriedenheit umsetzen kann. In meinem beruflichen Umfeld geht es zu 100% um Web- und Cloud Entwicklung. Vue, Nuxt. Backend ist de facto immer in AWS, ob nun „klassisch“ Serverless mit API GW, Lambda, SNS, SQS, EventBridge und Co oder als Container in ECS on Fargate. Wenn es eine HTTP API benötigt und API GW nicht das Mittel der Wahl ist, wird es ein Fastify Backend oder eben direkt Nuxt. Ich habe noch keinen Fall gesehen wo ich gesagt hätte „jetzt bräuchte ich hierfür Go oder Rust“.
Ich finde es enttäuschend wenn Programmiersprachen etablierte Begriffe neu belegen. Wie Rust, "match" für "switch case" verwendet, wobei "match" bei allen normalen Leuten fest mit pattern matching verbunden ist. Kann man natürlich argumentieren, "Ja aber darum geht es ja beim neue Sprachen lernen. Es soll weh tun im Kopf. Das ist Lernen." Ne, für mich ist es zeichen für schelchtes Sprachdesign. Auch wenn ich selbst noch nie eine Sprache selbst entwickelt habe, kann ich es als Sprachanwender behaupten. Warum dann nicht Ruby, oder Netlogo? Netlogo - total coole Sprache die funktionen mit "to" deklariert. Mega genial. Funktion soll ein Verb sein, und um die zu deklarieren schreibt man "to" und dann hat man bspw. "to start()" und dann den Körper, und dann "end". Sehr zugänglich.
Ich glaube hier wurde das match in Rust noch nicht ganz verstanden. Man kann das zwar für "switch case"s nutzen, aber das Konzept ist viel größer als das. So kann ich zum Beispiel matchen ob ein dreiteiliges Tupel als erstes ein Ok mit irgendeinem Inhalt, als zweites eine Zahl zwischen 1 und 10 und als drittes einen beliebigen Wert hat. Und solche Konstrukte sind nur der Anfang. Rust bietet mit Match ein sehr ausgiebiges pattern matching, weshalb der name "match" doch recht passend ist.
Ich schaue RUclips auf unterschiedlichen Endgeräten und Clients: hauptsächlich im Browser (Chrome) auf meinem Macbook, auf meinem iPhone und auf meinem LG webOS TV. Auf keinem dieser Endgeräte sehe ich die ominösen Infocards. Was mache ich falsch? PS: wie immer super Content!
Java Script ist sicherlich etwas zu common um explizit erwähnt zu werden.. früher oder später kommt man ja ohnehin nicht daran vorbei 😉
Год назад
@@YaXTuber Ich dachte daran, dass es auch in 2023 noch Leute gibt, die man dazu auffordern muss, Vorbehalte gegen JavaScript abzulegen. Und damit - richtig -anzufangen.
@ die Vorbehalte hab ich zum Teil auch noch.. das liegt in erster Linie daran, dass ich Ordnung mag. Java Script kann man auch ordentlich schreiben, aber das heißt letztlich nicht, dass dies auch gemacht wird. Manchmal ist es besser, weniger Freiheitsgrade und klare definierte Grenzen zu haben 😉 ... und ein TypSystem .. 🤐
Год назад+1
@@YaXTuber Ich dachte das auch viele Jahre (Jahrzehnte). Allein um festzustellen, dass ein Typ-System auch nicht von schlechtem Code abhält. Und wer wirklich ordentlich arbeitet, schenkt sogar PHP lyrische Qualitäten 🙂
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Interessanter Beitrag!
Ich hab mir Dank euch schon go näher angesehen, doch jetzt hast du mich entgültig davon überzeugt Mal lisp auszuprobieren
Interessante Überlegungen/Argumente zu den einzelnen Sprachen!
Was ich bislang mache: Die Klassiker (Hauptsächlich C#, Typescript, Javascript, Python)
Was ich interessant fänd: Rust, Go, WebAssembly
Ich verwende beruflich (Common) Lisp. Das hört sich nach Deiner Erläuterung sonderbar an, hat aber seinen Grund: Man kann in Lisp durch Metaprogrammierung sehr einfach DSLs (Domain Specific Languages) bauen. Das hilft mir sehr dabei, Software zu machen, die große Datenmengen flexibel und schnell untersuchen kann.
wofür würde man DSLs brauchen?
Geht in Kotlin auch sehr gut, schreibe auch selber DSLs
Naja, wenn man mal recursiv absteigende Parser programmiert hat, dann macht man das immer noch am liebsten direkt in C 🤣. Aber Lisp Performance ist halt bei grossen Datenmengen total untauglich mit modernen CPU Architekturen wegen voellig fehlender Cache Locality. Arrays, arrays, arrays und nicht Listen sind gefragt.
@@llothar68 Exakt falsch. Ich erreiche mit einer Analysesprache für Logfiles einen Durchsatz von 130000 Datensätzen pro Sekunde, da die auf der Console eingegbenen Queries direkt in nativen x64 Code umgesetzt werden. Das Zauberwort heißt Homoikonizität.
@@xdevs23 Es würde mich interessieren, wie das geht.
Danke für die tollen Infocards und Informationen, damit kann man super lernen!
[gr] Das freut mich, vielen Dank 😊
Sehr gut, danke! Ein tolles Video!
Schöne Auswahl von Sprechen, speziell Lisp als Impulsgeber für spätere Sprachen. Bei Go hätte ich noch einen Hinweis auf die einfach einzusetzende Nebenläufigkeit erwartet.
Meine aktuellen Sprachen: C++, C#, Python, Go. Deiner Bartfarbe entnehme ich, dass wir vermutlich ähnlicher Jahrgang sind, und ich habe auch viele andere Sprachen probiert.
Du hast vollkommen recht, dass jede neue Sprache einfacher zu lernen ist als die vorhergehende. Prolog fand ich aber trotzdem echt schräg, und als jahrzehntealter C++-Nerd hatte ich bei Python massive Einstiegsprobleme. Ich habe mich allerdings durchgebissen, weil mir die Vorteile klar waren, und bereue es nicht -- es war im Gegenteil sehr erhellend und nützlich! :) Go war dagegen ein Klacks, auch dank eures Einstiegsvideos (und jeder Menge On- und Offline-Doku)
Alles Gute!
Spannendes Video, danke.
Ich bin Momentan primär mit C# unterwegs mit Ausflügen in PHP und Python.
Python will bei mir bisher nicht so zünden 😅
Kann ich verstehen. Python kann echt viel, aber ich mag es einfach nicht. 😢
Aktuell bin ich mit Python unterwegs. Go hört sich so spannend an - einfach weil es in mein Umfeld passen könnte. Als kleine Geschichtsstunde werde ich mir Lisp ansehen.
[gr] Lustigerweise ist es bei mir gerade umgekehrt - ich habe im Moment ein bisschen mehr mit Python zu tun 😊
Ich bin aktuell dabei JavaScript bzw. TypeScript und darauf aufbauende Frameworks zu lernen, einfach weil das der aktuelle Status Quo in der Webentwicklung it, dass man da nicht dran vorbei kommt insbesondere spätestens, wenn es ums Frontend geht, da kann WebAssembly NOCH nicht hinreichend Ersatz leisten. Als nächstes hatte ich dann Kotlin auf dem Schirm, weil aktuell die Hauptsprache für Android-Apps und weil die JVM halt immer noch ein gewichtiges Thema im Web-Backend-Bereich spielt. Und dann habe ich Rust auf der Roadmap, weil es für mich einfach DIE Sprache der Zukunft ist, wenn es um Ressourcen-sparende Lösungen geht. Ich denke, mal sie wird langfristig auch im Endanwenderbereich mehr eine Rolle spielen, wenn erstmal die ganzen Laufzeitumgebungen usw. alle mit Rust stabilisiert wurden und der Freiraum da ist, sich dann in den Frontend-Bereich zu gehen. WinUI, Qt, GTK dürften da entsprechend portiert werden...
Super Video!
Mein persönlicher Favorit: Kotlin. Kann ich sehr empfehlen!
Kotlin in Verbindung mit dem Spring Boot Framework - das ist eine sehr feine Kombination.
@@rolfspeer5403 Nutze gerne Ktor - weiß aber, dass Spring Boot auch sehr fein ist.
Ich bin aktuell dabei Rust zu lernen, da aktuell immer häufiger Tools in Rust geschrieben werden. Bisher ist sind das typsystem und borrow checker zwei tolle Eigenarten der Sprache.
Bibliotheken für Bluetooth-Vibratoren z.B. Lohnt sich allein schon dafür. 😂
Ich habe mich auch an Rust probiert, komme von Java, C++ und ein paar Frontend-Frameworks und... irgendwie habe ich enorme Probleme mit dem Borrowchecker, keine Ahnung warum.
Inspirierend!
Go find ich tatsächlich ganz spannend. Mal schauen was das Jahr so bringt :)
Professionell verwende ich hauptsächlich C#. Privat ebenfalls, und dazu noch das gute, alte C++. Aber ich habe mir in den letzten Monaten auch Rust und WebAssembly angesehen, vor längerer Zeit auch Go, und mit Lisp habe ich in meiner Jugend herumgespielt. Womit ich noch keine Erfahrung habe, ist Julia.
Wieder ein sehr interessantes Thema! 👌
Oft könnten Eure Videos nur ein paar Praxisbeispiele verbssern. Hier zim Beispiel: Quelltextauszpge und Ergebnisse zeigen, wäre super interesssnt gewesen.
Aktuell verwende ich Go in Verbindung mit dem Gin-Framework als Backend/REST-Service und React im Frontend-Bereich.
Spannend finde ich Rust. Allerdings denke ich, dass ich mit Go für die Webentwicklung besser aufgehoben bin. Mit Gin und Echo gibt es hier zwei etablierte Frameworks. Bei Rust ist das Feld noch etwas übersichtlich - soweit ich das beurteilen kann.
Anwendungsfälle in denen man jedes Byte noch mit seinem Vornamen ansprechen muss, habe ich kaum. :-)
Kleine Korrektur: GIN und Echo sind Libraries, nicht Frameworks :)
@@lokthar6314 Auf der Website von Gin wird es aber als Web Framework beworben. Ebenso bei Echo: High performance, extensible, minimalist Go web framework. Dann haben die das wohl falsch hingeschrieben. 🙂
Vielen Dank!
Hammer Content, wie gewohnt! Verkauft ihr jetzt auch Merch, oder wo kann man den Pulli erwerben :D?
[gr] Vielen Dank 😊
Ja, den Hoodie (und auch die T-Shirts) kann man bestellen - wenn Du Interesse hast, melde Dich einfach kurz per E-Mail bei uns, unter hello [at] thenativeweb [dot] io 😊
Was hältst Du denn von Dart / Flutter? Ist das eine glaubwürdige Alternative? Oder meinst Du (oder Dein Team), dass React Native eine bessere Basis (für Cross-Platform APP-Gedevelope) ist?
Kurze Frage: Was haltet Ihr von Dart?
Ich liebe Go
Ist ja auch eine sehr schöne und elegante Sprache 😊
Sprachlich und Runtime mäßig interessiert mich elixir sehr, mal gucken wann mal die Zeit da ist um sich tiefer damit zu beschäftigen 😅.
Mit Go werd ich nicht so richtig warm, allein schon, weil es eine "no-go" Formatierung vorschreibt. (Was für ein Wortspiel 😅)
Deine Ausführungen sind aber treffend. Mittlerweile zweifele ich sogar schon den Sinn von OOP an. Es wird ja immer die Kapselung gelobt. Im Endeffekt ist es aber nichts anderes als das Mißtrauen gegen sich selbst und den Rest des Teams. Ich fand es auch lange Zeit toll, alles private und protected zu deklarieren, wobei Vererbung - der ursprüngliche Sinn von OOP - mittlerweile ja auch schon verpönt ist, also gilt protected auch schon wieder als böse. Es werden häufig also lieber komplexe Strukturen entworfen, statt einfach zu vererben. Statt alles streng zu kapseln, kann man auch Namespaces verwenden und Namenskonventionen, die anzeigen, daß etwas nicht für den externen Zugriff angedacht ist. Manchmal macht es aber dennoch Sinn, direkt einzugreifen, statt einen riesigen Workaround zu schreiben und die Komplexität weiter zu erhöhen. Das muß ja nicht geschehen, wenn das Modul noch in der Entwicklung ist und Änderungen wahrscheinlich sind. Darüber hinaus gibt es dann noch den sealed Schutz. Solange das die Laufzeit maßgeblich verbessert, ist es ja nachvollziehbar, aber es wird für meinen Geschmack auch zu exzessiv eingesetzt.
Rust ist eine interessante Alternative, die ich mir bislang nur ganz kurz mal angesehen habe. Garbage-Collection ist sowieso nicht mein Ding. Ich behalte die Verantwortung für die Speicherbelegung lieber unter Kontrolle. So kann man auch Speicherbereiche unterschiedlich interpretieren, ohne Bitoperationen Hi/Lo Teile einzeln lesen/schreiben etc. Mir gefällt hardwarenahe Operation, das bedeutet einen maximalen Grad an Freiheit. C++ hatte ich mal gerne programmiert, aber mittlerweile werden mir da zu exzessiv Makros für jeden Furz eingesetzt.
Julia klingt sexy, kannte ich noch gar nicht. Ein kompilierter Pythonverschnitt wär mal was.
Ich finde es sehr angenehm, dass bei Go die Formatierung vorgegeben ist. Dort lässt sich auch nicht so viel machen, da das Ende der Zeile klarmachen muss, ob es in der nächsten Zeile weitergeht.
also bei LISP und Rust bin ich dabei :) - Julia denke ich nur wenn man schon Python kennt (sonst lieber das) ... bekommen wir jetzt vielleicht klassisches SICP ;P
Wer sich Richtung Typsystem (also z.B. Rust) interessiert, dem würde ich je nach dem woman her kommt Haskell (da bekommt man "fast" alles) oder gar eine dependent-typed Sprache wie Agda empfehlen.
Ansonsten denke ich sowohl LISP als auch RUST dürften die meisten Entwickler deutlich länger als ein Jahr beschäftigen - vor allem wenn man die "Ideen" wirklich verstehen will. Go geht vielleicht schneller (?)
WebAssembly lernen? Hmm IMHO nur wenn ich z.B. zu Sprachen contributen will, die das (zukünftig) als Target haben. Ansonsten IMHO ähnlich sinnvoll wie Assembler zu lernen - nicht verkehrt aber praktisch oft nicht sooo relevant.
Assembler ist nicht so furchtbar kompliziert. Und da ja heute sehr viel über Systemaufrufe und Bibliotheken passiert, spielt die Sprache ansich im Endeffekt auch nicht mehr so die große Rolle - nur eben die Standardbibliothek, die eine Hochsprache von Hause aus mitbringt. Da hat Assembler halt keinen "built-in". An ASM weiß ich aber zu schätzen, daß man viel mehr Strukturen entwerfen kann als die klassischen Standardkonstrukte der Hochsprachen, und auf Bitebene arbeiten ebenso.
Will man nur für berufliche Zwecke eine Sprache lernen, ist ASM natürlich nur mehr eine Nische für embedded systems und ansonsten kaum gefragt.
@@pinkeHelga Ich weiß - ich glaube meine ersten Assembler-Programme habe ich vor 30 Jahren geschrieben ;) - aber gebraucht hab ich das abgesehen von Spielereien, ein paar Jahren für Systemaufrufe in MSVC++ und die letzten 20 Jahre vielleicht noch für ein paar Advent-of-Code Aufgaben nie mehr ;)
Wie ist dein setup? Pc, Monitor, Tastatur und Mikro
[gr] Guck mal hier:
- Hardware-Setup: ruclips.net/video/HdwBYeGHAdY/видео.html
- Software-Setup: ruclips.net/video/EwdI-TZAL64/видео.html
@@thenativeweb Danke :)
Sehr gut du kommentiert, ich glaube, die ganzen Programmiersprachen sind nichts für mich. Ich muss wohl mehrere Jahre warten, bis eine Programmiersprache herauskommt, das besser zu mir passt. Mal sehen, ich schaue mir Lisp mal an, aber ich glaube, dass ich damit auch nicht klarkomme.
Ich hab einige Sprachen in den letzten 10 Jahren durch gemacht: Java, Kotlin, Dart, Python, TS / JS. Mittlerweile mache ich nur noch Go und Python
Bisher C# (meist BE mit ASP)
und TS (meist FE mit Svelte).
Besonders spannend find ich GO, Rust und Julia
Ich würde mich auch gerne mal mit C beschäftigen, aber nur aus Neugier.
C ist auch gar nicht mal schlecht. Im Prinzip läßt sich auch alles damit machen, und das quasi auf jedem System, vor allem auch enbedded systems. Ist halt back to the roots ins prozedurale Zeitalter, was auch nicht verkehrt ist . Ich bekomme nach Jahrzehnten OOP allmählich Zweifel, ob das nicht in eine falsche Richtung geführt hat. Oft erlebe ich Overengineering.
Etwas gewöhnungsbedürftig ist, wenn man Sprachen auf höherem Level gewohnt ist, daß es keine Strings kennt. Man arbeitet mit Zeigern direkt auf Speicherbereichen und hat keinen Schutz, daß man über reservierte Speichergrenzen hinaus schreibt. Dafür ist man selbst verantwortlich. C++ hat dagegen eine CString Klasse.
"NSA Releases Guidance on How to Protect Against Software Memory Safety Issues" ist ein lesenswertes Dokument.
Lange Zeit galt C noch als Sprache, die man für den Linux-Kernel benötigt, aber es sieht nun doch so aus, als würde das schrittweise durch Rust ersetzt werden. Im Prinzip hat die NSA sich hierin deutlich gegen C/C++ ausgesprochen: "NSA advises organizations to consider making a strategic shift from
programming languages that provide little or no inherent memory protection, such as
C/C++, to a memory safe language when possible."
@@pinkeHelga Das mit der OOP kann ich gut nachvollziehen. C# versucht hier mit weiteren Features häufige Muster etwas zu kürzen, aber ich persönlich verwende dann doch sehr häufig bewusst die umständlichere Schreibweise. Die etwas direktere Art und Weise von Go gefällt mir auf dem ersten Blick sehr gut.
C++ wirkt in der Hinsicht eher abschrecken auf mich. Hab kürzlich ein Video gesehen in der eine kurze Funktion mit einer Schleife und 2 Ifs mittels ranges::accumulate, rv::iota und rv::filter "verbessert" wurde.
Man hätte mit einer weitere Funktion und einem early return eine völlig unmissverständliche Lösung bauen können. Das was da rauskam war ein rech fremdes konstrukt. In Go baue ich darauf, dass sowas eben nicht entsteht.
@@pinkeHelga Overengineering - ein wahres Wort. Habe gerade zwei Anwendungen mit Go und dem Gin-Framework am Start, nachdem ich vorher längere Zeit mit Spring Boot und Java gearbeitet habe. Go und Gin, einfach super-pragmatisch und unglaublich schnelle Startzeiten. Cross-compiling finde ich auch eine tolle Sache - unter Windows für Linux kompilieren.
Die Fehlerbehandlung in Go ist fehleranfällig, da man Fehler ganz einfach ignorieren kann. Was das mit guten Sprachdesign zu tun hat, ist mir ein Rätsel.
Meine Vorhersagen:
- Go
- Rust
- TypeScript
- Python
- Zig
[gr] Mit Go und Rust hattest Du Recht 😉
@@thenativeweb Hä ok dann bin ich gespannt was die anderen drei sind
5 Sprachen in einem Jahr ist ein bisschen hoch gegriffen meiner Ansicht nach.
Grundsätzlich ist es ziemlich utopisch zu behaupten man könne 5 Sprachen und ist auch bei allen up to date, kennt die gängigen Framesworks etc. Eine Sprache zu können erfordert mMn. etwas mehr als "ich kenne die Syntax und kann sie lesen und schreiben". Vorausgesetzt man zählt "sich sehr ähnliche Sprachen" nicht einzeln.
Ja. Ich bin jetzt auch nicht professionell tätig und für eine einzige Sprache (was ja durchaus evtl. sinnvoll wäre) kann ich mich definitiv nicht entscheiden. Das hatte ich schon versucht. Also schaue ich mal wie weit ich komme mit den 2.5, die ich jetzt festgelegt habe. JavaScript habe ich übrigens rausgeschmissen, weil ich da einiges zu gesehen hatte und das hat mir einfach nicht gefallen, sowohl vom Tempo der Vortragenden, als auch von der allgemeinen Attitüde, die ich da so mitgenommen hatte. Wahrscheinlich können viele von Euch schon JavaScript, aber ich werde dann sehen, ob ich drum herum komme...
@@claus7555 Javascript musst du auch nicht können, wenn du nichts im Browser machen möchtest 👌🏻
@@claus7555 Hab ich das richtig verstanden: Du machst es also vom "Tempo der Vortragenden" und deren "Attitüde" abhängig, ob du eine Programmiersprache lernst?
@@miedsekadse7136 Nicht nur, aber auch.
Viel probiert, aber seit über 20 Jahren nur noch Java, Sql und JavaScript.
Scala, Kotlin, Python, Typescript nur unter Zwang 😉
Die Verbindung zwischen OOP + FP mit Scala finde ich weiterhin genial. Leider lässt das Ökosystem etwas zu wünschen übrig - die IDE-Überstützung war lang nicht optimal. Das Build-Toll sbt ist auch nur so mittelprächtig.
Ich warte noch immer darauf, dass mir ein realer use case über den Weg läuft, den ich mit TypeScript / JavaScript nicht zur Zufriedenheit umsetzen kann.
In meinem beruflichen Umfeld geht es zu 100% um Web- und Cloud Entwicklung. Vue, Nuxt. Backend ist de facto immer in AWS, ob nun „klassisch“ Serverless mit API GW, Lambda, SNS, SQS, EventBridge und Co oder als Container in ECS on Fargate. Wenn es eine HTTP API benötigt und API GW nicht das Mittel der Wahl ist, wird es ein Fastify Backend oder eben direkt Nuxt.
Ich habe noch keinen Fall gesehen wo ich gesagt hätte „jetzt bräuchte ich hierfür Go oder Rust“.
Scheme statt Lisp wäre vielleicht auch eine Überlegung, da es vielleicht mehr praktische Verwendung dafür gibt.
Und was ist mit C++?
EDIT: Die Frage war ein Scherz. Ich habe täglich mit C++ zu tun und die Sprache und die Toolchains sind einfach nur PITA.
Ich finde es enttäuschend wenn Programmiersprachen etablierte Begriffe neu belegen. Wie Rust, "match" für "switch case" verwendet, wobei "match" bei allen normalen Leuten fest mit pattern matching verbunden ist. Kann man natürlich argumentieren, "Ja aber darum geht es ja beim neue Sprachen lernen. Es soll weh tun im Kopf. Das ist Lernen." Ne, für mich ist es zeichen für schelchtes Sprachdesign. Auch wenn ich selbst noch nie eine Sprache selbst entwickelt habe, kann ich es als Sprachanwender behaupten.
Warum dann nicht Ruby, oder Netlogo? Netlogo - total coole Sprache die funktionen mit "to" deklariert. Mega genial. Funktion soll ein Verb sein, und um die zu deklarieren schreibt man "to" und dann hat man bspw. "to start()" und dann den Körper, und dann "end". Sehr zugänglich.
to? Interessanter Ansatz nach function (JavaScript), func (Go), fun (Kotlin) und fn (Rust).
Ich glaube hier wurde das match in Rust noch nicht ganz verstanden.
Man kann das zwar für "switch case"s nutzen, aber das Konzept ist viel größer als das. So kann ich zum Beispiel matchen ob ein dreiteiliges Tupel als erstes ein Ok mit irgendeinem Inhalt, als zweites eine Zahl zwischen 1 und 10 und als drittes einen beliebigen Wert hat. Und solche Konstrukte sind nur der Anfang. Rust bietet mit Match ein sehr ausgiebiges pattern matching, weshalb der name "match" doch recht passend ist.
Ich schaue RUclips auf unterschiedlichen Endgeräten und Clients: hauptsächlich im Browser (Chrome) auf meinem Macbook, auf meinem iPhone und auf meinem LG webOS TV. Auf keinem dieser Endgeräte sehe ich die ominösen Infocards.
Was mache ich falsch?
PS: wie immer super Content!
Das kleine (i) ist die Infocard
Ich glaube die Zeit für 5 Sprachen habe ich nicht. Wenn dann wird es Go und das lieber zu 100% als 5 Sprachen zu 20%.
Schöne Woche!
Wieso nicht auch mal: Tcl (Lisp-like, multiparadigmatisch, homoikonisch); C++2x. Aktuell verwende ich diese Sprachen...
Ich rechne damit, dass Go und JavaScript dabei sind.
[gr] Go ja, JavaScript nein 😉
Java Script ist sicherlich etwas zu common um explizit erwähnt zu werden.. früher oder später kommt man ja ohnehin nicht daran vorbei 😉
@@YaXTuber Ich dachte daran, dass es auch in 2023 noch Leute gibt, die man dazu auffordern muss, Vorbehalte gegen JavaScript abzulegen. Und damit - richtig -anzufangen.
@ die Vorbehalte hab ich zum Teil auch noch.. das liegt in erster Linie daran, dass ich Ordnung mag. Java Script kann man auch ordentlich schreiben, aber das heißt letztlich nicht, dass dies auch gemacht wird. Manchmal ist es besser, weniger Freiheitsgrade und klare definierte Grenzen zu haben 😉 ... und ein TypSystem .. 🤐
@@YaXTuber Ich dachte das auch viele Jahre (Jahrzehnte). Allein um festzustellen, dass ein Typ-System auch nicht von schlechtem Code abhält. Und wer wirklich ordentlich arbeitet, schenkt sogar PHP lyrische Qualitäten 🙂
Python
Gute Tipps, aber 2023 passt hier doch nicht? Die nächsten Jahre würde doch eher stimmen? Ist doch alles in 2024 noch genauso relevant...