Warum gerade Go? Darum! Wie wir unsere Entscheidung begründen // deutsch

[@kobi-kobsen]

Was ein geiler Typ du bist. Perfekte Tiefe/Komplexität, klare Sprache, super Tempo,... Vielen Dank für dieses und alle deine Videos.

[@thenativeweb]

[gr] Vielen lieben Dank 😊

[@yahmk3978]

Vielen Dank für diese detailierte Wiedergabe Eurer Entscheidungsfindung.

[@thenativeweb]

[gr] Gern geschehen 😊

[@hansvetter8653]

Toller informativer Vortrag! Ich stimme Ihnen in allem zu. Danke!

[@floriango5705]

Es ist wirklich super, dass du euren Entscheidungsprozess hier so detailiert beschreibst und das ihr eure langjährige Erfahrung mit den bisher eingesetzten Technologiestack mit uns teilt. Eure Entscheidung finde ich wirklich nachvollziehbar und es hat mich auch dazu bewogen, mich eingehender mit der Sprache Go zu beschäftigen. Danke!

[@thenativeweb]

[gr] Vielen Dank - das freut mich 😊

[@wernervienna]

wunderbar packende und interessante 30 Minuten! Einfach schön hergeleitet mit schlüssigen Begründungen - so geht das! Wo andere einfach sagen "wir machen alles mit Java, weil Java ist halt Java" wird hier sauber argumentiert. Und als passionierter Go Developer kann ich deiner Entscheidung natürlich nicht widersprechen :-)

[@snapstromegon]

Insgesamt ein sehr interessantes Video, doch ich möchte einmal meine Meinung zu euren drei Punkten zu Rust geben (damit möchte ich nicht sagen, dass Rust die richtige Wahl für euch gewesen wäre, aber eventuell ist das Licht der Betrachtung doch etwas verschoben): 1. 26:55 Systemnähe: Ja, Rust ist recht systemnah und erlaubt es einem zum Beispiel auch Kernelmodule für Linux, Firmware für Microcontroller oder andere Systemnahe Software zu schreiben. Auf der anderen Seite erlaubt gerade die vorhandene Cratevielfalt zusammen mit dem Sprachdesign sehr einfach (wenn auch nicht ganz Codezeilenarm) z.B. Microservices umzusetzen. Ich habe zum Beispiel gerade die Tage einen Service für die Tankerkönig API geschrieben, der die Daten für Prometheus bereitstellt. Allein die Möglichkeit die Configuration entweder über CLI Parameter oder Umgebungsvariablen setzen zu können und direkt in einer statisch typisierten Struktur zu haben ist in der Developer Experience mMn schon sehr viel wert. Ich sehe es also eher als eine Sprache, die gut für Anwendungen nutzbar ist, mit der man aber auf die tieferen Ebenen abtauchen kann, wenn man möchte. 2. 27:07 Rust ist schwer: Auch hier ist der Kern nicht falsch. Gerade dadurch, dass Rust einige Konzepte einführt, die andere Sprachen nicht haben (Borrow Checking, der Strikte Compiler, Traits, ...), muss man erstmal reinkommen. Hierbei helfen allerdings zwei Dinge sehr: Erstens: Die Dokumentation der Sprache, die ich so gut noch so gut wie nirgendwo anders gesehen habe (allein dass Crates keine veralteten Beispiele in der Dokumentation haben können, da diese nicht kompilieren würde, ist großartig) wie z. B. das Rust Book und Zweitens: Zum Einstieg in existierende Projekte gucken. Rust macht es sehr schwierig Dinge kaputt zu machen und gleichzeitig erlauben existierende Projekte "sich etwas abzugucken", wodurch man leichter in die Sprache rein kommt. Insgesamt ist es also richtig, dass Rust nicht "leicht" ist, aber wie schon im Video erwähnt, halte ich das für kein starkes Argument und persönlich zudem stark für den "vorher" Blick (soll heißen Rust wirkt schwerer als es ist). 3. 27:30 Verbreitung von und Vertrauen in Rust Ich nehme jetzt mal den JetBrains Dev Ecosystem Report von 2021 als Grundlage für die folgenden Aussagen (www.jetbrains.com/lp/devecosystem-2021/rust/): Rust ist tatsächlich (gerade im professionellen Umfeld und größeren Projekten) noch nicht allzu sehr verbreitet. Jedoch scheint ihr nach dem Report eigentlich genau in einen Bereich zu fallen, der recht einfach zu Rust übergehen könnte. Ihr kommt von JS/TS, arbeitet in VS Code, erstellt Web Services, die übers Netzwerk kommunizieren und als Target habt ihr normal Unix Systeme oder in Zukunft eventuell WASM (was Rust meiner Meinung nach am besten von allen Sprachen macht). Gleichzeitig seid ihr eher erfahrene Entwickler und tragt den Open Source Gedanken mit euch. In dem Video wurde allerdings auch das "Mozilla-Problem" angesprochen. Ich persönlich halte Mozilla in Rust nur noch für eine Organisation von vielen. Den Einfluss, den Mozilla zu Beginn mal hatte, hat es schon lange nicht mehr und selbst wenn Mozilla heute Rust komplett fallen lassen würde, glaube ich nicht, dass das einen merklichen Einfluss auf die Sprache hätte. Inzwischen haben viel mehr Organisationen ein tiefes Commitment in Rust (AWS, Google, Microsoft, Facebook, WASM Community Group, ...). Ich persönlich finde, dass Rust aktuell also eine stark wachsende Verbreitung mit einem sehr stabilen Standfuß hat. Ich will euch also nicht zwingend in eurer Einschätzung widersprechen, sehe aber dennoch einige Dinge einfach anders als ihr im Bezug auf Rust. Dennoch bin ich gespannt, was ihr in Zukunft so an Go Content produzieren werdet.

[@domemvs]

Rust erinnert mit den Crates stark an das NPM Ökosystem. In Go gibt es zwar auch viel als externe Module, aber eines der gewichtigsten Argumente für Go ist dir stdlib. Da kann Rust einfach nicht mithalten und Golo will ja externe Deps reduzieren.

[@TheEde1998]

@@domemvs das sind halt unterschiedliche Philosophien. Rust hält seine stdlib absichtlich klein. Stattdessen sollen normale crates verwendet werden, die wesentlich flexibler sind bzgl. Änderungen. Die stdlib hat halt in extreme Stabilitätsgarantien, die auf Dauer ziemlich zur Last werden. Es gibt nicht umsonst bei Python den Spruch "The standard library is where code goes to die.". Auch in C++ gibt es z.B. das regex Modul, von dessen Verwendung abgeraten wird. Man kann es aber nicht einfach entfernen wegen der Stabilitätsgarantien der stdlib.

[@X39]

Rust hat eigentlich gar keine Konzepte die so komplex zu verstehen sind... Es ist eher so, dass die Syntax von rust aus der Hölle kommt. Wer meint das c++ verbos sei, hat noch nie rust geschrieben... Verstehe mich nicht falsch, ich versuch mich Bswp immer wieder mal rein zu Fuchsen... Aber diesee Syntax gebilde ist einfach nur mist

[@snapstromegon]

@@X39 Ich würde Rust weniger als verbose, sondern eher als explizit beschreiben. Und wenn ich mir so meine Rust Projekte ansehe, dann ist das, was an "mehrcode" da steht, meist den "fehlenden" optionalen parametern geschuldet. Abseits davon finde ich die Syntax (wenn man die Sprache und das Traitsystem richtig nutzt) sogar recht übersichtlich (es hat sich aber auch in den letzten Rust Versionen viel verbessert). Natürlich ist Rust kein go oder python in der Syntax, aber deshalb sage ich auch, dass man am besten mit einem existierenden Projekt in die Sprache rein kommt.

[@X39]

@@snapstromegon Ich bin kein Freund von Go oder Python, Syntax technisch. Aber Rust fühlt sich von der Syntax an wie ein als bison gestarteter versuch einer Sprache der dann plötzlich festgestellt hat "Scheiße Bernd, wir brauchen ja auch noch ne Programmiersprache dazwischen" mit teils Obskursten Entscheidungen für Syntax Elemente Und ob ich jetzt verbos oder explizit sage ist dabei ziemlich wumpe ... Was mir persönlich allerdings am meisten aufstößt sind die Funktionen ... Statt Parameterüberladung gibt es da Strukturen die man mit Obskurika "default" befüllen lassen kann. Mal ist es aber auch nötig, dass bestimmte felder immer im gleichklang gesetzt werden (weil es sich um eine fake-überladung handelt) was dann aber nicht sauber über den code kommuniziert werden kann. Insgesamt sind sehr viele Entscheidungen Richtig getroffen worden in rust ... nur um es dann an den unnötigsten stellen wieder zu verballern (womit es halt das typische Mozilla Projekt ist)

[@groovebird812]

Richtig cooles Video. Du weißt so viel und erklärst alles gut und nachvollziehbar. Das trifft aber nicht nur auf dieses Video zu.

[@thenativeweb]

[gr] Vielen, vielen Dank 😊

[@m.j.7492]

Super interessant, werde dank dir mehr auf GO aufspringen, Rust nur noch für IOT. Und natürlich weiterhin Python für die kleinen Helfer-Bots. Alles nebenberuflich in die Zukunft. Danke dafür, sehr professionell. ✊

[@thenativeweb]

[gr] Danke schön 😊

[@W00PIE]

Ich setze Go im industriellen Bahnumfeld seit ein paar Jahren für lastintensive serverseitige "24/7 Datenschaufeln" ein und kann sagen, dass ich selten so unkompliziert entwickelt habe. Die Sprachkonzepte sind super, dazu kommt das unfassbar einfache Crosscompiling und das ausgewachsene Ökosystem, das gerade im Netzwerk- und Datenbankbereich alles zu bieten hat, was man sich nur wünschen kann. Keine riesige Toolchain, keine nervigen Abhängigkeiten, es läuft einfach schnell und sicher und stabil.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊 Ich denke, das Wort "unkompliziert" trifft es schon ziemlich gut.

[@marcelkoch_net]

Ich denke auch, dass Go die richtige Wahl ist. Die Herleitungen wirken auf mich jedoch etwas, wie soll ich sagen, nachträglich hinzu gebaut. Danke jedoch für das Video. Es ist im großen und ganzen ein gelungenes Video geworden, mit einem guten Überblick an Sprachen und zeigt besonders Deine Qualität, frei zu sprechen. Danke!

[@thenativeweb]

[gr] Danke schön 😊

[@knofi7052]

Also, ich bin ja richtig begeistert von Julia und glaube, dass der Sprache noch eine große Zukunft bevorsteht und vermutlich sogar Python ablösen kann. Für euch und eure Anforderungen ist aber vermutlich Go die tatsächlich beste Lösung und deshalb in meinen Augen eine sehr gute Entscheidung.😊

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊 Und ja, Julia finde ich auch sehr spannend - auch wenn mir dafür die Anwendungsfälle im größeren Stil fehlen. Aber interessant ist die Sprache auf jeden Fall.

[@andreashurling6995]

Moin. Danke für den interessanten Einblick. Die Begründung für Go ist nachvollziehbar.

[@thenativeweb]

[gr] Danke 😊

[@flor6741]

Aufschlussreich und unterhaltsam, danke dafür!

[@yt7042]

Danke für das Video und deinen sehr informativen Spaziergang durch das aktuelle Sprachlabyrinth. Deno hatte ich bis jetzt noch gar nicht auf dem Schirm, obwohl es über 80k stars auf Github hat. Es scheint auch sehr aktiv weiterentwickelt zu werden, so dass man doch gespannt sein darf ob es da irgendwann einen Durchbruch aus der bisherigen Bedeutungslosigkeit geben wird. Ich denke mal Go war die richtige Entscheidung und ich freue mich schon auf deine Go Videos. Schöne Woche!

[@thenativeweb]

[gr] Danke für Dein Feedback 😊

[@stevenkleist9111]

Danke für das Video, viele von den genannten Sprache habe ich mir ebenfalls angesehen. Ich kam, wenn auch von einem anderen Standpunkt aus, auf ähnliche Ergebnisse. Ich freue mich aber sehr das ich fast immer die Pubkte finde, die ihr auch erwähnt, wirklich eine angenehme Bestätigung. Einziger Wermutstropfen: meine Lieblingssprache hat gleich als erstes eine Schelle bekommen 😀

[@thenativeweb]

[gr] Danke schön 😊 Und ich hab' ja nicht gesagt, dass Python schlecht wäre - es hat nur nicht zu unseren Anforderungen gepasst … insofern, nicht traurig sein 😊

[@MarkusEicher70]

Eine wirklich gelungene und wertvolle Ausführung über Euren Auswahlprozess. Ich finde das unheimlich hilfreich. Ich weiss, man kann meine Begeisterung für Eure Inhalte für elonsches Fanboytum halten, aber ich finde die Beschreibung dieses Verfahrens äusserst einleuchtend und nachvollziehbar. Sicherlich werden verschiedene Leute das anders sehen und es kann auch sein, dass einzelne Sprachen und Umgebungen nicht in jedem Detail von Euch berücksichtigt wurden. Ich finde, dass jeder mit der Umgebung arbeiten soll, die seinen Neigungen und Anforderungen entspricht und zu den gewünschten Ergebnissen führt. Für mich war dies die noch fehlende Bestätigung, mich eingehend mit GO zu beschäftigen. Ich geh jetzt gleich daran, Eure 130-minütige Einführung durchzuarbeiten und dann muss ich mir zwei Projekte ausdenken, um das Gelernte gleich anzuwenden. Ich brauche heutzutage etwas länger, um neuen Stoff in meinen alten Schädel zu kriegen, bin aber begeistert damit loszulegen. Vielen Dank nochmals und happy coding! 🤛

[@geeksy2278]

Ich finde es erstaunlich wie schnell ich mich schon nach kurzer Zeit in Go-Projekte einarbeiten kann. Wir nutzen für diverse Backups das Tool "restic" und ich konnte mich sehr fix in das Repository einlesen. Das habe ich vorher eher selten gemacht. Go ist einfach und toll, vor allem wenn man den pragmatischen Ansatz der Sprache übernimmt.

[@thenativeweb]

[gr] Ja, da stimme ich Dir im Großen und Ganzen zu. Es gibt ein paar Sachen, die ein bisschen gewöhnungsbedürftig sind, oder dann doch nicht ganz so sauber gelöst sind, aber das ist von der Anzahl her bislang doch alles recht überschaubar.

[@siriusmarz512]

An das ganze Team Frohe Ostern

[@thenativeweb]

[gr] Danke schön - das wünschen wir Dir auch 😊

[@oliverandrich7778]

Ich hätte das genauso entschieden wie ihr. Genauer gesagt habe das auch für mich so getan. Go als Sprache für Webanwendungen macht so viel Sinn und ich glaube, ich hatte noch in keiner Sprache so wenige externe Abhängigkeit, um eine komplette Webanwendung zu bauen. Da ich für ein Projekt auch noch auf HTMX setze, entfällt auch der JavaScript-Zirkus fürs Frontend.

[@thenativeweb]

[gr] Danke für Dein Feedback 😊

[@ikemkrueger]

HTMX sieht spannend aus. Danke für den Tipp!

[@Lyrik-Klinge]

Ein super Überblick, DANKE!

[@thenativeweb]

[gr] Danke, das freut mich 😊

[@benny8063]

Sehr gutes Video! Go habe ich schon lange auf dem Schirm. Finde die Entscheidung gerecht fertigt.

[@thenativeweb]

[gr] Danke schön 😊

[@wolfsluytermanvanlangeweyd6741]

Toller Vortrag wieder 👍

[@thenativeweb]

[gr] Danke schön 😊

[@mag8101]

was ein hammer geiles Video. Vielen Dank Golo

[@thenativeweb]

[gr] Vielen lieben Dank 😊

[@markusmaiwald8134]

Wau, klasse Erklärung, tolles Video.

[@callmejoe5209]

Wir hatten eine ähnliche Diskussion - aber nur intern. Wir haben uns dann für C# .Net Core entschieden. Weil wir eben Binaries für alle Plattformen entwickeln können. Ja, MS ist ein Problem. Ist Google aber auch. Für uns war es wichtig, dass die Lernkurve für alle die aus dem Bereich C++/Java kommen nicht so hoch ist. Aber ich nehme das hier mal zum Anlass Go sich mal anzuschauen. Danke für das Video!

[@thenativeweb]

[gr] Danke für das Lob und den Kommentar 😊 .NET Core sieht (inzwischen) tatsächlich auch durchaus (wieder) spannend aus - nur braucht man hier eben (im Normalfall) wieder eine gesonderte Laufzeitumgebung, die man installieren muss. Wenn man davon mal absieht und sich mit Microsoft anfreunden kann, ist das aber sicherlich auch eine gute Wahl 😊

[@mathiszeiher]

Hi, super Zusammenfassung, der Vorteil von Go ist meiner Meinung auch die doch recht grosse Standardbibliothek. Bei rust ist man sehr schnell auf 3rd party crates angewiesen, (z.b. rust-crypto, wobei die super gemaintained ist), oder eben tokio als async runtime. Das schoene, vor allem in grossen Teams ist auch, dass Go ziemlich opinionated ist, gibt kein bike-shedding ueber style oder patterns, gibt normalerweise nur einen "Go way". Rust ist wenn man von C/Cpp kommt tatsachlich eine Offenbarung, vor allem im no_std land ;) Bezueglich single binaries (auch static linked) ist .net 6.0 auch recht interessant, da kann man auch single executables erzeugen, mit .net 7 sollen die wohl noch effizienter und kleiner werden.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@koder7738]

Ich fand das Video interessant. Ich habe mich auch schon mit Rust und Go befasst. Ich finde Rust ist schwieriger zu lernen. Aber der Compiler ist gut, was die Fehlermeldungen angeht! Ich habe eine eigene VM entwickelt: L1VM. Meine Programmiersprache Brackets ist typsicher, hat Multithreading und ist recht einfach zu lernen. Die VM kann Array- und Stringüberlaufe erkennen. Die VM kann mit Modulen einfach erweitert werden. Man kann mit dem SDL Modul Grafik und GUIs erstellen.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@aptfx]

Ein paar (nitpicking) Hinweise: 1) Obfuscating vs. Compiling Das ist grundsätzlich natürlich korrekt, allerdings können auch nativ (oder Bytecode)-compilierte Programme oft erstaunlich gut decompiliert werden. 2) Laufzeitumgebung Nahezu jedes Programm verwendet eine Laufzeitumgebung selbst C. Unter Linux ist die durch die glibc gegeben und hat da ja auch immer mal wieder nach ABI-Änderungen für Probleme gesorgt. Es gibt natürlich bei Go (und Rust) die Möglichkeit ein Binary zu erzeugen, dass nicht an die Laufzeitbibliothek dynamisch gebunden ist - aber auch das hat natürlich eigene Nachteile. Der Unterschied der für eure Entscheidung eher relevant ist, ist eher eine "schwergewichtige Runtime". 3) npm Ist ein Opfer seines Erfolgs. Ich kann die Argumentation nachvollziehen. 4) Swift Ist ja eigentlich das ursprüngliche "Pet-Project" von Chris Lattner (LLVM). Es ist eine erstaunlich gute Sprache mit Ähnlichkeiten zu Rust, aber in vielerlei Hinsicht einfacher bzw. mehr Highlevel. Du hast natürlich Recht, dass der Zweck der Sprache hauptsächlich das Apple-Ökosystem ist - ich finde es aber ein wenig unfair die Sprache von vorneherein darauf zu reduzieren. Es gibt z.B. durchaus auch den Anwendungsfall "Backend" dafür. Der Hintergrund dazu ist, dass natürlich auch Apple sein Cloud-Geschäft stark weiterentwickelt und die neue "Hauptsprache" dafür ebenso geeignet sein soll. Es gibt demnach einen recht gut gepflegten Linux-Port und einen so langsam besser werdenden Windows-Port. Die Sprache ist OpenSource. Es ist tatsächlich ein wenig Schade, dass die Sprache im Web-OpenSource-Umfeld noch nicht weiter Fuß gefasst hat, denn viele Eigenschaften davon wären erstaunlich gut. 5) Lisp Ich kann das was Du sagst zu 100% nachvollziehen. Ich habe viele Jahre Projekte in Common Lisp entwickelt (fast ausschließlich Webprojekte). Ich habe z.B. mit "Portable Allegroserve" den Webserver von Franz Inc. portiert. Mit "mel-base" eine der umfangreichsten (POP3, IMAP, Maildir...) Mailbibliotheken für Common Lisp entwickelt usw. Letztlich bin ich für Webentwicklung aber dennoch mehr in Richtung JavaScript und später Typescript gedriftet - spätestens mit dem Erfolg von Node.js. Dennoch blicke ich immer noch mit Wohlwollen auf meine Lisp-basierten Dienste, die ich nichtmal beenden musste um neuen (compilierten!) Code zu laden. 6) Rust Hier kann ich Deiner Argumentation tatsächlich nicht folgen. Die Bindung an Mozilla wurde von vielen eher kritisch gesehen. Deshalb gab es ja auch die Entwicklung zu einer Governance. Rust wird z.B. auch bei Microsoft wachsend eingesetzt. Was die Systemnähe angeht - das ist zwar durchaus korrekt, aber die Sprache erlaubt durchaus unterschiedlich "feingranular" zu entwickeln. Ich habe mir Rust nachdem ein Kollege mich jahrelang immer mal wieder drauf aufmerksam gemacht hat irgendwann doch mal skeptisch angeschaut und war tatsächlich ziemlich schnell begeistert. Ich bin ja schon ein wenig ein Language-Nerd und habe mir in den letzten 20 Jahren ständig neue Sprachen angeschaut. Aber: Rust war die erste Sprache seit Common Lisp (vor über 20 Jahren) die mich wirklich vom Hocker gehauen hat. Es ist eine Sprache die sowohl Highlevel-Code ermöglicht (wie Common Lisp) als auch extrem nah auf Maschinenebene (wie Common Lisp). Die Syntax ist erweiterbar (wie Common Lisp). Der vermutlich kniffligste Teil am Anfang ist die ungewöhnliche Speicherverwaltung. Ein Rust-Blogger hat das mal als "statische Garbage Collection" beschrieben - und das kommt der Idee tatsächlich ziemlich nah. Man kann in Rust eigentlich in etwa so entwickeln, als ob es eine Garbage Collection gäbe - nur gibt es eben keinen in der Runtime. Stattdessen verfolgt der Compiler bereits die Laufzeit der Objekte und gibt sie exakt dann frei, wenn sie nicht mehr benötigt werden. Wer jetzt denkt, dass wäre doch genauso wie bei Reference-Counting - nein auch das wäre ein Laufzeitfeature. Dennoch gibt es auch die Möglichkeit reference counted Referenzen zu verwenden - was manche Dinge im Code vereinfachen kann. Dann eben mit dem zu zahlenden Laufzeit-Impact. By default alloziert Rust auf dem Stack und verwendet Value-Types. So kann man tatsächlich hocheffizienten Code schreiben - allerdings ist Laufzeitflexibilität dann eben schwieriger. Man kann jedoch auch leicht Dinge auf dem Heap allozieren und gewinnt so an Laufzeitflexibilität. Diese unterschiedlichen Code-Organisations und Entwicklungsstile sind bei Rust eben in einer Sprache möglich - je nachdem was man braucht und eben auch gemischt. Hinzu kommt, dass der Rust-Compiler so ziemlich die besten und zielführendsten Meldungen ausgibt, die ich bislang überhaupt bei einem Compiler gesehen habe. Es macht einfach Spaß die Sprache zu verwenden. Ist Rust schwierig? Ich finde nicht, dass Rust wirklich schwierig ist. Die größte initiale Hürde ist der Borrow-Checker. Aber ein Tutorial dazu reicht aus um dieses eben ungewohnte Feature schnell zu lernen. Hier nochmal ein kleiner Seitenhieb nach Swift: Die Sprache ist ja auch in dieser Hinsicht etwas ähnlich, aber leichter zugänglich. Man kann wirklich hoffen, dass Swift von seinem "Apple-Image" loskommt und breitere Verwendung findet. Grundsätzlich möchte ich aber nochmal erwähnen, dass ich Deine ungewohnt stark negative Darstellung von Rust etwas enttäuschend fand. Das ist ein verdammt cooles Projekt, das definitiv nicht nur "systemnahe" Entwicklung erlaubt und definitiv eine der momentan spannendsten "Websprachen" ist. Ich kann das natürlich nur vermuten, aber was viele vielleicht etwas übersehen ist schlicht, dass ihr ja durch Videos, Vorträge, Kurse und Beratung andere Anforderungen habt als irgendein Team, dass "lediglich" ein Projekt umsetzen will. Es spricht tatsächlich nicht unbedingt etwas dagegen ein Projekt z.B. in Common Lisp umzusetzen wenn man damit firm ist. Es ist jedoch völlig klar, dass dafür kein Markt für Beratung & Co. existiert. Deshalb auch - für mich Nachvollziehbar - die Entscheidung für Go statt für Rust. Ich hoffe Du nimmst es mir nicht übel, wenn ich das "unterstelle": Go ist eben aktuell die gehyptere Sprache. Wenn man also nicht auf den .NET-Hype oder Java-Trott im Businessumfeld aufspringen möchte, dann ist Go aktuell vermutlich wirklich der zweitbeste Markt.

[@marinaegner]

Wow, sehr detaillierte Überlegungen! 😮 Danke, für die tolle Aufschlüsselung! Was in Vergangenheit mit so manchem NPM Modul passiert ist, hat mich auch etwas beunruhigt. Wie ich finde sehr erschreckend und alles andere als zielführend. Ich finde die Schlussfolgerung und Aufgabenstellung sehr nachvollziehbar. Gute Wahl! 👍 Ich denke ich wäre, ohne jetzt jede Sprache gut zu kennen, zu einem sehr ähnlichen Ergebnis gekommen. Einige Sprachen sind einfach von derren eigenen Fokus nicht geeignet für solch ein Zweck, wenngleich sicher alles möglich ist, nur halt zu einem anderen Preis. Wiederum manche Sprachen sind sehr komplex und schwergewichtig. Ich finde zum Beispiel auch, Java alles andere als eine attraktive Sprache, um damit zu arbeiten. Ich sehe das sehr ähnlich! Ich denke auch für mich wird es in Zukunft noch interessant bzw. relevant werden, mich mit Go zu beschäftigen. Ich bin sehr gespannt, was sich hier zu Go noch alles kommt! 😊 Wer weiß vielleicht kann es mich begeistern 😊

[@thenativeweb]

[gr] Danke für Dein Feedback 😊

[@MasterFX2000]

Ich stand vor ein ca. einem Jahr vor den gleichen Problemen und bin letzten Endes auch bei Go hängen geblieben. Ich komme aus der Hardware-Entwicklung und bin daher eigentlich nur mit C unterwegs gewesen. Und C ist auch nach wie vor eine meiner Lieblings-Programmiersprachen. Dennoch stößt man halt irgendwann an die Grenzen bzw. merkt dass man zu viel Programmieraufwand in etwas stecken muss um ein Projekt umzusetzen, oder um den Aufwand zu reduzieren viele Abhängigkeiten (auch damit auch Lizenzbedingungen) ins Haus holt. Bei Go ist halt bereits sehr viel in der Bibliothek enthalten (insbesondere für Cloudanwendungen) und Crosskompilate purzeln im CI/CD einfach in allen Varianten ohne zusätzliche Compiler-Umgebung dabei raus. Ein http-Server ist halt einfach nur ein Einzeiler. Dateien lassen sich einfach ins Binary einbetten. HTML-Seiten lassen sich super einfach via Tamplates dynamisch generieren etc... Weiterhin sollte man noch erwähnen, dass insbesondere für TDD bei Go die ganze Test-Infrastruktur bereits drin ist. Inzwischen gibt es auch Generics und damit bleiben kaum noch Wünsche offen. Außerdem finde ich die die Go Community sehr angenehm. Auf den GopherCons ist immer sehr viel Witz dabei.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@dirkj.3234]

Ein Video vollgepackt mit Informationen sowie eine hilfreiche Bewertung und Einstufung vieler aktueller Sprachen. Vielen Dank dafür! Der KZbin-Kanal von the native web entwickelt sich langsam aber sicher zu einer umfassenden Bibliothek und Nachschlagewerk rund um alle Themen zu Entwicklung und Architektur. Großartig! 👍 Zwei Anmerkungen habe ich allerdings zum Video: Es werden zwar Oracle und Microsoft als Firmen erwähnt, die Bedenken gegen die Sprache(n) mit sich bringen, aber ausgerechnet Google bei der Auswahl von Go ignoriert!? Das ist für mich nicht nachvollziehbar. Und zum visuellen Auftritt noch eine Bemerkung am Rande: diesmal fallen die Handbewegungen extrem auf und waren (für mich) so störend, dass ich nach der Hälfte das Tablet umgedreht und den Rest nur gehört habe. In anderen Videos fand ich es lange nicht so auffallend. Hier liegt es vermutlich an der tieferen Kameraposition und größeren Entfernung so dass die Hände relativ zentral im Bild sind. Aber das nur als Anregung, es schmälert nicht den Inhalt des Videos! 😉

[@thenativeweb]

[gr] Danke für das tolle Feedback 😊 Zum Thema "Nachschlagewerk": Da kommt demnächst noch etwas, da haben wir noch eine kleine Überraschung in Petto … 😉 Zum Thema Google vs Microsoft vs Oracle: Ja, das stimmt, auf das Thema "Google" sind wir bei Go nicht eingegangen. Dazu kommt demnächst noch ein eigenständiges Video. Und was die Handbewegungen angeht: Ja, verstehe ich … ist bei den neuesten Videos wieder anders.

[@kariltyboxing7267]

Bitte ein Developers Deep Dive über Go! :)

[@thenativeweb]

[gr] Kommt - wird aber noch etwas dauern 😊

[@anyaplays7150]

Bei den Anforderungen hätte ich trotzdem C#/.NET gewählt. Seit .NET Core 3.1 liefert man nämlich die Runtime mit aus bzw. kann mit ausliefern. Daher sehe ich die Runtime nicht (mehr) als Problem.

[@dannen59]

Super Video, Danke. Bin auch kürzlich auf Go gestossen und finde die Sprache äusserst spannend. Komme primär aus dem Umfeld von Client-Apps für die Administration (Adressen, Artikel, Buchhaltung usf. - ein CRM wie man heute sagen würde) und verwende dazu seit den Neunzigerjahren Clarion und MySQL. Die Stärke von Clarion liegt bei den Templates, die es erlauben, innert kürzester Zeit datenbasierte und kompilierte Apps zu erstellen. Zu Go habe ich Fyne entdeckt, womit man GUI-basierte Apps entwickeln kann. Kennt jemand von Euch Fyne, was haltet Ihr davon und gibt es Alternativen dazu? Mein erster Eindruck von Fyne ist sehr gut, obwohl oder gerade weil die GUI etwas anders aussieht als die Standard-GUIs von Windows oder macOS.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@windschattengeber]

Auch ich habe mir Fyne schon näher angesehen, aber noch nicht wirklich etwas damit umgesetzt, da ich hinsichtlich Go noch Anfänger bin. Fyne hat den Vorteil, dass es spezifisch für Go entwickelt ist und nicht nur über ein Binding eine GUI-Bibliothek einbindet, die für sich dann in einer anderen Sprache geschrieben ist. Der Initiator des Fyne-Projektes, Andrew Williams, hat mit "Hands on Gui Application Development in GO" (Packt Verlag) ein Buch geschrieben, in dem er mit Walk, andsLab UI, Go-GTK, Go-Qt, Shiny und Nuklear for Go einige Alternativen für die GUI-Entwicklung in Go im Vergleich zu Fyne darstellt (jeweils anhand einer kleinen E-Mail-Client-App) und bewertet. Das Fyne-Projekt wird auch aktuell weiterentwickelt, wenn man sich das Repo ansieht. Hoffentlich bleibt es weiterhin am Leben. Links zu den Alternativen finden sich unter "GUI" auch auf der Seite awesome-go.com/ .

[@customraspi]

Das sind für mich Entscheidungskriterien aus den 90ern. Wenn ihr wirklich Kundensoftware individuell programmiert, kennt der Kunde doch eh die SOLL-Logik seiner Businesssoftware. Oder programmiert ihr Server-Software als Produkte, die dann ausgerollt werden?

[@thenativeweb]

[gr] Um es kurz zu machen: > Oder programmiert ihr Server-Software als Produkte, die dann ausgerollt werden? Ja, auch. Und schon sind das keine "Entscheidungskriterien aus den 90ern" mehr 😉 Nicht alle sind in der Cloud. nicht alle nutzen Containerisierung. Das mag manchmal so scheinen, ist aber in der Praxis nicht so.

[@dosch7766]

Hallo, warum nicht Erlang oder Elixir? Die Erlang VM hat Nebenläufigkeit (Erlang Prozesse mit Message Passing) und ist Opensource. Erlang/OTP ist geeignet für Verteilte Systeme. Seit Erlang/OTP 24 gibt es den BeamAsm JIT-compiler für bessere Laufzeit Performance.

[@thenativeweb]

[gr] Danke für Deinen Kommentar - ich denke, gegen Erlang und Elixir spricht in erster Linie die Verbreitung. Finde mal jemanden, die oder der Erlang entwickelt … (und damit will ich nicht sagen, dass das "niemand" macht, aber Dir dürften nicht im größeren Stil Leute begegnen, die das können …).

[@Phoboss32]

Wie gut ist Go für die Anwendungsentwicklung geeignet?

[@BenjaminWagener]

Wenn ihr jetzt schon im Backend teilweise andere Wege geht, habt ihr auch schon überlegt, eventuell mal React an der einen oder anderen Stelle durch etwas leichtgewichtigeres wie etwa Svelte zu ersetzen?

[@thenativeweb]

[gr] Ehrlich gesagt nein … mit React sind wir aktuell nach wie vor recht zufrieden, zumal das Ökosystem darum recht gut ist. Am ehesten beschäftigen wir uns daneben noch mit Vue, wobei mir persönlich da React mehr zusagt. Aber, kurze Antwort: Nein 😉

[@Muescha]

Bei Java ginge mit GraalVM eine Compilierung - aber (um auf die vorgegeben Kriterien zurückzukommen) das ist nicht automatisch dabei sondern ein extra Projekt

[@uselesscommentary5404]

Wie immer sehr detailliert - danke dafür. Ich denke besser hätte die Entscheidung- Bzw. Entscheidungsfindung.

[@thenativeweb]

[gr] Danke schön 😊

[@christianbaer2897]

Ich habe einen Webshop auf C++-Basis gesehen und kann verraten: Die Entscheidung etwas anderes als C++ war gut ;-) Ich bin sehr auf die Go-Deep-Dives etc. gespannt und werde mir mal anschauen, was die Sprache so an Vorteilen bietet.

[@raymundhofmann7661]

Könnte es sein dass der Autor des C++ Webshops inkompetent war? Irgend wann landet alles bei C++, oder einer Sprache mit deterministischem und vom Autor steuerbaren Memory Management, denn alle Sprachen die das nicht unterstützen blähen den Speicherbedarf und die CPU Belastung auf, auch GO. Alles in der Wirtschaft strebt zur effektivsten Lösung, die niedrigsten Hosting Kosten und die geringste Hürde und Belastung für den Endanwender, kein Platz für Ineffizienz, nur so lange etwas neu ist wird Ineffizienz vom Markt toleriert.

[@christianbaer2897]

@@raymundhofmann7661 Nein. Die Autoren waren und sind ziemlich kompetente Menschen. Es wird einfach nicht alles bei C++, D oder Assembler landen. Das wäre Irrsinn. Wenn dem so wäre, gäbe es keinen Grund für all die anderen Sprachen. Kosten für Rechenzeit und Speicher (flüchtig wie persistent) sind ein Witz, wenn man dagegen die Kosten für Entwickler hält. In einer sich schnell ändernden Umgebung wie dem E-Commerce, ist Entwicklungszeit ein wesentlich kosteneffektiverer Hebel als CPU-Zeit. Die Rechen"leistung" die es braucht um einen Webshop zu betreiben ist lachhaft gering. Es gibt durchaus bereiche, in denen es auf jede Millisekunde ankommt und dort haben die Sprachen, die uns Entwickler*innen ein höchstmögliches Maß an Kontrolle geben klar den Vorteil. Für Webshops sieht das sehr anders aus. Erschwerend kommt hinzu: Finde mal Entwickler*innen mit Kenntnissen in C++ (oder dem Willen sich darin zu vertiefen), die gleichzeitig Web-Development machen. Das führt unweigerlich zu Silos (Frontend, Backend) und damit zu Kommunikationsmehraufwand und damit wird wieder alles langsamer. Während man also in der Villabajo noch sicher stellt, dass Feature X keine Speicherlecks einführt, wird man in der Villariba schon an Feature Y und Z arbeiten.

[@raymundhofmann7661]

@@christianbaer2897 Ich sprach nicht von D oder Assembler, ist aber interessant wenn das von dir in einem Satz mit C++ assoziiert wird. Es ist davon auszugehen dass durch weitere Standardisierung im Web E-Commerce die Kosten für die Entwicklung sich so weit reduzieren dass die Hosting Kosten signifikant werden. Das Argument der "lächerlichen Rechenleistung" ist das gleiche wie mit der immer größer werdenden Rechenleistung und dem immer größer werdenden Speicher weswegen Effizienz irrelevant werden sollte und es ist gescheitert. Es ist gescheitert an der Stagnierenden Single Core Leistung seit 20 Jahren und am Energieverbrauch die immer höhere Rechenleistung fordert seit dem mobile Rechner & Smartphones dominieren. "Millisekunden" sind sekundär, primär ist die Kontrolle die effizienteste Lösung realisieren zu können. Wer heute, wo es schon über 10 Jahre im C++ Standard smart pointer gibt von Speicher Lecks redet, der hat es scheinbar wirklich mit weniger kompetenten Leuten zu tun, ist ja auch deine Aussage, die Kompetenz die C++ fordert etwas funktionierendes und effizientes zu realisieren ist hoch, so hoch dass es eine Inflation an Sprachen gibt die mit weniger Kompetenz auch brauchbare Lösungen versprechen und, spärlich und richtig Angewendet das auch tun. Ich sehe eher dass diese ganzen neuen Sprachen mit dem Ziel mit weniger Kompetenz eine ausreichende Problemlösung zu schaffen vor allem den Interessen von großen Organisationen dienen. Siehe z.B. .NET oder swift. Sie sind eine Folge genereller Überforderung, fehlender Standardisierung und der Gewinnabsichten diverser Organisationen. Es ist prinzipiell nicht verwerflich, ja sogar ratsam, sich das Leben möglichst einfach zu machen, also mit "weniger Kompetenz" ein gutes Ergebnis zu erzielen, doch hierbei kann man nicht generell das Kompetenzniveau senken, man muss im Gegenteil die Kompetenz dort am meisten anwenden wo sie sich am besten auszahlt. Es ist also die "Dynamik" an Kompetenz die am Ende zählt um im Gesamtergebnis die beste Lösung zu erreichen. Und genau das beschreibst du ja funktioniert nicht in deiner polemischen Anekdote und es hat nichts mit der Wahl einer Sprache sondern alles mit den Beteiligten zu tun.

[@christianbaer2897]

@@raymundhofmann7661 Diese Standardsoftware fürs E-Commerce existiert nicht. Es gibt ein paar große Frameworks und ein paar fertige Shops, die man sich anmalen kann. Keiner davon ist in C++ oder einer anderen Sprache mit dediziertem Speichermanagement geschrieben.

[@raymundhofmann7661]

@@christianbaer2897 Da sehe ich erhebliches Potential zur Optimierung, es ist nur eine Frage der Zeit wann es realisiert wird. Der normale Web Shop ist dann vielleicht eine Schablonen Webapp über Websocket an ein hocheffizientes und standardisiertes Backend angebunden. Der Web Shop ist dann meist nicht mehr als eine "Skin" mit schönen Bildern, kornblumenblauen Buttons und kann ohne Probleme weiterhin mit JS/TS realisiert werden.

[@davidzakrevskyy3406]

Was ist mit Erlang? Ich finde es eine gute Alternative zu Go.

[@Tim6993]

Sehr interessantes Video - wie gewohnt informativ :) Hast du dir mal überlegt deine Videos auf spotify als Podcast zur Verfügung zu stellen? Ich schaue deine Videos oft beim Auto fahren oder spazieren gehen und da wäre ein Podcast geeigneter oder spricht da etwas deinerseits dagegen? Würde mich freuen deine Videos auch bald als Podcast auf spotify zu sehen :)

[@thenativeweb]

[gr] Danke für Dein Lob 😊 Was Podcasts angeht … ja, darüber haben wir schon nachgedacht, haben uns aber dagegen entschieden. Unter anderem, weil wir ja auch immer auf Infocards und die Kommentare und so hinweisen, und das passt im Podcast ja nicht so wirklich.

[@chefsalat]

mich würde das Thema Cross-Plattform -Development bzw. -Compiler, mal an einem Beispiel betrachtet, interessieren. Wie funktioniert das bei Binaries? Es gibt nicht viel Content dazu bisher, leider.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@michael_1010]

Wenn ich die Wahl zwischen GO und Rust fürs Web hätte, würde ich aktuell auch GO bevorzugen. Die Rust Bibliotheken für Webanwendungen sind aktuell noch oft in Entwicklung und weniger stabil. Rust ist eine sehr interessante und gute Sprache, obwohl das erlernen wirklich deutlich schwieriger war als bei allen anderen Programmiersprachen, die ich bisher gelernt habe. Ich denke Rust wird sich erstmal weiter dort verbreiten wo es sehr systemnah ist, wie z.B. Treiber, Kernelmodule oder auch wenn bei sicherheitsrelevanten Themen, da einige Fehler in safe Rust so nicht mehr möglich sind. Rust ist eine wirklich tolle Sprache, damit mal etwas herum zu probieren kann ich jedem nur empfehlen, eventuell hat jemand lust sich an den OpenSource Projekten zu beteiligen und bringt dann auch Rust ein bisschen nach vorne in den anderen Bereichen. Ich habe letztens jedoch aus den gleichen Gründen wie hier im Video erklärt wird zu GO gegriffen um einen kleineren Webservice umzusetzen, ging schnell ohne größere Probleme und lief perfekt auf der Zielplattformen Windows und Linux trotz der Entwicklung auf dem Mac.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@xtra9996]

Eindeutig Go. Ist meiner Meinung nach die richtige Entscheidung. Nutze ich selbst, allerdings eher für die Entwicklung von Kommandozeilen-Tools, was durchaus eine weitere Stärke dieser Sprache ist. Auch hier ist einfaches Deployment eine nette Eigenschaft.

[@thenativeweb]

[gr] Services sind ja häufig auch nichts anderes als Kommandozeilentools - nur eben solche, die sich per HTTP oder per ähnlichem Protokoll ansprechen lassen.

[@Venistro]

Ist es nicht möglich, für nodejs den Source Code mit V8 zu kompilieren, so dass man nicht den Sourcecode ausliefert und Node das dann beim Start der Anwendung selbst durchführt, sondern einfach bereits vorher schon mit V8 "cached". Zumindest hatte ich da glaube ich mal was gelesen. Aber ich fände es auch gut, wenn es zumindest für TypeScript einen compiler geben würde. Aber vielleicht tut sich da ja noch was. Nur den Punkt zur Laufzeitumgebung habe ich noch nicht so wirklich verstanden... Also im Rechenzentrum usw. ist es kein Problem, dass die Laufzeitumgebung vorhanden ist. Das verstehe ich. Aber wieso sollte das auf dem Computer von dem Entwickler ein Problem sein und welche Endanwender sind genau gemeint? Und ich meine, da gäbe es doch bereits Lösungen, die den Sourcecode + Nodejs in eine executable packen, ohne Docker oder ähnliches.

[@thenativeweb]

[gr] Ja, solche Lösungen gibt es - nexe und pkg zum Beispiel. Und die funktionieren auch teilweise ganz passabel, aber so ganz das Wahre sind sie dann halt doch auch nicht. Das fängt damit an, dass sie im Prinzip das komplette Node verpacken (was die Binaries per se schon mal sehr groß macht), und den Quellcode Deiner Anwendung dann einfach dazulegen. Ja, das ist dann ein Binary, ist aber a) riesig, und b) am Ende doch nicht "echt" kompiliert. Im Grunde ähnlich wie ein Self-Extracting-ZIP-File 😉

[@MichiOnline1721]

Habt Ihr euch auch gedanken Bezüglich WASI und WASM gemacht weil das nicht genannt wurde (auch nicht assemblyscript). Ich meine ja, noch in entwicklung, ja ist auch eine IL aber schwerer zu decompilieren da primitiver aber passt perfekt zu typescript und (in zukunft) keine runtime. Grade im Cloudumfeld wenn man an AWS Lambda oder Azure funktions denkt doch ohne docker sehr interessant. Und Go hat bei Wasm das selbe problem wie C# durch conzepte wie exceptions in wasm langsamer als Javascript. Das spricht doch wieder für Rust, C++ und Assemblyscript. Aber ansonsten finde ich Go doch sehr gut komplementär zu Typescript.

[@thenativeweb]

[gr] Das war tatsächlich keine Überlegung, weil wir ja nicht nach einem Ersatz für JS/TS gesucht haben, sondern als Ergänzung. Und insofern steht uns die Tür mit WASM/WASI über Node.js als Host und AssemblyScript als Sprache ja nach wie vor offen. Und das ist richtig - der Schritt von TS zu AS ist sehr klein.

[@Tekay37]

Du hast in dem Video die jew. Unternehmen hinter einer Sprache (Oracle bei Java, Microsoft bei .NET) betrachtet, bei GO aber nichts zu Google gesagt. Inwiefern war das denn bei eurer Entscheidung relevant? War das eher einpositiver oder negativer Aspekt? Ich bin beeindruckt, wie gründlich ihr euch mit ungefähr allen relevanten Sprachen auseinandergesetzt habt um eine Entscheidung zu treffen.

[@thenativeweb]

[gr] Danke für Dein Feedback 😊 Und was Google angeht - da kommt demnächst noch ein Video zu diesem Thema!

[@llMalibu]

Vielen Dank für die Einblicke! Es wäre noch interessant zu beleuchten, in welchen Situationen und bei welchen Anforderungen welche Sprache zur Anwendung kommt. Und ob NodeJS und Go vielleicht sogar zusammen in einem Projekt genutzt werden können.

[@thenativeweb]

[gr] Das wird die Zeit zeigen, aber auf die Frage kommen wir sicherlich über kurz oder lang mal zurück …

[@hanshans4006]

Sehr interessant 👌🏻

[@thenativeweb]

[gr] Danke schön 😊

[@jbZahl]

Interessant. Ich kam von c++ (ja auch das gibts teilweise noch für Web-Server Code im Userland. :D ) zu golang als Sprache Webserver Dienste. Im Moment hauptsächlich für REST-Apis, und es ist um Längen einfacher und schneller in der Entwicklung. Allein das Dinge wie lightweight threads, csv-, json- und xml-Parser, sowie ein einfach verständliches Framework für Webserver schon "ab Werk" dabei sind, macht halt vieles echt angenehm. Solange man keine selbst entwickelten "Spezialanforderungen" mit harten Echtzeitanforderungen (wie z.B Audio/Videostreaming oder ähnliches) hat, kann ich auch mit der automatischen Garbage Collection gut leben. Mein Arbeitgeber steckt auch gerade mitten im Umzug von handgezüchteten Echtmetallservern zu Containern auf VMs. Und klar soll immer alles Neue lieber in die "neue Welt", aber ab und an muss halt doch noch mal "eben schnell" was in die alte Welt und da funktioniert ein golang-binary halt echt in beiden Szenarien gleich gut.

[@thenativeweb]

[gr] Danke für Dein Feedback 😊

[@flynifty3951]

Wurde C# erwähnt ?

[@thenativeweb]

[gr] Ja - und das ist auch in der Videobeschreibung enthalten und verlinkt: kzbin.info/www/bejne/rZSYkpera5hsbKM

[@lollo4711]

Hatte Go bislang nicht auf dem Schirm, mal etwas angeguckt... Was mit gefällt: Native Compiled Executables (GC etc. inklusive). VS-Code kann Go. Für mich war microsoft bislang immer das Beste... vielleicht Go als Reverse-Proxy für C# (dotNet) nehmen?! Live-Vorstellung von Go-Features wäre Klasse!!!

[@thenativeweb]

[gr] Go einmal näher vorzustellen kommt sicherlich, wird aber wohl noch etwas dauern …

[@RamazanGevrek]

Dart fände ich noch als eine interessante Sprache, deshalb weil Google mit Flutter bei mobiler App-Entwicklung auf Dart setzt, welcher für's schnelle entwickeln auf einen JIT Compiler und mit einem AOT Compiler für die LLVM kompiliert, und die Szenarien für den Einsatz von Flutter und Dart stetig weiter ausbaut.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@No-no-no-no-nope]

Ich habe mir auch mal Dart und Flutter angeschaut und in einem Unternehmen wie Google kann man es sich sicherlich leisten eigene Sprachen einzuführen, aber ansonsten würde ich eher auf Technologien setzen welche weit verbreitet sind. Mit Kotlin kann man zum Beispiel viele Android Entwickler finden, welche nur KMM lernen müssen um cross platform entwickeln zu können. Mit React Nativ das gleiche für JS Devs. Mit Spring oder Node hat man dann noch gleich weit verbreitete Backend Frameworks. Zu guter letzt geht es hier ja um eine Sprache für die Cloud und da ist Dart aber mal direkt raus.

[@svenludwig7435]

Go ist ne gute Wahl, nutzen wir auch in der Firma. Für kleine Services finde ich Go sehr übersichtlich und schnell. Es ist aber schon eine Umgewöhnung, wenn man von OOP kommt.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@VeryBlackMan]

In go kann man auch Objekte zusammen bauen, aber das sieht etwas gewöhnungsbedürftig aus. Zumal man hier mit Pointern arbeiten muss. Interessanter dagegen finde ich Dart. Die Syntax ist auf OOP ausgelegt. Zusätzlich hat man die Möglichkeit mit Futter eine Mobile App zu schreiben.

[@sGiny1980de]

Öhm, Go ist OOP. Es nutzt halt keine Vererbung dafür, was ich ehrlich gesagt für die absolut richtige Entscheidung halte. Und das Embedding von structs benötigt nicht zwingend Pointer.

[@VeryBlackMan]

@@sGiny1980de stimmt man kann auch ohne einen Pointer arbeiten, wenn man die Kopie des Wertes benötigt. Womit ich gedanklich noch nicht klar komme ist mit dem type struct. Aus C kenne ich das ein Data Struct durch x Functions im gesamten Code geschleift wird. Man weiss nie welchen Zustand der Data Struct zum Zeitpunkt X hat, da er durch alle möglichen Functions ging und eventuell geändert wurde. Wenn später der Data Struct angepasst werden soll, muss man vielleicht im gesamten Code nach den Functions suchen, welche den Data Struct nutzen und anpassen. Wie sieht das hingegen in Go aus? Dürfen nur die Functions in der selben Datei auf den Data Struct zugreifen? Oder ist der Data Struct für alle Functions im gesamten Code verfügbar? Ansonsten ist das für mich nix anderes als was C mit dem Procedural Programming gemacht hat.

[@VeryBlackMan]

Ich hab mich mal tiefer in Go eingearbeitet, um den Grundgedanken hinter der Sprache besser verstehen zu können. Normalerweise fängt man mit einer class an, die alles beinhaltet um einen Job ausführen zu können. Bei Go geht es gefühlt anders herum. Zuerst wird der Container für die Daten erstellt und erst im Anschluss die methods. An das anders herum denken, muss ich mich erst noch gewöhnen. Das Schöne dabei finde ich das die Sprache dadurch nicht überladen ist und alles von Haus aus mitbringt, was man zum Entwickeln benötigt.

[@bobderbraumeister6919]

Wenn du Prolog und Ruby erwähnst könntest du auch Erlang und Elixir erwähnen ;) (Obwohl beide auf der BEAM laufen, weshalb die rausfallen)

[@dominik4496]

Teile viele eurer Sichtweisen und Wünsche warum ich ebenso bei Go gelandet bin als Ergänzung zu PHP und Python. Aber für das Web sehe ich immer noch viele Vorteile bei PHP gerade durch Frameworks wie Laravel, bestehender CMS usw.

[@harveychuba5442]

Ich habe mich für Rust entschieden letztens. Anmerkung: Ich habe ein anderen anwendungsfahl Game Entwicklung und Programmieren ist mein Hobby. Den Punkt das Rust Schwierig ist würde ich Bestätigen, aber das betrifft nur 2 Konzepte. Die meisten anderen Konzepte sind nicht anderes wie in anderen Programmiersprachen. Natürlich alles meine Persönliche Meinung. Ich sehe die Abhängigkeit Mozilla etwas anders als ihr. Rust war ein Projekt von Mozilla aber es existiert jetzt die Rust Foundation. Die eine vollkommen eigenständige Organisation ist. Dazu wird Rust immer mehr in Großen Projekten integriert wie Windows oder Linux. Wodurch ich bezweifle das plötzlich der Geldhahn oder die Entwicklung an Rust plötzlich aufhören wird. Zu euren Video, ich finde echt toll wie ihr eueren Entscheidung Prozess geteilt habt. Ich glaube es kann vielen helfen sich ein Bild zu machen über Unterschiedlichsten Programmiersprachen. Besonders was Kriterien waren kann bestimmt manch einen Helfen.

[@oliverberning130]

Einziger Haken bei der Argumentation. Die hervorgehobene Kritik, dass eine zu große Firma hinter der Programmiersprache steckt, ist bei der Wahl von "Go" nicht mal mehr angesprochen worden. Hier wären vielleicht zwei oder drei Sätze dazu von Vorteil gewesen, warum das Argument zumindest nicht mehr den Stellenwert hat. Google, Microsoft und Oracle, alle arbeiten nach rein wirtschaftlichen Interessen. Tatsächlich sehe ich jedoch Go ebenso als die bessere cloud- und web-native Programmiersprache. Allerdings empfinde ich die Syntax als oft zu simpel, auch wenn jetzt Generics Einzug erhalten haben. Bestimmte Konstrukte sind daher nicht so ausdrucksstark wie z.B. Kotlin. Ja, sogar Java halte ich dagegen für ausdrucksstärker, da hier eine einheitliche Struktur und Beziehungen erzwungen werden. Bei den Go-Projekten, die ich mir angeschaut und erweitert habe, fühlt sich das mehr nach "Kraut und Rüben" an. Nicht umsonst gibt es viele Videos über die richtige Strukturierung von Microservice-Implementierungen. Mit Quarkus, Micronaut und immer mehr Spring Boot lässt sich auch Java mithilfe der GraalVM nativ kompilieren. Und dieser Compiler ist mitnichten ein Exot. Das wird inzwischen produktiv im Enterprise-Sektor eingesetzt. Einzig die Hürde der komplexeren Sprache und Frameworks bis hin zu akademischen Auswüchsen ist tatsächlich etwas, was die "Wartungsfreundlichkeit" (ich meine damit nicht "Wartbarkeit") von in Java geschriebener Software eher hinderlich als förderlich ist. Daher ist der Einsatz von "Go" nachvollziehbar und auch aus meiner Sicht richtig. Aber ich bleibe dabei: Go ist einfach zu erlernen, aber bisweilen schwer zu meistern.

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊 Was Google als Unternehmen angeht - dazu kommt noch ein Video.

[@Hannibal215000]

Ich musste schon ein wenig schmunzeln als Sie Assembler in diesem Kontext angesprochen haben, der nächste Schritt wäre wohl die hexadezimale oder gar die binäre Darstellung. 🤣 Ich habe jetzt auch schon die ersten Schritte mit Go hinter mir und bin direkt schockverliebt nachdem das erste Bauen einfach so geklappt hat ohne irgendwelche Kopfschmerzen, Warnings und ewig langer Konfiguration. - einfach "go build" und fertig! - und die binary Datei kann ich einfach so auf die Systeme werfen und direkt ausführen. Wenn ich das richtig gelesen habe kann man auch über die Flags mit "go generate" unterschiedliche Zielarchitekturen einstellen...

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@marcello4258]

problem #3 genau wie pip.. malware ohne ende. .. Was ich interessant finde, dass Du sagst die JVM fuehlt sich nicht leicht an, vorher aber mit JS gearbeitet hast - und da liegen groessere Welten zwischen als zwischen JVM und C.. Aber dennoch denke ich Go ist der richtige Weg, auch wenn Java ein grosses Framework in der WebDev hat, so ist Go sehr angesagt und hat viele moderne Kompenenten nativ dabei.. Compiled mit Garabage collection, native Multithreading.. (GoRoutines) etc

[@thenativeweb]

[gr] Danke für Deinen Kommentar 😊

[@thosteg]

Nicht für euch von besonderer Relevanz, aber als komplettes Ökosystem in Zukunft vielleicht interessant: Elixir auf der Erlang VM.

[@thenativeweb]

[gr] Danke für den Tipp 😊

[@yahmk3978]

Was mir bei GO stets etwas unklar war (und ist) sind die Packages und Modules. Bin mir sicher, dass dies im Laufe der Beiträge zur Sprache kommen wird: aber bitte buchstabieren, so dass ich es mitschreiben kann. :)

[@thenativeweb]

[gr] Kann ich gut verstehen - ging mir auch eine Weile lang so, eigentlich ist es aber ganz einfach: Ein Modul ist das, was nachher zu einer Datei kompiliert wird, also entweder eine Anwendung oder eine Bibliothek. Im Prinzip kannst Du "Modul" mit "Projekt" gleichsetzen. Ein Package ist ein Verzeichnis. Jedes Verzeichnis ist ein Package, und jedes Package ist ein Verzeichnis. Das ist immer eine 1:1-Zuordnung. Ein Package ist eher so etwas wie ein Namespace. Jedes Modul besteht aus einem oder mehreren Packages. Im einfachsten Fall halt nur eins, aber es können auch mehr sein. Klarer?

[@yahmk3978]

@@thenativeweb Bin in der Zwischenzeit über eine Seite gestolpert, die das Package-Problem ('Problem natürlich aus meiner Sicht) sehr gut erklärt: kzbin.info/www/bejne/hKebe5KIqshlbpI

[@marcello4258]

Auch wenn jetzt auch auf go gewechselt bin so war Scala bei mir ganz weit vorne. Scala hat (mittlerweile) einen offiziellen native Compiler btw und mit zio ein sehr gutes Framework für Web Development. Was für die evtl interessant sein könnte Scala kann auch zu JS übersetzt werden was gut für Wiederverwendbarkeit ist. Also wenn du irgendwann mal Langeweile hast schau gerne mal rein. Sbt ist genau so einfach wie npm.

[@michaelbrauner5320]

Warum nutzt ihr eigentlich keine Ökosysteme wie Drupal. Ist das nicht unschlagbar für Plattformen von groß bis klein?

[@snapstromegon]

Das kommt stark darauf an. Wenn ich z. B. eine Website bauen möchte, die nachher wie z. B. ein Blog von einem Unternehmen ohne großes technisches Verständnis geführt wird, dann kann sowas wie Drupal oder Wordpress sehr gut sein. Wenn ich aber eher Services umsetze, die nur eine kleine Aufgabe haben und eventuell seperat entwickelt werden sollen, einen möglichst kleinen Footprint haben sollen, Höhe performance brauchen und dabei z.B. externen Anforderungen wie z.B. einem externen config Management entsprechen müssen, dann ist es meist schneller, einfacher und korrekter das ganze System selbst (mit vorhandenen Bibliotheken) zu bauen.

[@BenjaminWagener]

Drupal ist in PHP geschrieben und daher treffen schon mal alle hier genannten Argumente gegen PHP hier schon mal zu. Davon mal abgesehen ist Drupal vielleicht eine Alternative, wenn man eine Community-/Intranet-Seite in einer klassischen Host-Umgebung realisieren möchte, es taugt aber null als Basis für eigene auf individuelle Ansprüche ausgerichtete Web-Applikationen, denn dafür ist es viel zu fett, komplex und unflexibel. Selbst innerhalb des PHP, gibt es für etliche Anwendungsfälle bessere Alternativen. Für eine einfache Seite mit Blog ist Wordpress z.B. viel besser. Für kleinere Communities würde ich eher Joomla vorziehen, weil das weniger komplex ist, wenn es eine PHP-Host-Umgebung sein soll. Also nein, Drupal ist definitiv nicht unschlagbar für Plattformen von groß bis klein. Drupal ist ein Dino, noch aus der Zeit als PHP der absolute King im Web war. Aber wie man allein an diesem Video schon sehen kann, spielen da immer mehr andere Sprachen eine Rolle, weshalb die Nutzung von Drupal auch sinkt. Meist sind es eher Legacy-Umgebungen, wo Drupal noch läuft, wo aber häufig nicht mal die neueste Version von Drupal eingesetzt wird. Die Mehrzahl der Drupal-Sites läuft glaube ich immer noch mit Drupal 7, während Drupal eigentlich schon bei 10 ist. Ich würde niemanden empfehlen ein neues Projekt nochmal mit Drupal anzufangen.

[@michaelbrauner5320]

​@@BenjaminWagener Aha, interessant. Und welche Alternative zu einem kompletten Ecosystem gibt es? Ich meine, zum Beispiel ein Kunde aus der Industrie möchte eine Firmenwebseite. Multiplattform, Multisite, Multidomain, Multilanguage - natürlich mit custom Entities für die komplexe Produktpalette und einem Javascript-Konfigurator, Facetted Search usw usw. . Nächstes Jahr fällt ihm ein, dass er bestimmte Dinge auch online verkaufen könnte. Dann soll mit der bestehenden Produktpalette ein Shop entstehen. Ein paar Monate später, kommt ihm die Idee, eine App entwickeln zu lassen. Alle Daten müssen nun per Restful-Service zur Verfügung stehen. Dann möchte er noch ein Forum dazu, wo seine Mitarbeiter (alles bestehende Plattformuser) Kundenanfragen beantworten und moderieren können. Und das alles möchte der Kunde natürlich zu einem kompetetiven Preis - das bedeutet meistens, dass man schauen muss, das überhaupt was übrig bleibt. Gibt es da viele Alternativen zu Drupal, bei denen man nicht schon zu Beginn hoffen muss, dass dem Kunden nicht bald neue Wünsche kommen.? Nimmt man Drupal, freut man sich über neue Kundenwünsche, weil das meiste davon geht bequem mit einem Modul und den Rest passt man an. Wenn ich anfange, mit einem Framework wie Django oder Symfony zu coden, brauche ich für die Grundfunktionen 50 Mal so lange wie mit Drupal für das gesamte fix-fertige System. DeFacto, hänge ich dann schon eine Woche alleine am Cookie-Consent Popup und seiner systemweiten GDPR-konformen Umsetzung. Von Userverawaltung, Permissions, Content Revisions, Media-Library, Bildbearbeitung usw usw. reden wir da noch gar nicht.

[@michaelbrauner5320]

@@sven2529 Was meinst du damit? Was beides?

[@BenjaminWagener]

@@michaelbrauner5320 Klar gibt es da Alternativen zu Drupal. Die Stichworte lauten da Modularisierung und das richtige Werkzeug für jede Anwendung. Man kann auch von verschiedenen Lösungen für verschiedene Anwendungsfälle aus auf ein und der selben Datenbasis operieren. Dafür braucht es bloß eine gescheite API. Du versuchst alles mit einem Hammer zu erschlagen, egal ob auch Schrauben oder sonst was für Bauteile dabei sind. Das ist schlicht unsinnige Ressoucenverschwendung.

Sehr gute Herleitung. Könnte man sich eine Scheibe abschneiden.

[@thenativeweb]

[gr] Vielen Dank 😊

[@marcteufel8348]

Ich kann die Entscheidung nachvollziehen. Ich komme aus der Java-Welt und wir nutzen aktuell vorwiegend Java im Backend und React und Vue im Frontend. Mein Eindruck ist aber, dass Java einfach zu schwergewichtig, und ja, auch zu komplex ist um in der modernen Cloud-Welt wirklich zu funktionieren. Es ist mehr ein Bauchgefühl und vielleicht liege auch völlig falsch, aber für meinen Geschmack wird an Java in den letzten Jahren soviel "herumgedoktert" nur um es passend für die Cloud zu machen. Wie gesagt, ich komme aus der Java-Welt und ich liebe Java, aber die Zukunft für die moderne Webwentwicklung sehe ich - sorry - nicht in Java. Go ist viel leichtgewichtiger, braucht keine Laufzeitumgebung und als Java-Entwickler findet man leicht hinein in die Sprache. Es finden sich auch immer mehr Projekte, die Go nicht nur im Backend nutzen sondern zusätzlich das Frontend (in React oder Vue) damit "serven". Das heisst, mit Go bekommt man am Ende des Tages, wenn man es geschickt anstellt, ein sinnvolles Gesamtpaket geliefert mit dem man Backend und Frontend unter einen Hut bekommt. Daher gute Entscheidung. Wir werden in Zukunft auch mehr in Richtung Go gehen.

[@thenativeweb]

[gr] Danke für Deinen Kommentar - und ja, gerade was Du auch am Ende geschrieben hast, mit dem Frontend, das sich damit ausliefern lässt, das ist ein (denke ich) wichtiger und sehr interessanter Punkt 😊

[@No-no-no-no-nope]

Jupp, selbe Meinung + Go hat das beste Maskottchen mit Gopher 🦫

[@TommyVorlostRiddle]

PHP ist auf dem Markt schon noch eine relevante Größe. Einfach weil es sehr große Frameworks und CMS gibt die darauf basierend. Laravel oder Symfony zum Beispiel.

[@sGiny1980de]

Wer schon mal Projekte über Jahre betreut hat, wird Laravel oder Symfony meiden, wie der Teufel das Weihwasser. Du bist am Ende nur noch damit beschäftigt, das Framework upzudaten. Das hat mich letztlich von PHP auch weggebracht. Die Community hat diese ein Framework to rule them all Attitüde. Bei Go holst du dir ein Modul für einen Zweck. Wird dieses irgendwann nicht mehr unterstützt, ist es recht einfach, es durch etwas anderes zu ersetzen, oder einen eigenen Fork hochzuziehen.

[@thenativeweb]

[gr] Ja, das ist richtig - das ist aber vor allem historisch bedingt, und betrifft vor allem den Bereich um WordPress, CMS-Systeme und ähnliches … In der reinen Service-Welt habe ich noch nie PHP angetroffen - immer nur in Verbindung mit UI. Und für reine Services habe ich schon vieles gesehen: Von Node.js über .NET, Java, Go, Rust, … bis hin zu C++. Aber kein PHP. Und ich würde mich mal so weit aus dem Fenster lehnen, zu behaupten, dass PHP kein Wachstumsmarkt mehr ist, zumindest nicht im reinen Backend-Bereich.

[@axelbaumann8182]

Mit GraalVM kann man Java nativ compilieren

[@thenativeweb]

[gr] Ja, das stimmt, aber GraalVM ist halt kein "offizieller" Bestandteil des Java SDKs, oder?

[@axelbaumann8182]

@@thenativeweb das stimmt, die GraalVM ist kein Bestandteil des Java SDK.

[@LA-fb9bf]

Go ist doch absolut rudimentär wenn es um DB Zugriff geht, oder ist es mittlerweile etwas ausgereifter?

[@thenativeweb]

[gr] Da ich nicht genau weiß, worauf sich Deine Kritik bezieht, kann ich Dir darauf leider keine Antwort geben - was genau stört Dich denn beziehungsweise was genau fehlt Dir denn?

[@LA-fb9bf]

@@thenativeweb ORM Mapper wie Hibernate.

[@FrankHRitz]

Wartbarkeit über Lebenszeit von Software > 8 Jahre. Die Entscheidung ist gut und wäre von mir auch so gemacht worden. Es ist jedoch sehr schwierig Entwickler zu finden.

[@StefaNoneD]

Der dritte Punkt gegen Rust ist nicht valide, da Mozilla nicht mehr der Hauptsponsor von Rust ist. Hinter Rust steckt, wie du schon sagtest, die Rust Foundation und hinter der Rust Foundation stecken bspw. Amazon, Google, Microsoft, Huawei, Meta (Facebook), ARM, Toyota, Dropbox und noch viele mehr.

[@thenativeweb]

[gr] Jain … also einerseits ja, andererseits habe ich ja im Video erwähnt, dass das in der Vergangenheit dazu geführt hat, dass das Vertrauen da etwas angeknackst ist, und das muss halt erst mal wieder "verheilen", wenn man so will 😉

[@marcelkoch_net]

Golo, es fällt mir schwer Dein Argument bzgl Verbreitung von Rust nachzuvollziehen. Für meine Begriffe rationalisiert Du Deine Antipathie gegen Mozilla. AWS und Google investieren nach meinen Informationen inzwischen sogar mehr als Mozilla. Ich habe gerade auch noch mal nachgesehen. Sogar Threema ist mit dabei. An Deiner Stelle hätte ich das dritte Argument einfach weg gelassen. Die zwei ersten reichen doch vollkommen aus. Für mich bleibt dadurch ein fader Geschmack zurück, der den sonstigen sehr guten Argumenten eher schadet.

[@marcelkoch_net]

Deno als „Mogelpackung“ zu bezeichnen, halte ich für zu viel des Guten. Ich denke, hier hättest Du den Vergleich noch etwas detaillierter gestalten können. Das finde ich sehr schade. Was ist mit der nativen Unterstützung von Typescript? Was ist mit der integrierten Erweiterung durch Rust?

[@thenativeweb]

[gr] Gerade die „integrierte Unterstützung von TypeScript“ fällt für mich in den Bereich „Augenwischerei“. Deno führt TypeScript nämlich gerade nicht nativ aus - es wird einfach nur beim Start der Anwendung on-the-fly kompiliert. Im Grunde das, was ts-node auch macht, nur mit fest verdrahteter Version des Compilers. Ausführen kann Deno nämlich auch nur JavaScript.

[@ChrisJung]

Schön bei Go ist auch natives cross-compiling

[@thenativeweb]

[gr] Oh ja, das kann ich nur unterschreiben 😊

[@tobiasnickel3750]

hey, ich denke mir ist aufgefallen das die Argumente manchmal nicht Vollständig sind. Bei vielen sprachen sagst du das die Sprache einen anderen Fokus hat. aber ich glaube eher das es die community ist. Ich denke die Tatsache das c meist fuer low-level und system Applikationen genutzt wird, ist eher weil die community diesen Fokus hat. Das sorgt dafür das es keine guten libraries und packages fuer bestimmte aufgaben gibt. Bevor node.js du würdest sagen das JavaScripts eine Frontend Sprache ist. dabei had nur die backend Umgebung gefehlt. Python und R gelten als sehr stark für Datenverarbeitung, aber nur weil Python sehr früh ein gutes package hatte um excel zu lesen. in Node.js ein excel module ist erst sehr späht gekommen. Hauptsächlich wird der Schwerpunkt fuer die Community und die Anwendungsfälle natürlich vom Hauptentwickler der Sprache gesetzt. Apple stellt sicher das in swift alle IOS features verfügbar sind. Google hat für golang sehr gute Netzwerk Funktionalität in der standard library bereitgestellt. tldr: Der Schwerpunk einer Sprache kommt von der community und den Hauptentwicklern.

[@thenativeweb]

[gr] Das ist richtig - mit den meisten Sprachen kommt man ohne das Ökosystem drumherum ja nicht allzu weit. Und insofern stimmt es schon, dass der Schwerpunkt auch stark von der Community beeinflusst wird (so was wie Swift, was rein von Apple abhängt, mal außen vor gelassen). Trotzdem tragen die Sprachen dazu etwas bei - warum ist zum Beispiel Python und nicht JavaScript für Berechnungen so beliebt? Ein (1) Grund ist, weil JavaScript nur Fließkommaarithmetik kennt und daher für viele Berechnungen nicht besonders gut geeignet beziehungsweise auch schlichtweg nicht performant genug ist. Ein zweiter Grund ist vermutlich, dass es in JavaScript keine Threads gibt (gab). Nichtsdestotrotz hast Du aber recht, dass sich die Community sozusagen auf einen bestimmten Anwendungszweck "eingeschossen" hat, was dann irgendwann zum Selbstläufer wurde.

[@axelbaumann8182]

Ich denken, dass Go inzwischen etabliert ist und es das Zeug dazu hat, eine große Verbreitung zu finden.

[@thenativeweb]

[gr] Hoffen wir es 😊

[@DJTechnostyler]

Sehr gute Entscheidungsmatrix. Bei mir käme wahrscheinlich noch eine gewisse natürliche Ästhetik des Codes hinzu. Wenn ich schon den ganzen Tag darauf starren muss, dann soll das wenigstens auch irgendwie gut aussehen. Das liebe ich ja an JavaScript. Das hat diese natürliche Ästhetik irgendwie. Ist aber natürlich extrem subjektiv und hat mehr einen psychologischen Nutzen. Programmieren muss Spaß machen und da gehört das Aussehen meiner Meinung nach dazu. Was mich noch interessiert hätte, wie die Gewichtung war. Denn auch hinter GO steckt mit Google eine fragwürdige Firma, die mindestens genau so viel Einfluss auf das Web hat, wie MicroSoft und Oracle, wenn nicht sogar den meisten Einfluss. Wenn ich mal sehe, welche Tools es zum entwickeln gibt, dann steckt da schon irgendwie überall Google drin. Selbst VSCode baut auf die V8, was daran liegt, dass es eine Electron-App ist. Der Debugger ist der selbe, wie vom Chromium (Wobei der mittlerweile schon sehr buggy und selbst debug-würdig ist). Warum genau stört euch das eigentlich so? Bei Git z.B. regt sich ja auch niemand auf, dass es quasi ein "Monopol" hat. Wenn da mal die falschen dran entwickeln, dann war es das. Wäre doch mal ein cooles Video. "Wie gefährlich sind Google, Microsoft und Co wirklich?"

[@thenativeweb]

[gr] Danke für das Lob 😊 Was die Ästhetik angeht: Ja, da bin ich bei Dir. Die finde ich auch wichtig, denn eine Sprache, die rein visuell abschreckend aussieht, die mag man auch nicht gerne benutzen. Das finde ich an Go übrigens sehr spannend, dass es dort all die Diskussionen nicht gibt, weil es per gofmt einfach vorgegeben wird. Was Google angeht: Auch das ist ein valider Punkt - und ja, ich würde auch sagen, dass der Einfluss von Google auf das Web insgesamt viel größer ist als der von Microsoft und Oracle. Was uns an Oracle stört, ist die Kultur des Unternehmens - guck Dir an, was sie mit MySQL gemacht haben. Guck Dir an, was sie mit OpenOffice gemacht haben. Es ist ja kein Zufall, dass MariaDB und LibreOffice nicht nur als Forks entstanden sind, sondern die Originale in kürzester Zeit überflügelt haben. Dann, nimm die Datenbank: Ja, sie ist irgendwo seit Jahrzehnten "die Referenz" (wobei ich mich oft frage, warum eigentlich), aber wenn Du mit Oracle (der Datenbank) zu tun hast, fühlt sich das so dermaßen altmodisch und dinosaurier-mäßíg an. Zum Beispiel die Verbindung aus Node.js heraus: Das funktioniert nicht rein aus JavaScript, Du brauchst proprietäre Treiber, die Du richtig installieren und ansprechen musst … und dann vergleich das mal mit dem Microsoft SQL Server (den nehme ich nicht, weil ich damit sagen will, die beiden Datenbanken ebenbürtig sind, sondern weil er ebenfalls ein kommerzielles Produkt ist): Der fühlt sich in der Benutzung auch nicht gut an, aber das funktioniert um Welten besser und einfacher als mit Oracle. Gerade weil Du meintest, Entwicklung muss Spaß machen - genau das Wort "Spaß" ist so ziemlich das letzte, was mir bei Oracle einfällt 😉 Und was Microsoft angeht: Was mich daran massiv stört, ist, dass sie praktisch das komplette JS/TS-Ökosystem in der Hand haben. Wie gesagt, die Sprache, die IDE, den Package Manager, die CI/CD-Pipelines und das Git-Hosting. Wenn die sich nun morgen überlegen, GitHub abzuschalten zu Gunsten von Azure DevOps, dann wird das zwar einen Aufschrei in der Community geben, aber die Frage ist, ob Microsoft das interessiert. Wenn sie sich morgen überlegen, npm kostenpflichtig zu machen, dann … Wenn sie sich morgen überlegen, … das lässt sich endlos fortsetzen. Und ich habe meine Erfahrung mit 10 Jahren .NET gemacht, und ich habe erlebt, dass Microsoft eine größere Zahl an VB-Entwicklern vor den Kopf gestoßen und die Plattform abgesägt hat. Das gleiche Spielchen (im kleinen Stil) mit FoxPro. Das gleiche Spielchen mit WinForms, mit WebForms. Silverlight. Und, und, und. Microsoft hat in der Vergangenheit einfach keine Stabilität in Dinge gebracht, im Sinne, dass man sich darauf Jahre verlassen konnte (das war mal anders bei Microsoft!). Naja, und dazu jetzt Go im Vergleich: Google kontrolliert die Sprache. Punkt. Weder kommt die maßgebliche IDE von ihnen, noch kontrollieren sie das Ökosystem über eine zentral (!) organisierte Paketverwaltung, noch kontrollieren sie GitHub, und so weiter … insofern ist der Einfluss auf das Web an sich zwar riesig, aber der Einfluss konkret auf die Entwicklung mit Go ist eben nur ein Baustein von vielen. Und das ist bei Microsoft anders (und das, was ich mit .NET erlebt habe damals, da habe ich keine Lust mehr drauf …). Und guck mal, wie stabil Go seither ist, im Sinne von Breaking Changes. Das ist alles weitestgehend abwärtskompatibel, es gab kaum Brüche. Und dann vergleich das mal mit .NET. Ach ne, .NET Core. Ach ne, doch wieder .NET. Mit XAML. Silverlight. Ach ne ASP.NET MVC. Ne, lieber ASP.NET WebApi.. Ach ne, ASP.NET Core. Ne, doch wieder ASP.NET. Mit .NET Universal. Oder ohne. Dafür jetzt mit Blazor. Und so weiter … Du bist praktisch damit beschäftigt, ständig den neuesten Kapriolen hinterherzurennen, weil sich das Ökosystem alle fünf Minuten ändert, die Ausrichtung, die Strategie. Und das ist ja nicht nur die Plattform an sich. Das sind auch die Community-Programme, die Webseiten drumherum, alles was dazugehört: Codeplex? Gibt's nicht mehr. TechNet? Gibt's nicht mehr. XNA? Expression? Source Safe? TFS? …? Alles nicht mehr da. Da ist so viel Unruhe drin, über die Jahre, das ist aus unserer Sicht einfach keine verlässliche Basis. Und das in Kombination mit der kompletten Kontrolle über das JS/TS-Ökosystem hinterlässt einfach kein gutes Gefühl.

[@DJTechnostyler]

@@thenativeweb Oha... Mit der Wall of Text hab ich jetzt nicht gerechnet mein lieber Golo. Ich fühle mich schon irgendwie geehrt :) Man merkt, dass du da sehr viel durchgemacht hast und ja, das kann ich auch größtenteils nachvollziehen. Aber dieses "Wenn die sich entscheiden das abzuschalten", das hatten wir erst kürzlich so ähnlich mit Java. Wie du ja sicherlich mitbekommen hast, ist Java unter bestimmten Bedingungen nicht mehr kostenlos. Oracle hat auch "nur" diese Sprache in der Hand. Die Community ist weitestgehend selbstständig und eine Zentrale Verwaltung gibt's auch nicht (zumindest kenne ich sie nicht). In so fern bist du da bei Google auch nicht ganz sicher und die haben auch schon einige Dinge gegen den Willen der Mehrheit durchgeprügelt. Insbesondere auf KZbin. Mich würde es nicht wundern, wenn das auch mal mit GO passiert. Aber es stimmt schon, dass M$ da schon sehr krass ist. Eine Sache hab ich aber noch: MariaDB würde ich jetzt nicht als überflügelnd bezeichnen. :) MySQL finde ich jetzt auch gar nicht so schlecht. Hab da Jahre lang zufrieden mit gearbeitet und muss sagen, dass die DB nicht schlechter geworden ist. Als PDO kam musste man sich krass umgewöhnen, aber das war ja auch nur zu Gunsten der Sicherheit.

[@dailydosemedical]

Ich hab mich sofort in Go verliebt, als meine Dockerfiles plötzlich nur noch 2-Zeiler waren, in denen "FROM scratch" und ein Copy standen. Die größte Challenge für mich war das Management von Namespaces und das pinning von Abhängigkeiten. Darauf sollte man grade am Anfang ein besonderes Augenmerk legen, sonst komm man später in die Hölle.

[@Kirides]

1. FROM scratch ist nicht sonderlich sinnvoll, da hier u.a. CA-Certificates und Timezone Daten fehlen, distroless container sind da für den einstieg netter 2. Namespaces? Vermutlich meinst du Packages, Packages sind das was man in anderen Programmiersprachen unter verschiedenen Namespaces aufbaut - eine Komponente welche dieses "Package" (Funktionalität) bereitstellt. - Anders als in Java/C# wird in Go eher feature per package gelebt, als das aufschneiden von Features in "Modelle, Services, Api, Views" Ein package "repo.org/company/web/user" beinhaltet alles was für den Bereich Web an "user" features nötig ist. Ein Modell für Rückgaben, http-Handler für Anfragen, ... In dem package "repo.org/company/web" wiederum würde man alles antreffen was für das aufbauen eines Web-Services notwendig ist. Das Routing, middleware, sub-router, definitionen von authentifizierung (& oberflächliche authorisierung) für die registrierenden http-Handler Eine Struktur wie "repo.org/company/models" / "repo.org/company/services" / "repo.org/company/repositories" ist oft als ein ein anti-Pattern in Go aufgefasst und führt sehr schnell zu zyklischen Abhängigkeiten, was wiederum direkt zu Build-Fehlern führt. 3. Abhängigkeiten sind im standard schon gepinnt (Module)

[@wolfgangdames6627]

Hallo native web, grundsätzlich sehe ich es mit Go genau so wie Ihr. Als wirkliche Alternative bei Euren Anforderungen würde ich nur noch Java sehen. Es ist aber nicht richtig dass Java keinen Compiler hat, der ist immer beim JDk mit dabei und heißt javac. Und das mit der Laufzeitumgebung relativiert sich seit einiger Zeit, da Java seit Version 16 mit dem jpackage ausgeliefert wird. Damit ist es möglich, für verschiedene Platformen die Anwendung zu erstellen, incl. der Laufzeitumgebung. Und was das Deployement betrifft: Es ist einfach mit in der ausführbaren Datei enthalten sodass für BE + FE nur _eine_ Datei deployt werden muss. Ich weiß nicht ob Go diesen Vorteil auch hat. Und noch etwas: keiner weiß heute, ob Go nicht auch in ein paar Jahren wieder zur Niesche wird wie Ruby/Perl. Was die Zukunft und Verbreitung von Java betrifft: Es gibt wohl keine andere Sprache unter Euren Favoriten die eine längere Zukunft haben wird als Java. Die Verbreitung ist wohl bei Java von Euch etwas unterbewertet worden. Vielleicht noch mal überdenken :-) Viele Grüße !

[@thenativeweb]

[gr] javac erstellt aber keine Maschinensprache, sondern Bytecode - und den wiederum kannst Du ohne die JRE nicht ausführen. Insofern zieht das als Argument nicht so richtig, weil die JRE ist ja gerade wieder die Laufzeitumgebung, die wir vermeiden wollen. jpackage kannte ich tatsächlich nicht, interessant, dass sich hier etwas getan hat. Danke für den Hinweis 😊

[@Massenhaft1]

@@thenativeweb Es gibt auch noch graalvm. Wir haben uns für kotlin entschieden, da es auf die Java Backends aufbauen kann und alternativ z.b. mit ktor auch bald nativ gebaut werden kann. Kotlin hat auch eine sehr schöne Syntax :).

[@elalemanpaisa]

boo boo.. luaaaa... das kommt davon wenn man vscode nutzt und nicht neovim :P kleiner spass am rande :) mich haette noch mal mehr eine gegenueberstellung zu TS mit node/oder gar mit deno gefreut. denn aktuell ich nutze nodejs und ueberlege auf deno/TS umzusatteln.. aber dann dachte ich, wieso nciht fuers naechste projekt go nutzen..

[@thenativeweb]

[gr] Naja, ob Du nun JavaScript oder TypeScript mit Node.js machst, ist ziemlich egal - es hat beides die gleichen Vor- und Nachteile der Plattform Node.js, nur dass TypeScript eben nochmals speziell vorkompiliert werden muss. Insofern macht der Vergleich zumindest an der Stelle nicht so extrem viel Sinn, meiner Meinung nach. Aber wenn Dich generell interessiert, ob JavaScript oder TypeScript, dann schau mal hier: kzbin.info/www/bejne/enbWmXyhgs6VqpY

[@elalemanpaisa]

@@thenativeweb danke fuer den link ich schau noch mal rein.. es gibt runtimes die TS native beherrschen, die hattest du allerdings erwaehnt und vielen ja fuer euch raus. ich glaube deno/ts hat allerdings ein besseres oekosystem zzt fuer backend.. aber das projekt geht ganz klar in eine richtung die fuer projekte in der EU schwierig werden. ich werde golang mal bisschen mehr aufmerksam,keit schenken danke dafuer.

[@tarik3958]

Ocaml for the win!

[@thenativeweb]

[gr] Und warum …? Die Verbreitung ist ja vermutlich nicht unbedingt das stärkste Argument für OCaml, oder übersehe ich hier etwas?

[@ZuvielDrama]

Disagree bei 5:50. Die Entwicklung sollte immer in einem Release Environment erzeugen. Das Codeprojekt ist technischer Rahmen und Sourcecode! Also Docker Laufzeitumgebung. Die Docker Environment Files werden über .env Files für Entwicklung und Produktivsystem speziell konfiguriert!

[@felixna4122]

OCaml wäre die bessere Wahl

[@thenativeweb]

[gr] Und warum? Die Verbreitung wird wohl kein Argument sein 😉

[@felixna4122]

@@thenativeweb Es ist eine moderne, wirklich ausgereifte Native-Code Compilersprache die einem hilft Probleme zu lösen und Fehler zu vermeiden. Im Gegensatz zu Go hat OCaml ein ordentliches Typsystem und unterstützt funktionale Programmierung sehr gut ohne dabei so dogmatisch und akademisch wie z.B. Haskell zu sein. Das sind Qualitäten die ich persönlich höher werte als große Verbreitung und schnelle Erlernbarkeit. Go finde ich zu primitiv ist um wirklich hilfreich Probleme zu lösen und effektiv Fehler zu vermeiden. Abgesehen von den Goroutinen und der schnellen Erlernbarkeit hat Go m.M.n. nicht viel was es von den vielen anderen Kandidaten abhebt. Eine verbreitete Sprache mit ähnlichen Qualitäten wie OCaml ist übrigens F#, aber das scheidet bei Euren (für mich absolut nachvollziehbar) wegen Laufzeitumgebung und Hersteller aus.

[@luckyspiff]

Ich hätte bei den aufgezählten Sprachen vermutlich gegen Go und für Rust gestimmt, da ich ein ordentliches Typsystem heute als "must have" sehe und Go hier zu viele Schwächen hat. Go ist zwar sehr einfach, so dass es salopp gesagt an einem Nachmittag gelernt werden kann aber abgesehen davon und von ein paar netten Concurrency-Konzepten hat Go nicht viel zu bieten was man von einer Programmiersprache heute erwarten kann. Ich erwarte von einer Programmiersprache in erster Linie, dass sie mir beim Lösen von Problemen und Vermeiden von Fehlern hilft. Die Lernkurve spielt nur untergeordnet bzw. kurzfristig eine Rolle, da kommt man schließlich rein und im Team verbreitet sich das Wissen schnell wenn das Werkzeug gut ist. Aus dem Grund hätte ich auch lieber Ocaml statt Haskell in Eurer Shortlist gesehen (obwohl ich großer Haskell-Fan bin): Ocaml ist eine Compilersprache mit einem Typsystem ähnlich mächtig wie Haskell aber deutlich pragmatischer und weniger dogmatisch/akademisch, sehr ausgereift und auch für's Web und Cloud geeignet, ich glaube das wäre genau Euer Ding, abgesehen davon dass die Verbreitung eben nicht so hoch ist. Im Prinzip ist Ocaml sehr ähnlich zu F# (dem Juvel der .Net Platform) eine Art "pragmatisches Haskell Light" nur nicht auf der .Net Platform sondern als Native-Code-Compiler.

[@thenativeweb]

[gr] Danke für den Ausflug zu OCaml - das hatten wir tatsächlich nicht auf dem Schirm, klingt aber interessant (auch wenn es von der Verbreitung her wohl tatsächlich nicht in Frage gekommen wäre). Gucke ich mir bei Gelegenheit aber gerne unabhängig von unserer Entscheidung "einfach mal so" an 😊

[@luckyspiff]

@@thenativeweb Gerne! Beim Argument der Verbreitung muss ich an Paul Graham denken, der vor 25 Jahren ein erfolgreiches Startup mit einem Lisp-Produkt gegründet hat. Er sagte sinngemäß, dass das ein gutes Werkzeug wichtiger ist als dessen weite Verbreitung, wo ich ihm voll zustimme. Eine interessante Strategie verfolgt NoRedInk: die setzen (mittlerweile) zur Web-Entwicklung auf ELM (da würde mich Deine Meinung interessieren, das finde ich extrem interessant!). Überraschenderweise haben sie durch diese Entscheidungen keinen Mangel an Entwicklern sondern die Entwickler kommen gerade *wegen* dieser Technologien zu ihnen, so berichtet zumindestens Richard Feldmann z.B. in seinem Bericht "From Rails to Elm and Haskell" (hier auf YT zu finden). Dem Verbreitungs-Argument konnte ich nie viel abgewinnen, sehr häufig habe ich das bei Java(Skript) gehört, sinngemäß herrscht der Glaube vor, dass Java(Skript)-Entwickler auf dem Bäumen wachsen. Die Erfahrung zeigt aber, dass die Komplexität eher in den Frameworks und der jeweiligen Domäne liegt und durch die Entscheidung für Java(Skript) sich viele Antipatterns als Altlasten manifestiert haben, die man mit besseren Sprachen vermeiden hätte können. Aber da spielt wohl auch die "Ich kaufe IBM/Microsoft, dann habe ich nichts falsch gemacht wenn's schief geht"-Denke mit rein... ;-)

[@Polacekad]

Go

[@thenativeweb]

[gr] 😊

[@bretzel30000]

also die sache mit runtime ist meiner meinung nach ein falsches argument. denn die meisten sprachen die eine Runtime erfordern bieten heutzutage die möglichkeit die runtime in eine dicke exe zu bundeln mit dem paylod(der app). Beispielsweise Java vs Go. Weil go hat auch ja auch eine runtime, es hat einen garbage collector. Aber es linkt halt standardmässig immer statisch zu einer big exe wo alles inkludiert ist. Aber bei java ist das auch möglich z.b. spring boot kann man alles was eine java webapp braucht zu einer dicken exe bundeln. und wenn man openjdk verwendet kann man auch das licensing issue umschiffen. Oracle ist böse argument: ja ich stimme zu ich mag oracle auch nicht. Aber es naiv zu glauben das google besser ist. In meinen augen sollte man sich weder an google noch an oracle zu sehr binden. Ich sage nicht das ich java besser finde als go, ich sage nur das die argumente in diesem video nicht gut sind, das ist alles. Ich mag syntax von go lieber als die von java, aber das ist subjektiv.

[@heinrichschiller4673]

Wie kann man nur PHP nicht mögen? Ich bin erschüttert! Ich kann dieses sehr informative und gut gemachte Video nicht ernst nehmen :p Edit: Vermutlich würde ich mich anhand euerer Kriterien auch für Go entscheiden. Sehr wahrscheinlich sogar und euere Gründe klingen für mich überzeugend. Vielleicht schaue ich mir Go auch mal an. Nach JS, Python und C#.

[@thenativeweb]

[gr] Danke für Dein Feedback 😊

[@X39]

Lua ist auch nicht wirklich eine Sprache die man fürs entwickeln von Programmen verwendet Lua ist am Ende des Tages ein appendix für ein Programm, ein Weg um das Programm zu steuern ohne es neu zu kompilieren In meinem Leben (Bekanntenkreis usw.) kenne ich nichts was Lua verwendet als "echte" Software Grundlage

[@thenativeweb]

[gr] Ja, das ist richtig - ich habe Lua nur deshalb als Beispiel gewählt, weil viele "schon mal davon gehört" haben, es aber eben in der Praxis eher selten vorkommt. Am ehesten kenne ich es noch als eingebauten Interpreter in andere Anwendungen, um Anwendungen über Skripte erweitern zu können, aber selbst da kann ich die Fälle, die mir bekannt sind, an einer Hand abzählen. Es ging mir damit eher um das Beispiel an sich als um die konkrete Sprache.

[@devchannel5232]

Die wichtigste aller Sprachen habt ihr vergessen - ArnoldC. Evtl. überdenkt ihr ja nochmal eure Go Entscheidung!

[@thenativeweb]

[gr] Haha 🤣

[@luksch154]

Das Verbreitungs-Argument bzgl. Rust ist mittlerweile meiner Meinung nach hinfällig. Wir haben jetzt Rust im Linux Kernel, Windows Core und schon zu großen Teilen in Android.

[@itsmefrancois6825]

Meiner Meinung nach ist die Überlegung bzw Begründung für einen Wechsel nicht wirklich gut. Runtime + Compiler ist ein gemeinsamer Punkt, weil das eine das andere nach sich zieht. Der Hauptpunkt bei der Runtime war: Die Entwickler haben es "schwerer" zu entwickeln, weil sie mit unterschiedlichen Node Versionen arbeiten müssen. Mit NVM ist sowas schnell und mit Einfachheit handlebar. Entsprechend ist der Punkt für mich schon entkräftet und sehr cherry-picky. Der Punkt mit NPM hat für mich einen gewissen Wert, ist aber letztendlich auch etwas, was man durch simples NPM-Managment und die richtige Wahl von Paketen umgeht. Klar kann man nie wissen, ob wer was in seinen Code einschleust, aber das selbe Problem besteht potenziell auch bei Bibliotheken bei anderen Sprachen. Der Punkt, den ich gar nicht verstehe, warum er überhaupt aufgeführt wurde ist jener, der sich mit der Offenlegung des Codes beschäftigt. Wenn ihr für einen Kunden Code schreibt, sei es jetzt einmal Typescript für ein Backend, dann zahlt dieser Kunde dafür und hat doch sicher auch das Recht diesen einzusehen. Warum spielt es für euch dann eine Rolle diesen zurückzuhalten oder zu verschleiern? Macht für mich wenig Sinn. Insgesamt finde ich diese Punkte, was deren Stärke angeht, ziemlich dürftig. Ich kann sie zwar verstehen, aber für mich würde ein Umstieg niemals dadurch gerechtfertigt werden. Vorallem nicht, weil diese Probleme mit einfachen Lösungen behoben werden können oder teilweise auch gar nicht durch den Umstieg ausgemerzt werden. Der Punkt, den ich jetzt erwartet hätte, wäre eine bessere Performance bei CPU-intensiven Aufgaben. Aber der kam überhaupt nicht vor. Vielleicht könnt ihr auf meine Punkte nochmal eingehen und ggf. meine naive Sicht aufklaren? Danke für das Video!

[@thenativeweb]

[gr] Danke für die ausführliche Nachfrage. Compiler und Runtime ist nicht zwingend ein gemeinsamer Punkt. Es gibt durchaus Sprachen, die werden zwar kompiliert, benötigen aber trotzdem eine zusätzlich installierte Runtime. Spontan fällt mir da zum Beispiel Visual Basic (Classic) ein, oder eben auch .NET und Java, weil hier "nur" in eine Zwischensprache à la MSIL und Bytecode kompiliert wird. Daher macht es durchaus Sinn, diese beiden Punkte getrennt aufzulisten. Der Hauptpunkt bei der Runtime sind nicht die Entwickler:innen, sondern die Anwender:innen beziehungsweise das Deployment. Es genügt eben nicht, die Anwendung zu installieren, sondern man muss auch noch eine Laufzeitumgebung installieren. Und das ist lästig, fehleranfällig, umständlich, und so weiter. Und das betrifft interpretierte Sprachen wie zum Beispiel Python genauso wie JIT-kompilierte Sprachen wie C# und Java. Das mit npm stellst Du Dir IMHO etwas zu einfach vor. Klar kann ich überprüfen, welche Pakete ich selbst installiere - aber was bringen die wiederum als weitere Abhängigkeiten mit? Allein schon nur (!) Express zu installieren führt zu 57 (!) Modulen, die heruntergeladen werden. Wie soll das jemals jemand vernünftig überprüfen oder reviewen - und das auch noch in Anbetracht der Tatsache, dass ständig Updates kommen? Und Du hast Recht, das Problem gibt es an anderer Stelle auch, aber je weniger Abhängigkeiten man hat und je weniger häufig es da Updates gibt, desto stabiler und verlässlicher wird die ganze Sache. Was die Offenlegung angeht: Klar, wenn Du eine Auftragsarbeit für einen Kunden machst, quasi als Teil seiner Entwicklungsabteilung, dann legst Du dem Kunden gegenüber den Code offen. Was aber ist, wenn Du ein Produkt entwickelst, das Du Deinen Kunden anbietest, die Anwendung aber On-Premise und nicht in der Cloud laufen soll? Dann willst Du Deinen Quellcode gerade *nicht* ausliefern, und genau das war der Punkt hier. Hope that helps.

[@ZuvielDrama]

30:00 Full Agree! Bei meiner vorletzten Stelle sollte ich diverse REST Prototypen entwickeln. Bin intuitiv ohne Argumente bei Go gelandet. Mir fehlten Klassen aber es gab Interfaces und ich fing es wirklich an zu lieben! Und dann der Knaller! Auf einmal wird offenbart - deren Rest Like Webframework läuft in C++! Da ich auch C++ Liebe habe ich mich gefreut aber richtig fand es nicht! Also gratulation zu Go! Paßt auch zu deinem Namen! Go ist dein Schicksal! Stell mich ein! Ich will auch Go entwickeln! Ich will 90 % von deinem Gehalt! Peace!

[@cod3r1337]

Ad Java: In meinem Augen gibt es exakt einen einzigen Grund, auf Java zu setzten, dafür aber einen extrem starken, und zwar mit Namen Spring. Die Developer Experience mit Spring Boot sucht einfach ihresgleichen, man arbeitet entlang klarer Leitplanken für jeden nur erdenklichen Anwendungsfall, dabei fühlen sich alle Tools und Libraries aus diesem extrem umfangreichen Ökosystem wie aus einem Guss an. Man hat meistens einen klar vorgegebenen Weg, um ans Ziel zu gelangen, und muss nicht immmer wieder das Rad neu erfinden. Es fühlt sich oft schon mehr wie Legobauen denn als Programmieren an, so sehr passt da ein Baustein in den Anderen. Ja, es erbt Schwächen und Altlasten aus der eigenen sehr langen Historie und noch viel mehr von der von Java selbst, da will ich gar nichts schönreden, aber in Summe überwiegen die Stärken bei Weitem die Schwächen. Der Einwand, dass es eine aufgeblähte Runtime braucht, ist zwar valide, aber ganz aktuell im Begriff obsolet zu werden. Spring Boot 3.0, das in wenigen Wochen released wird, hat nach langen Jahren experimenteller Vorarbeiten endlich vollständige, first class - Unterstützung für Native Images. Nicht als irgendeine externe Erweiterung, sondern als Kernfeature, das direkt in die Standard-Toolchain eingebaut ist. Das ist tatsächlich eined DER Schwerpunktthemen für dieses Release, und einer der Hauptgründe, warum es überhaupt als Major Release deklariert wird. Meiner Meinung nach wird es Java und Spring nicht zuletzt damit gelingen, auch in der modernen Cloud Native - Welt noch für sehr lange Zeit relevant zu bleiben.

[@DogzDeDoggy]

Erstmal klingst Du etwas erkältet, also vorsichtshalber gute Besserung. Als freiberuflicher Informatiker ist meine Auswahl der Sprachen eher von der Verbreitung bei den potentiellen Kunden abhängig. So sind naturgemäß vor allem .net und Typescript hoch im Kurs, aber auch Java, Python oder C++ bzw. immer mehr Rust. Oft gibt es Altlasten, wo ein Rewrite nicht möglich, eine gekapselte Architektur wie zum Beispiel SOA oder Microservice nicht vorliegt oder umfangreiche Bibliotheken in einer gegebenen Sprache vorliegen. Mit der Zeit lernt man Recht gut zwischen den Sprachen zu switchen und bekommt auch ein gutes Gefühl dafür, welche Sprache und welches Umfeld wo gut funktioniert. Ich selbst bin Freunde von "die richtige Sprache für den richtigen Zweck" und konnte eigentlich niemals mit nur einer Sprache leben. So kommen also auch Python, Rust, Go und diverse andere regelmäßig vor. Da sich nicht jeder Entwickler in Umgang mit mehreren Sprachen wohl fühlt, empfehle ich meinen Kunden je nach Größe und Ausrichtung der vorhandenen Teams möglichst wenige Sprachen zu verwenden. In eigenen Projekten nehme ich gerne .net - schlicht deswegen, weil ich mich damit an besten auskenne - und ggf. auf RaspPi oder Controllern auch mal Rust/C++, Go oder bei Apps dann halt Kotlin oder Swift. Im Cloud Umfeld bin ich immer mehr Freund von serverseitigem Webassemblys und im Grunde haben sich serverless Anwendungen aus Basis von AWS Lambda, Azure functions oder OpenFaas und Konsorten bei mir durchgesetzt. Ich schaue dabei das Vendor Lock-in nicht, weil ich stets die "Migrationskosten" im Blick habe und die Anbieter spezifischen Vorteile bei AWS oder gerade Azure entsprechend ausnutzen kann. Aber das sind alles Themen, über die man wieder vortrefflich ganze Abende beim Bier diskutieren kann und die bei mir immer sehr von Kunden abhängen.

[@thenativeweb]

[gr] Danke für Deinen Kommentar - und es stimmt: Vieles hängt auch von Kunden ab, wobei sich da natürlich die Frage stellt: Suchen die Kunden Dich nach Expertise im Bereich X aus, oder machst Du X, weil Deine Kunden das machen, oder bedingt sich das am Ende gegenseitig, oder …? 😉 Und wie sehr so etwas wie genutzte Sprachen schwanken kann, das hängt auch sehr von der eigenen Bubble ab … ich kenne zum Beispiel kaum Projekte mit C/C++, weil es einfach in unserem Umfeld praktisch nicht vorkommt - ein Freund von mir macht aber primär C/C++ und kennt fast nur Projekte, in denen das vorkommt. Da wundern wir uns immer gegenseitig, wie man mit JavaScript beziehungsweise C++ als primäre Sprache genug Aufträge findet 🤣

[@DogzDeDoggy]

@@thenativeweb und darüber hinaus wundere ich mich, wie ich ob meines Alters (51) noch Projekte finde. Also Altersdiskriminierung wäre auch mal ein Thema für euch - also wo/wie/wann man in der Branche zum alten Eisen gehört und wie man dem entgegenwirkt. Diversifizierung des eigenen Könnens gehört sicherlich mit dazu.

[@ZuvielDrama]

28:34 Disagree beim Firefox Argument! Microsoft hat wie Mozilla ihre komplette Produktsparte aufgegeben! Die Marktmacht von Android mit dem offenen Ansatz war einfach zu attraktiv und dominant! Aus wirtschaftlicher Sicht war es das einzig richtige Firefox OS einzustampfen! Dieses Argument gegen RUST lass ich nicht gelten! Da wiegt die Schwierigkeit der Sprache und der Fokus auf Systemnahe Entwicklung stärker!

[@wolfsluytermanvanlangeweyd6741]

Was wählt Golo? Go, logisch 😂

[@thenativeweb]

[gr] Es hätte noch diese Option hier gegeben 🤣 golo-lang.org/

[@Maxpower-h8k]

Golo muss doch Go sprechen..☺️

[@ZuvielDrama]

19:41 Full Ack! Hab bei ner Firma als Flutter Dev angeheuert! Auf einmal sollte ich PHP coden! Die Sprache ist stark verbessert worden! Du kannst aber Instanzvariablen nicht statisch typisieren! Zum Kotzen!