https://de.wikipedia.org/wiki/Go_(Programmiersprache) Habt ihr mit Google GO bereits gearbeitet? Seid ihr damit in Berührung gekommen? Ich habe eine Zeit lang GO angewendet und einige Nebenprojekte damit gemacht, aber ich verwende GO aktuell nicht mehr aktiv. Diese Antwort basiert auf persönlichen Erfahrungen... **Sprachfunktionen:** Go bietet kuratierte, aber begrenzte Sprachfunktionen. Es sieht aus wie eine erweiterte C-Sprache mit einem einfachen Objektsystem. Ich finde nicht, dass Go im Vergleich zu anderen modernen Hochsprachen besonders gut abschneidet. Hier sind einige Punkte: Keine Generika: Viele Gophers versuchen einige Tricks wie leere Schnittstellen oder Codegenerierungsprogramme. Keiner davon stellt mich zufrieden. Keine Vererbung: OO-Code-Basis muss umgestaltet werden. Kein funktionales Überladen Kein Überladen von Operatoren Erzwungener Codestil: Gut für die Technik, aber manchmal zu restriktiv. Keiner der Punkte ist wirklich kritisch, aber manche Programmierer mögen es einfach nicht. **Bibliothek** Das hängt von den Zielanwendungen ab. Für Serveranwendungen ist es wunderbar geeignet. (Google-Anwendungen sind meist webbasiert.) Für andere Bereiche ist es nicht so gut. Zum Beispiel fehlt GO immer noch eine de facto GUI-Bibliothek. **Toolchain** GO bietet eine gute integrierte Toolchain. Es gibt einige Entwicklungswerkzeuge von Drittanbietern; ich bevorzuge integrierte Werkzeuge, wenn möglich. Ich glaube nicht, dass eine moderne Hochsprache ohne eine anständige Toolchain überleben würde. **Anwendung** Go ist gut in einigen Bereichen, aber nicht gut in anderen. Im folgenden einige Punkte: Konsolendienstprogramm: Go ist eine einfache Sprache im Vergleich zu C und C++, also eine gute Alternative für Kommandozeilenprogramme. Die meisten Endbenutzer werden jedoch nicht an CLI-Programmen interessiert sein. GUI-Anwendungen: Google scheint an diesem Bereich nicht interessiert zu sein. Derzeit müssen wir auf Community-Pakete zurückgreifen. Serveranwendungen (z. B. Webanwendungen): Aus diesem Grund hat Google GO(LANG) kreiert. Die Unterstützung ist großartig. Mobile Anwendungen: Go Mobile ist noch experimentell. Zudem ist ja noch "Kotlin" im Spielfeld der Android-Entwicklung unterwegs. Die Zukunft von Go mobile bleibt unklar. (Brauchen wir noch eine weitere Sprache für Android?) Datenanalytik: Nicht so gut. Es gibt einige Community-Pakete. **Fazit:** Obwohl GO eine Allzwecksprache ist, liegt seine Stärke immer noch hauptsächlich bei Serveranwendungen. Zudem: https://winfuture.de/news,121508.html
:
Bearbeitet durch User
Nein, nein. (Das ist jetzt nur meine Antwort auf deine Fragen. Keine Aussagen für oder gegen Go. Es hat sich für mich einfach noch nicht ergeben. Dass Malware-Entwickler diese Sprache verwenden spricht nicht gegen die Sprache. Eher dafür: das ist ein Tätigkeitsfeld, in dem Software vermutlich oft angepasst werden muss und in dem schlechte Software unmittelbar Auswirkungen auf die Einnahmen hat.)
Joe schrieb: > Hier sind einige Punkte ... Ich stimme dir so weit zu. In der Firma wo ich arbeite, hat das Management den Umstieg auf Go beschlossen. Die folgenden Gründe wurden mir genannt: 1) Der Nachwuchs ist Java EE nicht gewachsen, blickt nicht durch. 2) Go Programme belegen in der Cloud wenig CPU und RAM. 3) Python ist zu langsam. Ich stimme diesen Argumenten nur so halb zu, weil: 1) Ist sicher eine Frage, wie viel Geld man fürs Personal ausgeben will. 2) Je mehr Daten verarbeitet und zwischengespeichert werden, umso weniger spielt das eine Rolle. 3) Kann sein, muss nicht. Ich habe langsame und schnelle Python Programme gesehen. Zudem spielt die reiche Rechenleistung oft nur eine untergeordnete Rolle. Unabhängig davon kann ich nach 3 Jahren sagen, dass es für "unsere" Anwendungen (Backend für Web basierte Dienste) weitgehend geeignet ist. Wir haben nur wenige neue Java Programme, die wir mangels passender Bibliotheken nicht in Go schreiben wollten. Ich kann mich auch nicht erinnern, wann wir das letzte mal etwas in Go nicht zufriedenstellend hin bekommen haben. Wenn ich bei einem neuen Projekt die freie Wahl hätte und die folgenden Sprachen im konkreten Fall gleichwertig geeignet wären, dann würde ich sie in dieser Rangfolge bevorzugen: 1) Java, weil ich mich damit am sichersten fühle und am schnellsten arbeiten kann (habe > 20 Jahre Erfahrung mit Java). 2) Go, weil man damit auch flott arbeiten kann und ich es erfrischend finde, mal mit einer anderen Sprache zu arbeiten. 3) C++, weil ich diese Sprache als ebenso vollständig empfinde, wie Java. Zudem mag ich die gute Effizienz der Sprache und dass sie wenig verborgene "Magie" macht. Ich bin in C++ allerdings langsamer und auch fachlich nicht so sicher. 4) Python ist für mich mental immer noch eine Single-Threaded interpretierte Script-Sprache, obwohl ich weiß, das das nicht mehr zwingend so sein muss. An der Syntax stören mich die Einrückungen und dass mir bei einem Objekt oft unklar ist, wann sie welche Methoden und Attribute sie haben (da sich das zur Laufzeit ändern kann. Besonders stark ist mir das bei Odoo aufgefallen). Vorteilhaft finde ich den relativ leichten Einstieg für Anfänger und die weite Verbreitung. Ich denke, dass Python gekommen ist, um zu bleiben, während die alten Klassiker (Cobol, Fortran, Basic, C, C++, Java, Perl) bereits sichtbar aus der Mode kommen.
:
Bearbeitet durch User
Steve van de Grens schrieb: > und die weite Verbreitung. Kommt drauf an wo man sich bewegt. Für mich ist das immer noch ein Exot. > Ich denke, dass Python gekommen ist, um zu bleiben, Jetzt werden schon werbesprüche als Proargumente verkauft. > während die alten Klassiker (Cobol, Fortran, Basic, C, C++, Java, Perl) > bereits sichtbar aus der Mode kommen. Nur interessieren die Bereiche/Anwender die diese Sprachen einsetzen keine "Moden", von ein paar Ausnahmen mal abgesehen: Cobol war nie in Mode, das war für einen bestimmtes Einsatzgebiet der Standard und wird heute noch verwendet, keine Allzwecksprache. Es wurde immer prophezeit dass es durch Java abgelöst wird, ist aber nicht bzw. nur zT passiert. Untergegangen ist es eher mit dem schwinden der Hostssysteme auf denen es vorrangig lief. Und die laufen heute immer noch. Was würde da rumgeschrien das wird alles demnächst ersetzt,... nix ist passiert. Das Zeug läuft heute noch in Banken. Ja auch Java aber das Cobolzeug ist immer noch da, samt Host. Fortran. Auch wieder eine Sprache für eine bestimmte Nische. Wissenschaftliches Rechnen. Keine Ahnung ob das heute noch so populär dort ist manche sagen ja andere nein. Basic. Welches denn? Da gibts 1000 Dialekte davon, manche sind tot wie das Zeug aus dem Heimcomputerumfeld, in Form moderner Dialeke ist es immer noch vorhanden wie VB.NET. C. Das wird nie sterben, das ist immer noch DIE Systemsprache. Alles was irgendwie an andere Sprachen angebunden wird hat ein C-Interface. C++ hat sich mächtig weiterentwickelt mit zeitgemässen Features. Rust soll das mal ablösen und wird es ebensowenig wie andere Sprachen die Ablösung vorausgesagt wurde. C++ ist etabliert hat sich bewiesen und viele Mängel der Vergangenheit abgestellt bzw. sich weiterentwickelt. Java. Really? Selbst wenn die Sprache vielleicht an Bedeutung verlieren wird (Was sie nicht tut, nein Kotlin löst Java nicht ab, auch nicht Scala die davon mal träumten) wird die Platform nie sterben, das ist die State of the Art VM, die Referenzsprache darauf wird immer Java bleiben. Es hies immer "Java ist das Cobol der 90er" und Cobol lebte heute immer noch bzw. Programme die damit entwickelt wurden genauso wird das mit Java bleiben, das kann sich keiner leisten das abzulösen, weil damit noch viel mehr Code produziert wurde als mit Cobol. Perl. Da kann man wirklich einen Rückgang atestieren. Früher mal im Web gross gewesen, schnell abgelöst von PHP. Ne gewisse Zeit lang auch mal als Ablöse für die ganzen Shelldialekte angesehen ist es dann ziemlich implodiert mit ihrem Hickhack um v6, das hat sich grandios selbst weggeschossen.
Immer wieder das selbe. Die etablierten Programmiersprachen sind zu fett geworden. Zu viele Sprachfeatures und zu viele Abstraktionsebenen in den Libraries. Die billigen Kodiersklaven blicken nicht mehr durch. Java hatte vor 20 Jahren die selben Ziele. C++ wurde zu kompliziert. Sun entwickelte eine neue Sprache. Nur das Minimum an Sprachfeatures und Libraries. Heute ist es wieder so weit - die angelernten Scrum Kodierer sind mit den Möglichkeiten, die sich in den 20 ansammelten überfordert. Google fängt mit einer minimalen Sprache wieder neu an.
Xanthippos schrieb: > Die etablierten Programmiersprachen sind zu fett geworden. Zu viele > Sprachfeatures und zu viele Abstraktionsebenen in den Libraries. Bei C? Das kann man auch heute noch so nutzen wie 1990, denn auch heutige Compiler kommen mit C90-Code (damals "ANSI-C" genannt und in der zweiten und letzten Ausgabe des K&R beschrieben) bestens zurecht.
Seit 1990 sind 3 Konzepte hinzugekommen, auf die wir nicht mehr verzichten wollen. Aus der Objektorientierung kommt ein brauchbares Konzept für abgeschlossene Module. Die heutige Hardware hat genug Leistung für eine automatische Garbage Collection. Kein Anwender will mehr warten während eine Sanduhr alle Eingaben blockiert - Wir verteilen die Arbeit auf mehrere Threads. Geht natürlich auch in C90, aber jede Library macht es anders. Komplett neu schreiben geht schneller als Garbage Collection aus mehreren Libraries kombinieren. Das Ziel von Sprachen wie Java oder Go ist ja: Kompakt und einfach wie C90 und zusätzlich diese 3 Features.
> Go bietet kuratierte, aber begrenzte Sprachfunktionen. Es sieht aus wie > eine erweiterte C-Sprache mit einem einfachen Objektsystem. Ich finde > nicht, dass Go im Vergleich zu anderen modernen Hochsprachen besonders > gut abschneidet. Ich haette es als interessanten Ersatz fuer C im Embedded Bereich gesehen, aber mit Garbage Collection geht das natuerlich nicht. Und auf dem PC programmiert man ja mit C++, warum sollte man da noch so eine Bonsaisprache nutzen? Vanye
Xanthippos schrieb: > Aus der Objektorientierung kommt ein brauchbares Konzept für > abgeschlossene Module. Die heutige Hardware hat genug Leistung für eine > automatische Garbage Collection. In welchem Universum hat C eine "garbage Collection"? Und welches "brauchbars Konzept für abgeschlossene Module" magst Du meinen? Xanthippos schrieb: > Wir verteilen die Arbeit auf > mehrere Threads. Welches C bitte mag Threads als Sprachbestandteil kennen? Daß man mit C Threads nutzen kann, ist mir bestens bekannt - ich mach' das seit über 30 Jahren.
> In welchem Universum hat C...
Entschuldigung, da habe ich mich falsch ausgedrückt.
In C musst du dir diese Features irgendwie selbst basteln. Jeder macht
das anders. Für Projekte, die ein dutzend Libraries benutzen, eine
Katastrophe.
Das Ziel von Java und Go ist eine Sprache - minimal und einfach wie C90.
Und zusätzlich ein einheitliches Konzept für Module, GC und
Nebenläufigkeit.
Bei Java ist das in den 20 Jahren komplett aus dem Ruder gelaufen.
Inzwischen ist Java EE für billige Scrum Kodierer zu umfangreich.
Jetzt versucht Google mit Go das selbe noch mal.
Xanthippos schrieb: > In C musst du dir diese Features irgendwie selbst basteln. Da man keine "garbage collection" braucht, muss man auch nichts basteln. Threads kann das Betriebssystem zur Verfügung stellen, da muss man auch nichts basteln.
Xanthippos schrieb: > Das Ziel von Java und Go ist eine Sprache Java scheinen "die Arduinos" am PC zu sein: Irgedwelche Klassen zusammenkopieren und nicht verstehen, was sie da wirklich treiben.
> und nicht verstehen, was sie da wirklich treiben.
Das ist wesentlich katastrophaler. Die packen zwei dutzend
Abstraktionsebenen über die Klassen, die sie nicht verstehen. Bei
Fehlern und Sicherheitslücken blickt keiner mehr durch, welche Ebenen
gefixt werden müssen. Packen noch eine Ebene mit irgend einem nicht
funktionierenden Workaround drauf.
Zurück zu Go. Da sich Java EE nicht mehr reparieren lässt, versucht
Google das selbe noch mal mit einer komplett neuen Sprache.
Was Joe als Nachteile empfindet, sind für die Projektleiter Vorteile.
Sie können teure fähige Entwickler durch die billigsten Mausklicker
ersetzen.
Xanthippos schrieb: > Das Ziel von Java und Go ist eine Sprache - minimal und einfach wie C90. > Und zusätzlich ein einheitliches Konzept für Module, GC und > Nebenläufigkeit. > > Bei Java ist das in den 20 Jahren komplett aus dem Ruder gelaufen. Was wohl auch daran liegt, daß „minimal und einfach wie C90“ niemals das Ziel von Java war. Das war von Anfang an objektorientiert, plattformunabhängig, und auch sonst als eierlegende Wollmilchsau konzipiert. Mit der „Einfachheit“ von C90 hat das noch nie auch nur irgend etwas zu tun gehabt. Oliver
:
Bearbeitet durch User
Xanthippos schrieb: > Bei Java ist das in den 20 Jahren komplett aus dem Ruder gelaufen. Ich finde Java immer noch ziemlich gut, nur der Turm (zu Babel) von Libraries bereitet mir sorgen. Wenn dich jemand Fragt, ob du in Java programmieren kannst, dann meint er damit nicht die Sprache, sondern ob du die ganzen Libraries und Frameworks beherrschst, die er dabei gerade im Sinn hat. Das wäre, also ob ich jemanden Frage > Kennst du dich mit Elektronik aus? , um nach der Zustimmung auf > Prima, dann kannst du ja mal eben schnell die Steuerung meiner > Lagerhaltung auf neue Roboter umstellen zu kommen.
:
Bearbeitet durch User
> Was Joe als Nachteile empfindet, sind für die Projektleiter Vorteile. > Sie können teure fähige Entwickler durch die billigsten Mausklicker > ersetzen. Das ist genau mein Verdacht wieso wir in letzter Zeit wieder so eine "bluete" neuer Sprachen erleben. Vor allem wenn sie von Firmen wie Google promotet werden. Gute Programmierer sind teuer, schlechte sind noch teurer wegen dem Schaden den sie anrichten. Da wuerde eine einfachere Sprache es erlauben Geld zu sparen. Vanye
Vanye R. schrieb: > Da wuerde eine einfachere Sprache es erlauben Geld zu sparen. Google hat halt sein Geschäft vollständig verstanden… Oliver
Xanthippos schrieb: > Entschuldigung, da habe ich mich falsch ausgedrückt. Du musst dich für nichts entschuldigen. Ich hab dich verstanden, die meisten anderen wohl auch. Der Grantler von Kirnbichler wollte dich entweder nicht verstehen oder ist wieder auf Krawall gebürstet.
:
Bearbeitet durch User
Harald K. schrieb: > Xanthippos schrieb: >> In C musst du dir diese Features irgendwie selbst basteln. > > Da man keine "garbage collection" braucht, muss man auch nichts basteln. > Threads kann das Betriebssystem zur Verfügung stellen, da muss man auch > nichts basteln. Die 3 Konzepte die Xanthippos genannt hat existieren nativ in C nicht. Da es aber für jedes davon diverse Implementierungen gibt scheint es grundsätzlich Bedarf dafür zu geben, egal ob du diesen Bedarf teilst oder nicht. Ein rausgerotztes "braucht man nicht" zeugt jedenfall nicht von großem Horizont.
Le X. schrieb: > Ein rausgerotztes "braucht man nicht" zeugt jedenfall nicht > von großem Horizont. Vielleicht zeugt ja auch Deine "hat schon mal jemand gemacht, also wird es gebraucht"-These nicht von großem Horizont. Wenn Du nur Software schreiben kannst, in der Du Deinen Müll überall herumliegen lässt, und wenn es Dich überfordert, Dich mit der API des jeweils genutzten Betriebssystems zu beschäftigen, dann ist möglicherweise auch Dein Horizont eher die Innenseite einer Suppentasse. Wer meint, Erfahrung durch ständig Programmiersprachen ersetzen zu müssen, der bastelt munter am Babelturm, der sich schon wie das Mycel durch den Misthaufen durch all' die Frameworks und Libraries zieht, ohne den man bei Java & Co. nicht überleben kann, und der in Form von jetzt dann auch ständig neuen und anderen Namen in aktuell angesagten Universalproblemlösungsprogrammiersprachen als "Paketmanager" integriert wird - wie z.B. die "crates" von Rust. Kann so ein Zeitgeistprogrammiersprachenanwender denn fünf Jahre alten Code überhaupt noch verstehen, oder gar zehn Jahre alten Code? Kann er den aus Libraries, Frameworks, "crates" und anderen Paketen zusammengesetzten Code mitsamt der beliebten "Abhängigkeiten" denn überhaupt verstehen?
Harald K. schrieb: > Welches C bitte mag Threads als Sprachbestandteil kennen? C11 https://en.cppreference.com/w/c/thread
Kann man das auch "bare metal" nutzen und hat dann Threads? Oder ist das letztlich nur eine Verpackung für die vom Betriebssystem zur Verfügung gestellten Threads?
Harald K. schrieb: > Oder ist das > letztlich nur eine Verpackung für die vom Betriebssystem zur Verfügung > gestellten Threads? Wie deine ganz persönliche bare-metall-libc das macht, kannst nur du selber wissen. Die libc's von üblichen Implementierungen auf Betriebssystemen werden wohl die threads vom Betriebsystem nutzen. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Die libc's von üblichen Implementierungen auf Betriebssystemen werden > wohl die threads vom Betriebsystem nutzen. Hmmm, also ich muss da noch ›libpthread‹ explizit dazu linken.
1 | ~/tmp$ gcc -Wall -Wextra -pedantic -std=c11 -Os -o "x" "x.c" |
2 | /usr/bin/ld: /tmp/ccDAsqw7.o: in function `main': |
3 | x.c:(.text.startup+0x13): undefined reference to `thrd_create' |
4 | collect2: error: ld returned 1 exit status |
5 | ~/tmp$ gcc -Wall -Wextra -pedantic -std=c11 -Os -o "x" "x.c" -lpthread |
6 | ~/tmp$ file x |
7 | x: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8740b9522815e98a38211047c1a3024749812538, for GNU/Linux 3.2.0, not stripped |
8 | ~/tmp$ |
Norbert schrieb: > Hmmm, also ich muss da noch ›libpthread‹ explizit dazu linken. Nun ja, nur weil gcc die "libc" auf mehrere libs verteilt, ändert das nichts an der Aussage. Zudem: https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread Oliver
Interessantes Lesematerial, Danke. Habe bis jetzt immer nur libc als libc angesehen, alles andere als zusätzliche Bibliotheken.
Als C/C++ Entwickler finde ich die Sprache höchst merkwürdig und denke,
man kann alles sauber und platformunabhängig mit C++/STL abbilden.
Vor allem geht es mir nicht in den Kopf, warum man eine
nicht-objektorientierte Sprache entwickelt, in welche man OOP Features
integriert ohne OOP Features zu integrieren.
Es gibt struct (alles public, so weit so gut und simpel), schachtelbar,
ohne Member. Member Functions werden mittels "binding" an ein struct
gebunden (capture argument vor FuncName). Und dieses mysteriöse "Init()"
als Modul-Konstruktor. Ich frage mich, warum man nicht einfach struct
(alles public) mit Membern, Konstruktor, Destruktor gebaut hat?
Die angepriesene Parallelität ist genauso komplex in der Verwendung wie
in anderen Sprachen auch.
Dann die merkwürdig anmutende Klammersetzung. Ok, hier zwingt man den
Entwickler zu { ... }, um merge-Fehler auszuschließen.
Was mir sehr gefällt ist das Konzept mit "defer".
Ansonsten scheint es eine Sprache zu sein, damit "script-Schreiber" ein
Executable erstellen können. Für Mini-Commandlinetools sicherlich
geeignet, bevor man C/C++ lernt ...
:
Bearbeitet durch User
Random .. schrieb: > Als C/C++ Entwickler finde ich die Sprache höchst merkwürdig Allerdings, sehe ich auch so. > Und dieses mysteriöse "Init()" als Modul-Konstruktor. Habe noch nicht herausgefunden, wozu das gut ist. Damit verbirgt man eher den Ablauf des Programmstarts, was völlig am Sinn von Go vorbei geht. In Go gibt es auch keinen formellen Konstruktor für Klassen. Da ein Äquivalent dazu aber oft gebraucht wird, nennen "wir" (in meiner Firma) solche Funktionen immer NewWhatever() und die Funktion liefert Whatever zurück. > Ich frage mich, warum man nicht einfach struct > (alles public) mit Membern, Konstruktor, Destruktor gebaut hat? Meine Vermutung: Weil das dann zu nahe an C++ gewesen wäre, dann hätten wohl noch mehr Leute die Existenzberechtigung der Sprache Go in Frage gestellt. Ich meine, man hätte analog zu Arduino eine abgespeckte Variante von C++ erfinden können (gerne mit Garbage Collector).
:
Bearbeitet durch User
> Ansonsten scheint es eine Sprache zu sein, damit "script-Schreiber" ein > Executable erstellen können. Wahrscheinlich will Google genau das erreichen. Aber es funktioniert nicht. Bis 2000 herum konnten 2-3 fähige Programmierer ein komplettes Programm entwickeln. Jeder überblickte alle Probleme und alle Entscheidungen. Geht nicht mehr, die Programme sind zu umfangreich geworden. Man würde 10-20 fähige Programmierer brauchen. Da kann nicht mehr jeder alles überblicken. Und natürlich gibt es nicht genug fähige Entwickler. Statt 10-20 fähige Programmierer müssen die Firmen 100-200 Mausschubser einstellen. Grundidee von Java oder Go: Die Sprache so einfach machen, dass wieder jeder alles überblickt. An Java haben wir gesehen, das klappt nicht. Die Libraries wurden zu umfangreich. Die 2 Dutzend Abstraktionsebenen überblickt niemand mehr. Vielleicht müssen wir Softwareentwicklung wie Maschinenbau oder Bauwesen organisieren. Die eine Firma kann nur Baugruben ausheben. Die nächste nur Betonschalung bauen. Die dritte nur Beton liefern... Und in jeder Firma gibt es zig Spezialisten, die nur einen kleinen Teilbereich überblicken. Im Bauwesen kommt niemand auf die Idee: Spezialisten für Schiebekarre und Maurerkelle sollen in Scrum-Events den Job der Architekten und Ingenieure mit erledigen. Und die teuren Ingenieure lässt man nicht Schiebekarre fahren. Nur in der Programmierung - da tippen die Architekten Programmcode ein während die Knalltüten die Architektur zerschreddern.
Xanthippos schrieb: > Bis 2000 herum konnten 2-3 fähige Programmierer ein komplettes Programm > entwickeln. Jeder überblickte alle Probleme und alle Entscheidungen. > Geht nicht mehr, die Programme sind zu umfangreich geworden. Man würde > 10-20 fähige Programmierer brauchen. Da kann nicht mehr jeder alles > überblicken. Was ist "ein komplettes Programm"?
> Was ist "ein komplettes Programm"?
Ein extremes Beispiel wären Doom und Quake. Heutzutage braucht man für
so ein Spiel das Budget eines Hollywoodfilmes. Und 1000 Leute.
Oder Mysql. In den 90ern konnten 2 Leute ein konkurrenzfähiges DBMS
entwickeln.
Wenn du weiter zurück gehst. Das Visicalc hatten 2 Leute geschrieben.
Für MS Office braucht es tausende von Programmieren.
Ganz egal, wie einfach Go ist - Heutzutage können nicht mehr 2 geniale
Entwickler eine konkurrenzfähige Tabellenkalkulation entwickeln.
> Vielleicht müssen wir Softwareentwicklung wie Maschinenbau oder Bauwesen > organisieren. Die eine Firma kann nur Baugruben ausheben. Das ist im Grunde das was passiert wenn jemand eine Library des Systems, der Entwicklungsumgebung oder irgendwo aus dem Internet benutzt. Das Problem ist nur, vor allem unter Linux, das es einen unglaubliche Zoo an unterschiedlichen Librarys in unterschiedlichen Versionsstaenden und gerne auch mal mehrere unterschiedliche fuer eine Aufgabe gibt. Was fehlt ist letztlich eine harte Hand die das harmonisiert und ein Programmierstil der dafuer sorgt das alles was daruber hinaus geht immer statisch ins Programm gelinkt wird. Damit koennte man vieles verbessern aber nicht alles denn: > Bis 2000 herum konnten 2-3 fähige Programmierer ein komplettes Programm > entwickeln. ...das hier ist letztlich das Problem, oder halt das man sich darueber hinaus entwickelt hat. Programme sind so komplex geworden das es schwer wird das zu durchschauen. Aber wuerde man da eine Loesung finden, wuerden die Programme danach noch komplexer werden... Menschen sind einfach so. Was man anstrebt, sich aber wohl noch nicht recht durchgesetzt hat ist eine Unterteilung in Programmierer in 1. und 2. Klasse. Also fuer eher einfache banale Aufgaben dann weniger kompetente Leute einzusetzen. Da kommt die Idee zu Go her. Allerdings gibt es da noch einen Haken. Ab einem gewissen Level ist Programmieren kein Selbstzweck sondern wirklich nur eine Sprache die man drauf haben muss um das eigentliche Problem zu loesen. Man muss also ausserdem im dem Fachgebiet in dem man arbeitet Fachwissen haben. Du findest oft sehr gute Spezialisten, sagen wir mal Physik oder sowas die aber nicht automatisch gute Programmierer sind. Du kannst solchen Leuten nicht mal eben einen C++ Compiler geben und nett auf die Schulter klopfen. Das erklaert die interessante Verbreitung von Python in den letzten Jahren. Aber der besondere Murks an Go ist natuerlich der Name der Sprache. Mir wuerde kein Weg einfallen die Verbreitung eine Sprache staerker zu behindern als die Suche nach Information darueber zu erschweren. Was sagt uns das ueber die Entwickler davon? Vanye
Xanthippos schrieb: > Grundidee von Java oder Go: Die Sprache so einfach machen, dass wieder > jeder alles überblickt. An Java haben wir gesehen, das klappt nicht. > The key point here is our programmers are Googlers, they're not researchers. > They're typically, fairly young, fresh out of school, probably learned Java, > maybe learned C or C++, probably learned Python. They're not capable of > understanding a brilliant language but we want to use them to build good > software. So, the language that we give them has to be easy for them to > understand and easy to adopt...Go has indeed become the language of cloud > infrastructure. Rob Pike, Entwickler bei Google und Co-Autor von Go. Also ja, offenbar war das die Grundidee. Ich denke jedoch, dass die Programmiersprache (egal welche) nicht das Problem ist. Die Struktur und Funktionsweise einer Anwendung zu verstehen, erfordert in meinem Umfeld Monate. Gut zu programmieren erfordert Jahre an Erfahrung. Daran kann keine Programmiersprache etwas wesentlich ändern.
Vanye R. schrieb: > Aber der besondere Murks an Go ist natuerlich der Name der Sprache. > Mir wuerde kein Weg einfallen die Verbreitung eine Sprache staerker > zu behindern als die Suche nach Information darueber zu erschweren. Darum hat sich für die Suche auch "golang" eingebürgert.
Xanthippos schrieb: > An Java haben wir gesehen, das klappt nicht. Die > Libraries wurden zu umfangreich. Du vermischst Sprache mit Libraries. Wenn ich in irgendeiner anderen Sprache ähnlich komplexe Programme wie unter Java schreiben will brauche ich dort auch einen Zoo an Libs, das schenkt sich nix.
:
Bearbeitet durch User
> Du findest oft sehr gute Spezialisten, sagen wir mal Physik oder sowas > die aber nicht automatisch gute Programmierer sind. ... > Das erklaert die interessante Verbreitung von Python in den letzten Jahren. Stimmt, das versuchen wir. Aber es funktioniert nicht mehr. Ganz egal, wie einfach die Sprache ist, heutzutage ist ein Spezialist mit seinem Fachgebiet ausgelastet. Er kann nicht mehr nebenbei lernen, wie man Programmcode eintippt. Oder wie man Modulstrukturen anlegt. Im Maschinenbau und im Bauwesen haben wir das selbe Problem. Die mittelalterlichen Steinmetze konnten für die Kathedralen noch alles selbst entwerfen und auch bauen. Heutzutage kann ein Architekt weder Statik noch Wärmeschutznachweis selbst erstellen. Eine Betonpumpe bedienen erst recht nicht. Softwareentwicklung ist das letzte mittelalterliche Handwerk. Programmierer arbeiten immer noch wie mittelalterliche Steinmetze, die von der Ästhetik über die Statik bis zum Steine klopfen alles beherrschten. > Aber wuerde man da eine Loesung finden, wuerden die Programme > danach noch komplexer werden... Menschen sind einfach so. In allen Bereichen außer der Softwareentwicklung gibt es eine Lösung, die aber kein Mensch so wirklich haben will. Die einen machen nur kreative Arbeiten. Die anderen machen nur Berechnungen. Die nächste Abteilung macht nur Terminplanung. Noch andere machen nur stupide Fließbandarbeit... Aber wir wollen halt unsere eigenen Ideen selbst ausprobieren. Wir wollen weder Ideen erfinden, die andere ausarbeiten, noch wollen wir die Ideen anderer Leute eintippen. Mit Go wollen Pike, Thompson und Griesemer den Umbruch vom mittelalterlichem Handwerk zur industriellen Produktion verhindern.
> Softwareentwicklung ist das letzte mittelalterliche Handwerk.
Jedesmal wenn ich an einer Hausbaustelle vorbeikomme, sehe wieviele
Menschen da rum laufen und mir klar mache das sowas
selbstverstaendliches
wie ein Haus nicht von jedem in unserer Gesellschaft finanzierbar ist,
dann weiss ich das dieser Satz falsch sein muss. .-)
Ich hab eher den Eindruck als wenn man der Softwareentwicklung mal
mit einem sehr harten Tritt in den Hintern beibringen muss das jedes
Programm irgendwann man fertig zu sein hat um es dann viele Jahre zu
nutzen. Das koennten Programmierer vom mittelalterlichen
Handwerk noch lernen! Tatsaechlich wollen diese Beutelschneider
mittlerweile das man ihnen regelmaessig Geld ueberweisst!
Wuerde man so diese Zunft auf Vordermann bringen haetten sie
danach vermutlich wieder genug Leute um ihre uebrige Arbeit
richtig zutun.
Und vielleicht muss sich die Softwareentwicklung auch mal
eingestehen das manches nicht leistbar ist. Ich hab jedenfalls
mittlerweile oft den Eindruck das weniger mehr waere.
Vanye
Vanye R. schrieb: > wie ein Haus nicht von jedem in unserer Gesellschaft finanzierbar ist, eine Bekannte lässt gerade ihr Bad und ihr WC neu machen: 40.000,- EUR. Nennt mich kleinlich, aber ich wüsste nicht, wie ich da 40.000,- EUR verbrennen könnte. Ich schau mir mal bei Gelegenheit den KV bzw. die Rechnung an. Das interessiert mich schon brennend. Bin ja fast vom Stuhl gefallen, als ich diese Summe hörte. Aber es ist halt vermutlich so: Das Badezimmer ist die neue Küche ;-) ciao Marci
Vanye R. schrieb: > Jedesmal wenn ich an einer Hausbaustelle vorbeikomme, wunder ich mich, dass da tatsächlich ein "funktionierendes" Gebäude entstehen kann, so wie da teilweise rumgemurkst wird. Zumindest bis der Keller komplett fertig ist würde ich da jeden Tag einen Gutachter auf die Baustelle schicken. Alles oberhalb kann man auch später irgend wie fixen. Wenn mit der Bodenplatte oder dem Keller was nicht stimmt, wird es meist sehr teuer oder schwierig... ciao Marci
Vanye R. schrieb: > Ich hab eher den Eindruck als wenn man der Softwareentwicklung mal > mit einem sehr harten Tritt in den Hintern beibringen muss das jedes > Programm irgendwann man fertig zu sein hat um es dann viele Jahre zu > nutzen. Du meinst die, die den Kölner Dom gebaut haben? Oliver
Marci W. schrieb: > Zumindest bis der Keller komplett fertig ist würde ich da > jeden Tag einen Gutachter auf die Baustelle schicken. Hat mein Vater bei seinem Haus so gemacht, und es war später das einzige in der Reihe, wo später kein Wasser durch Ritzen eindrang.
Steve van de Grens schrieb: > Hat mein Vater bei seinem Haus so gemacht, und es war später das einzige > in der Reihe, wo später kein Wasser durch Ritzen eindrang. Heute reicht das Geld nicht mehr für einen Keller. Im Neubaugebiet nebenan haben die wenigsten Häuser einen Keller. Die Gärten sind winzige Rasenfetzen die man mit einer Nagelschere schneller gemäht hat als der Mähroboter.
:
Bearbeitet durch User
> Nennt mich kleinlich, aber ich wüsste nicht, wie ich da 40.000,- EUR > verbrennen könnte. Tja, im Bauwesen haben wir das gegenteilige Problem. Zu viele Bürokraten und zu viele Vorschriften. Auf jeden, der arbeitet kommen ein Dutzend Bürokraten, die widersinnige Vorschriften erfinden. Oder die Einhaltung widersinniger Vorschriften kontrollieren. Und ein Dutzend Juristen. Da ein paar Bauherren "Schadensersatz" für nicht eingehaltene Vorschriften einklagen, versuchen Architekten und Baufirmen alle widersinnigen Vorschriften einzuhalten. Die Bauarbeiter haben aufgegeben. Machen halt, was auf dem Plan steht, ganz egal ob es sinnvoll ist. Vielleicht sollten wir mit der Softwareentwicklung einfach so weiter machen. Ein Dutzend engagierte Scrum Kodierer bringen immer noch mehr zustande, als ein Dutzend Bürokraten und Juristen. >> Zumindest bis der Keller komplett fertig ist würde ich da >> jeden Tag einen Gutachter auf die Baustelle schicken. > Hat mein Vater bei seinem Haus so gemacht, und es war später das einzige > in der Reihe, wo später kein Wasser durch Ritzen eindrang. Typisch - bei jedem Bau werden alle unsinnigen Vorschriften eingehalten. Macht den Bau nur unnötig teuer. Aber in einer Siedlung, in der wirklich Probleme auftreten, machen die Baufirmen auch nur die Standardabdichtung. Die Sicherheitslücken in unserer Software entstehen, weil jeder Programmierer alles macht. Nicht genug von Sicherheitslücken versteht. Aber im Bauwesen ist das was anderes. Da arbeiten fähige Spezialisten und es gibt funktioniere Lösungen. Aber am Bau wollen die Leute nur mehr alle widersinnigen Vorschriften einhalten. Ob da was sinnvolles bei raus kommt, interessiert niemanden mehr.
Ach, ich mag Golang. Es hat seine Stärken IMHO vor allem bei der Entwicklung von kleinen Webservices, Forward und Reverse Proxies, die hohen Anforderungen an ihre Performance genügen müssen. Auch für Kommandozeilenwerkzeuge, die dann als statische Binaries sehr einfach auf unterschiedlichen Plattformen deployt werden können, ist Golang eine hervorragende Wahl. Für große Applikationen ist Golang zwar ebenfalls brauchbar, aufgrund der... sagen wir, etwas beschnittenen objektorientierten Features wird der Aufwand für die strukturelle Planung und Implementierung aber schnell recht groß, und dann frißt dieser Aufwand IMHO oft die Benefits der einfachen Sprache auf.
> sagen wir, etwas beschnittenen objektorientierten Features Genau das war doch der entscheidende Anlass für diese neue Sprache. > They're not capable of > understanding a brilliant language but we want to use them to build good > software. Pike, Thompson und Griesemer haben da ein paar Kleinigkeiten übersehen. Kodierung ist die einfachste Teilaufgabe. Entwickler müssen alle widersprüchlichen Anforderungen unter einen Hut bringen und eine erweiterbare Modulstruktur ausarbeiten. Und dann noch tausende von Detailprobleme berücksichtigen. Wer schon Probleme mit Vererbung und Generika hat, bringt die anderen Punkte erst recht nicht auf die Reihe. Nach meiner Meinung ist die Frage: Kann das, was Go versucht überhaupt funktionieren, oder müssen wir die Arbeitsteilung aus dem Maschinenbau übernehmen?
Xanthippos schrieb: > Pike, Thompson und Griesemer haben da ein paar Kleinigkeiten übersehen. > Kodierung ist die einfachste Teilaufgabe. Entwickler müssen alle > widersprüchlichen Anforderungen unter einen Hut bringen und eine > erweiterbare Modulstruktur ausarbeiten. Und dann noch tausende von > Detailprobleme berücksichtigen. Wer schon Probleme mit Vererbung und > Generika hat, bringt die anderen Punkte erst recht nicht auf die Reihe. Du übersiehst, daß die Komplexitäten nicht "linear" aufeinander aufbauen, sondern daß sie sich letztlich quasi aufsummieren. Wer man sich mal ansieht, wie komplex beispielsweise C++ heute ist, stellt schnell fest, daß es dabei nicht nur um "Vererbung und Generika", sondern um mehr geht. Viel mehr. Und zudem ist es doch so, daß gerade die Vererbung eines der meistmißbrauchten Features vieler Sprachen ist, und die Komposition -- die Golang anbietet -- häufig eine wesentlich elegantere Lösung bietet. Mit Deinem hochnäsigen "wenn sie das nicht können, sind sie halt zu doof" kommst Du deswegen am Ende nicht weiter, fürchte ich. Selbst wenn sie zu doof wären -- was ich ausdrücklich bezweifle --, wirst Du als jemand, der Sachen erledigt und funktionierende, wartbare Software aus der Türe bekommen will, mit Deinem herablassenden Ansatz nicht allzu weit kommen. Denn auch Giganten wie Google & Co. können nur mit den Entwicklern arbeiten, die sie bekommen, und allwissende Superdupergenies Deines Schlages gibt es leider selten.
> Mit Deinem hochnäsigen "wenn sie das nicht können, sind sie halt zu > doof" kommst Du deswegen am Ende nicht weiter, fürchte ich. Selbst wenn du bei Amazon Entwickler kaufen koenntest die n-klug sind wuerde das nicht reichen weil die danach Projekte schaffen fuer die man n+1 Klugheit braucht. Das ist so eine typisch Menschliche Eigenschaft. Wir wollen uns ja nicht langweilen. Das Problem ist nur. Wir haben derzeit viele Entwickler die haben ihr ganzes Berufsleben nur gelernt und praktisch die aktuelle Technik/Systeme/Programmierumgebungen mit aufgebaut und fingen 1980 bei 0 an. Der Nachwuchs faengt aber bei 0 an, soll aber auf dem aufbauen und fortschreitend besseres entwickeln ohne die Grundlagen 40Jahre lang gelernt zu haben. Das ist schon ein gewisses Problem. Vanye
> Denn auch Giganten wie Google & Co. können nur mit den > Entwicklern arbeiten, die sie bekommen Ist klar. Außerdem könnte heutzutage nicht mal ein Genie wie Steve Wozniak oder John Carmack ein konkurrenzfähiges Programm entwickeln. Tesla oder BYD können auch nur mit den Entwicklern arbeiten, die sie bekommen. Stell dir mal vor, die lassen ihre Autos von unerfahrenen Scrum Teams entwickeln. Crashtest im Prüfinstitut lassen die auch weg. Außerhalb der Softwareentwicklung hat sich ein ganz anderes Konzept durchgesetzt. Jeder lernt nur das, was er für sein kleines Teilgebiet braucht. Der eine lernt nur, wie man Anforderungslisten ausarbeitet. Der andere lernt nur, wie man Terminplanung macht. Der dritte lernt nur, wie man ein Tonmodell glatt streicht... Bis 2000 rum war unsere Vorgehensweise in der Softwareentwicklung durchaus sinnvoll. Als wir noch in Kilobytes und Kiloherz rechneten, musste alles aus einem Guss sein. Der Entwickler musste entscheiden, ob er Anforderungen weglässt oder mehr Zeit ind die Low-Level Optimierungen steckt. Da musste ein Entwickler alle Bereiche von den Anforderungslisten über die Terminplanung bis zur Bitfummelei beherrschen. Habe den Eindruck, diese Zeiten sind vorbei. Heutzutage brauchen wir auch in der Softwareentwicklung Spezialisten für Anforderungslisten, Modulstrukturen, Bitfummelei... und für jede kleine Teilaufgabe eine jahrelange Ausbildung. Mit Hilfe von Vererbung und Generika eine erweiterbare Modulstruktur ausarbeiten ist ein eigener Beruf. Kann man nicht nebenbei machen. Die einen Spezialisten arbeiten die Interfaces aus. Die anderen Spezialisten tippen den Programmcode ein. > "wenn sie das nicht können, sind sie halt zu doof" Ein interessanter Punkt. In unserer Kultur sagen wir: Ein Baggerfahrer ist für die Arbeit eines Architekten zu doof. Nicht aber, ein Architekt ist für die Arbeit eines Baggerfahrers zu doof. Warum eigentlich?
> Wir haben derzeit viele Entwickler die haben > ihr ganzes Berufsleben nur gelernt und praktisch die aktuelle > Technik/Systeme/Programmierumgebungen mit aufgebaut Nicht wirklich. Unsere Programme sind uns über den Kopf gewachsen. In den 80ern hatten wir Methoden gelernt, mit denen wir ein nützliches Programm in 64 Kilobyte quetschen konnten. Seit wir in Gigabyte rechnen funktionieren diese Methoden nicht mehr. Es gab ein paar Ideen, wie wir die Softwareentwicklung gewaltig vereinfachten. Hochsprachen, Personal Computer, Objektorientierung. Habe den Verdacht, hinter Go steckt die selbe Idee. Die Softwareentwicklung wieder so weit vereinfachten, dass die alten Methoden weiterhin funktionierten. Die heutigen Softwareentwickler wollen auch diese 40 Jahre alten Methoden übernehmen. Die wollen auch von der Erfindung bis zum Freigabetest alles selbst machen. Aber bei den heutigen Anforderungen kann ein Mensch nicht mehr alles überblicken.
Vanye R. schrieb: > Selbst wenn du bei Amazon Entwickler kaufen koenntest die n-klug > sind wuerde das nicht reichen weil die danach Projekte schaffen > fuer die man n+1 Klugheit braucht. Ja, natürlich, und das... > Der Nachwuchs faengt aber bei 0 an, soll aber auf dem aufbauen > und fortschreitend besseres entwickeln ohne die Grundlagen 40Jahre > lang gelernt zu haben. ... sind ebenso richtige wie kluge Gedanken. > Das ist schon ein gewisses Problem. Nunja, existierende und etablierte Technologien tendieren leider selten dazu, einfacher zu werden. Okay, OpenSSL und Sendmail vielleicht, als für OpenSSL eine Art Wrapper um die vermurkste API und für Sendmail M4 zur Erzeugung der vermaledeiten Konfigurationssyntax bereitgestellt wurden, aber die haben die Leute dann -- wie Du sehr richtig anmerkst -- dann wieder dazu benutzt, um noch komplexere Sachen damit zu machen... Das ist der Lauf der Dinge. Google versucht mit Golang einen Rückschritt, und an manchen Stellen gelingt der dann auch wie gewünscht. Aber Softwareentwicklung ist eine komplizierte Angelegenheit -- und einen Teil dieser Kompliziertheit können Werkzeuge nur teilweise auffangen... höchstens.
Xanthippos schrieb: > Außerhalb der Softwareentwicklung hat sich ein ganz anderes Konzept > durchgesetzt. Jeder lernt nur das, was er für sein kleines Teilgebiet > braucht. Der eine lernt nur, wie man Anforderungslisten ausarbeitet. Es gibt einen Fachausdruck dafür, das nennt sich Arbeitsteilung. Die gibt es an vielen Stellen auch längst schon in der Softwareentwicklung: hier gibt es den Frontend-, den Backend- und den Datenbankentwickler, zusätzlich meistens einen, der sich um Automatisierungen kümmert, ... Wovon redest Du also?
Xanthippos schrieb: > Nicht wirklich. Unsere Programme sind uns über den Kopf gewachsen. In > den 80ern hatten wir Methoden gelernt, mit denen wir ein nützliches > Programm in 64 Kilobyte quetschen konnten. Seit wir in Gigabyte rechnen > funktionieren diese Methoden nicht mehr. Langsam gewinne ich den Eindruck, daß Du seit Deiner Zeit mit dem Commodore 64 nicht mehr viel mit Softwareentwicklung zu tun hattest. Deine 64k-Programme konnten nämlich nicht mehr als ein Megabyte an Daten verarbeiten, auf einer Maschine mit einem Singlecore-Prozessor. Die Programme von heute verarbeiten Terabyte an Daten auf modernen Multicores, hochparallelen GPUs und womöglich sogar einem Computecluster, und die Anforderungen steigen weiter.
Marci W. schrieb: > Aber es ist halt vermutlich so: Das Badezimmer ist die neue Küche ;-) Nein, es soll Instagram tauglich sein. Küchen und Kinderzimmer sind schon lange Insta-tauglich, jetzt ist eben das Badezimmer an der Reihe.
Xanthippos schrieb: > Mit Go wollen Pike, Thompson und Griesemer den Umbruch vom > mittelalterlichem Handwerk zur industriellen Produktion verhindern. Aber nicht jedes Produkt benötigt das. Genauso wie nicht jedes Loch in einer Wand von einer Hilti oder Makita gebohrt werden muss.
:
Bearbeitet durch User
G. K. schrieb: > Xanthippos schrieb: > >> Mit Go wollen Pike, Thompson und Griesemer den Umbruch vom >> mittelalterlichem Handwerk zur industriellen Produktion verhindern. > > Aber nicht jedes Produkt benötigt das. > Genauso wie nicht jedes Loch in einer Wand von einer Hilti oder Makita > gebohrt werden muss. Es ist aber schöner, wenn jedes Loch in der Wand von einer Hilti oder Makita gebohrt wird.
Ein T. schrieb: > Es gibt einen Fachausdruck dafür, das nennt sich Arbeitsteilung. Die dann wieder aufgelöst wird.... > hier gibt es den Frontend-, den Backend- und den Datenbankentwickler, Das macht heute der Fullstackentwickler, den Devopskram manchmal auch noch gleich mit dazu. > Wovon redest Du also? Das nennt sich Kostenersparniss. Statt drei Hansel brauche ich nur noch einen.
Joe schrieb: > Es ist aber schöner, wenn jedes Loch in der Wand von einer Hilti oder > Makita gebohrt wird. Sind die Löcher dann glücklicher?
Franko S. schrieb: > Das macht heute der Fullstackentwickler, den Devopskram > manchmal auch noch gleich mit dazu. Ich finde allerdings ebenfalls, dass die IT inzwischen zu komplex geworden ist, um all dies von einer einzelnen Person zu erwarten. Ich erwarte von einem Baumeister ja auch nicht, dass er ganz alleine ein komplettes Haus baut und instand hält.
Franko S. schrieb: > Ein T. schrieb: >> Es gibt einen Fachausdruck dafür, das nennt sich Arbeitsteilung. > Die dann wieder aufgelöst wird.... Ich nehme an, Du meinst den heutigen DevOps-Gedanken. Der hat sich gebildet, weil sich die Trennung der Tätigkeiten oft als problematisch erwiesen hat. Beispielsweise kenne ich das aus dem Umfeld unserer Kunden so, daß sie oft viel zu wenig Datenbanker hatten, so daß jede Änderung an der Datenbank am Ende von deren Arbeitsaufträgen eingereiht wurde und es dann ewig gedauert hat, bis sie endlich durchgeführt werden konnte. Für die anderen Teams war das dann nicht selten ein Blocker, so daß die teilweise dazu übergegangen sind, sinnvolle Änderungen an der Datenbank nicht einmal mehr zu beauftragen und stattdessen um das suboptimale, aber immerhin vorhandene Design herum zu arbeiten, was dann wieder zu höheren Aufwänden für die Wartung und Pflege der Software geführt hat. Ebenso habe ich die Probleme kennengelernt, die aus der strikten Trennung zwischen Entwicklung und Betrieb entstanden sind. Dabei muß es nicht einmal so weit kommen, daß die Teams gegeneinander arbeiten; es reicht schon, wenn die Entwickler den Operatoren ihre Arbeit vor die Füße werfen und sich ansonsten nicht mehr darum kümmern, wie die Ops das Zeug zum Laufen bringen und wie es sich dann zur Laufzeit verhält. Insofern erscheint es mir schon sinnvoll, die Aufgaben nicht gar so strikt zu trennen, sondern in kooperativen Teams mit gemeinsamer Verantwortlichkeit zu integrieren. Das heißt ja nicht, daß die Entwickler dann unbedingt Operations machen müssen und umgekehrt, natürlich macht jeder im Team immer noch primär das, was er am Besten kann. Dennoch soll durch den DevOps-Gedanken der Austausch zwischen den Beteiligten und auch die gemeinsame Verantwortlichkeit gestärkt werden, und das halte ich aus meiner persönlichen Erfahrung heraus für durchaus sinnvoll. >> hier gibt es den Frontend-, den Backend- und den Datenbankentwickler, > Das macht heute der Fullstackentwickler, den Devopskram manchmal auch > noch gleich mit dazu. > >> Wovon redest Du also? > Das nennt sich Kostenersparniss. Statt drei Hansel brauche ich nur noch > einen. Nein, Du brauchst für denselben Output pro Zeit immer noch drei, vielleicht sogar dieselben drei Leute. Natürlich ist Wirtschaftlichkeit ein wichtiger Aspekt und Kosteneinsparungen sind ein Teil davon, aber in diesem Fall geht es weniger um die Einsparung von Gehältern, sondern um Einsparungseffekte durch die verbesserte Organisation der Mitarbeiter -- wenngleich die für die Kooperation zwingend nötige Koordination dabei sogar zuerst meistens höhere Aufwände (und damit Kosten) verursacht.
> es reicht schon, wenn die Entwickler den Operatoren ihre Arbeit vor die > Füße werfen und sich ansonsten nicht mehr darum kümmern Vermutlich ist das hier die zentrale Frage. Extreme Beispiele findest du im Bauwesen. Jeder Spezialist hält nur mehr seine Vorschriften ein. Niemand fühlt sich mehr für das Gesamtergebnis verantwortlich. Ob nun Keller nass, oder BER Flughafen - die Leute interessiert nur mehr, ob sie der Richter für das Desaster verantwortlich macht. Die SecDevOps sind zwar mit ihrem riesigen Aufgabengebiet überfordert, aber zumindest fühlen die sich noch für das Ergebnis verantwortlich. Der Automobilbau hat da einen Kompromiss gefunden. Ein einzelner Ingenieur, Bürokrat oder Manager kennt sich nur auf seinem mikroskopisch kleinen Gebiet aus. Trotzdem fühlen die sich für das Gesamtergebnis verantwortlich. Wir können jetzt zwei unterschiedliche Wege einschlagen. Eine einfache Sprache, damit die DevSecOps weiterhin die Arbeitsteilung aus C64 Zeiten beibehalten können. Oder herausfinden, warum Arbeitsteilung beim Bau von Flugzeugen funktioniert, nicht aber beim Bau von Flughäfen.
Xanthippos schrieb: > Oder herausfinden, warum Arbeitsteilung beim Bau von > Flugzeugen funktioniert, nicht aber beim Bau von Flughäfen. Von Boeing lernen heißt Siegen lernen, wie man unter anderem bei der 737 Max 9 erfahren konnte.
Harald K. schrieb: > Von Boeing lernen heißt Siegen lernen, Die lassen jetzt gerne mal die Doorplugs rausfliegen, dann müssen sie nur noch in max. 12000 Fuß Höhe fliegen.
> Von Boeing lernen heißt Siegen lernen
Stimmt.
Der Konzern wurde von einem Ingenieur gegründet. William Edward Boeing.
80 Jahre lang war Boeing allen anderen haushoch überlegen. Mal abgesehen
von dem mit Steuergeldern durchgefütterten VEB Airbus ging die gesamte
Konkurrenz Bankrott.
So ab 2000 hörte das Management nicht mehr auf die Ingenieure. Gegen
deren Rat ließen die BWLer untaugliche Workarounds and die betagte 737
dran frickeln.
Da können wir wirklich einiges draus lernen. Wieso ist eine Firma, die
Spitzentechnologie zu vernünftigen Preisen entwickelte innerhalb von 10
Jahren zur Ramschbude verkommen?
Xanthippos schrieb: > Der Konzern wurde von einem Ingenieur gegründet. William Edward Boeing. > 80 Jahre lang war Boeing allen anderen haushoch überlegen. Mal abgesehen > von dem mit Steuergeldern durchgefütterten VEB Airbus ging die gesamte > Konkurrenz Bankrott. Die Rüstungsaufträge an den VEB Boeing werden aus Steuergeldern finanziert.
> Die Rüstungsaufträge an den VEB Boeing werden aus Steuergeldern > finanziert. Ja, in den USA gibt es offiziell keine staatlichen Zuschüsse für Forschung und Entwicklung. Aber jede Menge Aufträge von Militär und Geheimdiensten. Die einen behaupten, Google sei eine Tarnorganisation der CIA. Die anderen behaupten, mit dem Umweg über die CIA haben die USA nur die üblichen staatlichen Zuschüsse verschleiert. Gibt auch die Behauptung, das US Militär wolle gar keine Microsoft Produkte einsetzen. Würde aber von Lobbyisten und Politikern dazu gezwungen. Egal - da kommt doch die Frage auf: Können sich die Softwaregiganten unsere irrsinnig teuren Entwicklungsmethoden nur leisten, weil sie von staatlichen Zuschüssen leben? Das Automobil wollten die damaligen Politiker verhindern. Karl Benz musste ohne staatliche Zuschüsse auskommen. Führte eine effiziente Arbeitsteilung ein.
Ein T. schrieb: > Nein, Du brauchst für denselben Output pro Zeit immer noch drei, Nein eben nicht, weil sich die Technik, Tools,... drumherum weiterentwickelt haben, d.h. der Zeitaufwand ging in einem Bereich bis auf ein Drittel oder mehr zurück oder ist sogar komplett rausgefallen. Die Leute die früher noch mit separaten Tasks beschäftig waren, machen heute jeweils Teilaufgaben der anderen mit. Wer Webservices entwickelt, der weiss was ich meine. CI, direkt in die Cloud alles weitgehend automatisiert. Dort sieht man am besten wie sich das gewandelt hat. Im Embeddedbereich vermutlich weniger bis gar nicht, wegen vieler Auflagen (Medizintechnik, Safety,...).
> der Zeitaufwand ging in einem Bereich bis > auf ein Drittel oder mehr zurück oder ist sogar komplett rausgefallen. Im Prinzip ja. Wenn du die gesamte Entwicklung von der Lochkarte bis zu den heutigen Tools vergleichst, ging der Aufwand für die Kodierung auf 1/1000000 zurück. Aber der Aufwand, der durch die unüberschaubaren Zusammenhänge entsteht, ist explodiert. Als wir noch in Kilobytes rechneten, konnte ein Kodierer Modulstrukturen, Softwaresicherheit, Terminplanung und Freigabetest nebenbei mit erledigen. In allen anderen Bereichen haben wir eine Arbeitsteilung eingeführt. Die einen kümmern sich nur um Modulstrukturen, die anderen nur um Sicherheit, die nächsten nur um Terminplanung... Nur in der Softwareentwicklung haben wir es umgekehrt versucht. Wir machen die Sprachen und Tools so einfach, das jeder Kodierer nebenbei Modulstrukturen erfinden kann. Hat ja bis 2000 rum geklappt. Zur Zeit wächst uns das aber über den Kopf. Die dutzenden von Layern und Libraries überblickt niemand mehr. Jeder Bugfix, der eine Sicherheitslücke schließt, erzeugt zwei neue. Der Kern von Go ist: Die meisten Kodierer verstehen die objektorientierten Features nicht. Lassen wir einfach weg. Aber die Kritiker sagen: Für unsere heutigen umfangreichen Systeme brauchen wir diese Features. Habe den Eindruck, Go ist ein Relikt aus einer untergegangenen Epoche. Rob Pike will sich nicht damit abfinden - die Zeiten in denen ein Entwickler von der Erfindung bis zum Freigabetest alles selbst machen konnte, sind vorbei. > Die Leute die früher noch mit separaten Tasks beschäftig waren, machen > heute jeweils Teilaufgaben der anderen mit. Ganz übles Thema. Maschinenbau, Bauwesen, Landwirtschaft... brauchten früher hauptsächlich angelernte Hilfsarbeiter. Deren Arbeit machen inzwischen die Maschinen. Heutzutage brauchen wir hauptsächlich Ingenieure und Manager. Hilfsarbeiter zu Ingenieuren umschulen hat nicht geklappt. Auch in der Softwareentwicklung brauchen wir bald nur mehr Experten für Modulstrukturen, Sicherheit und Terminplanung. Die angelernten Kodierer werden durch Tools ersetzt. Es stimmt: In der Softwareentwicklung machen die überflüssig gewordenen Kodierer die Arbeit der Ingenieure und Manager mit. Wie lange wird das noch funktionieren. Bringt uns da eine triviale Sprache wie Go weiter?
Franko S. schrieb: > Ein T. schrieb: >> Nein, Du brauchst für denselben Output pro Zeit immer noch drei, > Nein eben nicht, weil sich die Technik, Tools,... drumherum > weiterentwickelt haben, d.h. der Zeitaufwand ging in einem Bereich bis > auf ein Drittel oder mehr zurück oder ist sogar komplett rausgefallen. > Die Leute die früher noch mit separaten Tasks beschäftig waren, machen > heute jeweils Teilaufgaben der anderen mit. > Wer Webservices entwickelt, der weiss was ich meine. CI, direkt in die > Cloud alles weitgehend automatisiert. Dort sieht man am besten wie sich > das gewandelt hat. Im Embeddedbereich vermutlich weniger bis gar nicht, > wegen vieler Auflagen (Medizintechnik, Safety,...). Dafür sind die Projekte viel komplexer geworden als ehedem und das Produkt aus Zeitaufwand und Manpower deswegen konstant geblieben.
Microservices auf Clound Plattformen sind meiner Meinung nach ein weiterer Versuch, mit Programmierern aus zu kommen, die das komplexe Gesamtprojekt nicht durchblicken. Man zerlegt ein großen Programm in viele kleine Microservices mit einem überschaubaren Funktionsumfang. Weil sie klein sind, taugen Programmiersprachen wie Go dazu. So die Idee. Es besteht aber die Gefahr, dass der Blick auf das Große Ganze verloren geht. Irgendjemand muss weiterhin das gesamt Projekt durchschauen, und von demjenigen macht sich die Firma abhängig. Die Module rufen sich gegenseitig auf und tauschen Daten aus. Dazu verwendet man irgendeine standardisierte Schnittstelle die von der Programmiersprache unabhängig ist, zum Beispiel REST und JSON. Technisch gesehen explodiert dadurch der Aufwand. Wo früher Funktionen direkt binär innerhalb des Programmes aufgerufen wurden, müssen jetzt Eingabeparameter validiert und serialisiert und die Ergebnisse wieder de-serialisiert werden. Netzwerkverbindungen müssen geloadbalanced werden, timeouts sollen behandelt werden, teils mit komplexen Wiederhol- und Roll-Back-Verfahren. Dazu muss jegliche Kommunikation sicherheitshalber verschlüsselt und mit Authentifizierung stattfinden. Daten in Dutzenden verteilten Caches müssen asynchron aktualisiert werden. Und beliebig skalierbar soll es auch noch sein, sonst lässt sich der Aufwand nicht rechtfertigen. Damit man Fehler untersuchen kann, werden viel mehr Log-Meldungen mit mehr Details protokolliert. Beim Auswerten (oder schon vorher) müssen diese zusammen gefasst werden, was in der Regel auf eine strukturierte Datenbank hinaus läuft. Mit einem simplen log.println() ist es da nicht mehr getan. Spätestens beim Testen und Debuggen verteilter Prozesse braucht es Leute, die mit der ganzen Plattform umgehen können. Da reicht es nicht mehr, nur ein paar einfache Module zu kennen. Wer das nicht von Anfang an mit eingeplant hat, kann von den Kosten überwältigt werden. Xanthippos schrieb: > Bringt uns da eine triviale Sprache wie Go weiter? Ich denke: nein. Für mich fühlt sich das eher so an, als ob ich einen bewährten Kreuz-Schraubendreher durch einen neuen anderen Schraubendreher ersetze. Es bleibt aber dabei, Dinge zusammen zu schrauben. Sie werden dadurch nicht nennenswert einfacher oder billiger. Go funktioniert, aber es löst keine Probleme. Ich arbeite seit 3 Jahren täglich damit, aber ganz ehrlich: Ich würde die Sprache nicht vermissen, wenn sie plötzlich verschwinden würde.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Microservices auf Clound Plattformen sind meiner Meinung nach ein > weiterer Versuch, mit Programmierern aus zu kommen, die das komplexe > Gesamtprojekt nicht durchblicken. ...müssen. > Es besteht aber die Gefahr, dass der Blick auf das Große Ganze verloren > geht. Irgendjemand muss weiterhin das gesamt Projekt durchschauen, und > von demjenigen macht sich die Firma abhängig. Nach meiner Erfahrung durchschaut das nicht nur einer, sondern ein ganzes Team, und auch die einzelnen Entwickler haben üblicherweise zumindest einen groben Überblick -- auch wenn sie sich primär vollständig auf ihren eigenen Anteil konzentrieren können. > Die Module rufen sich gegenseitig auf und tauschen Daten aus. Dazu > verwendet man irgendeine standardisierte Schnittstelle die von der > Programmiersprache unabhängig ist, zum Beispiel REST und JSON. Technisch > gesehen explodiert dadurch der Aufwand. Die Kernidee ist eigentlich, daß genau das nicht passiert. Im Endeffekt geht es bei Microservices nur um eine Modularisierung. Richtig, die ist zunächst ein gewisser Mehraufwand, aber der zahlt sich bei der Wartung der Software ziemlich schnell wieder aus. Das kennen wir doch alle, monolithische versus modulare Software. Größere Monolithen werden immer schwieriger zu entwicklen, zu testen, zu pflegen und zu warten, und meist ist man dabei zudem an die Limitierungen der gewählten Technologie(n) und Sprache(n) gebunden. Mit Microservice-Architekturen kann ich einzelne Komponenten ziemlich einfach austauschen, und es ist dabei auch kein Thema, Microservice A mit Python, B mit Golang und C mit C++ umzusetzen, weil A umfangreiche Berechnungen mit numpy, Scipy und Scikit-Learn macht, B eine sehr hohe Last an Requests verarbeiten muß und C eine speicherintensive Konsolidierung über Milliarden von Datenbankeinträgen machen muß. > Und beliebig skalierbar soll es auch noch sein, sonst lässt sich der > Aufwand nicht rechtfertigen. Skalierbarkeit hängt üblicherweise primär an der Persistierung, Stichwort Brewer's oder CAP-Theorem. > Damit man Fehler untersuchen kann, werden viel mehr Log-Meldungen mit > mehr Details protokolliert. Beim Auswerten (oder schon vorher) müssen > diese zusammen gefasst werden, was in der Regel auf eine strukturierte > Datenbank hinaus läuft. Mit einem simplen log.println() ist es da nicht > mehr getan. Das kommt darauf an, worauf Deine Microservices laufen. Moderne Frameworks wie Kubernetes, Docker Swarm oder Apache Mesos haben dafür je eigene Lösungen, und zusätzlich gibt es eigene Tools für das Thema Observability wie etwa Jaeger, Elastic- oder OpenSearch mit denen man die Requests sauber durch die Schichten der Microservices verfolgen und visualisieren kann. Die genannten Frameworks erwarten auch üblicherweise nur, daß die Software ihre Logs auf Stdout und / oder Stderr schreibt, reichern die Logeinträge mit weiteren Metadaten an und aggregieren sie entweder selbst oder über weitere Komponenten. Deswegen ist log.Println() schon ganz in Ordnung so und paßt jedenfalls zum Anwendungsfall, für den Golang entworfen wurde. > Ich denke: nein. Für mich fühlt sich das eher so an, als ob ich einen > bewährten Kreuz-Schraubendreher durch einen neuen anderen > Schraubendreher ersetze. Es bleibt aber dabei, Dinge zusammen zu > schrauben. Sie werden dadurch nicht nennenswert einfacher oder billiger. > > Go funktioniert, aber es löst keine Probleme. Ich arbeite seit 3 Jahren > täglich damit, aber ganz ehrlich: Ich würde die Sprache nicht vermissen, > wenn sie plötzlich verschwinden würde. Mit Verlaub, sehe ich das anders. Ja, Golang hat ein paar unschöne Ecken, allerdings ist mir in meinem Leben noch keine einzige Programmiersprache begegnet, bei der es keine unschönen Ecken gegeben hätte. Golang hat zwei spezifische Anwendungsdomänen, nämlich Microservices einer- und schnelle Kommandozeilenwerkzeuge andererseits, und darin ist es richtig gut.
Gemaess einem Vortag von Google zu GO ist ein wesentliches Designziel Rueckwaertskompatibilitaet. Es gibt nichts Schlimmeres bei grossen Projekten wie Library Inkompatibilitaeten. Die Eine Library benoetigt Version ab 12.7, die Andere lief nur bis Version 10.4. Speziell, wenn man die Quellen nicht hat. Und auch falls... Das soll GO also loesen. Auf alle Zeiten. Fuer die meisten Programmierer ist das natuerlich kein Thema, denn nach ihnen die Sintflut. Fuer Google mit ihren Megaprojekten eben schon. Die Versionierung wird bei der Kompilierung beachtet und unterstuetzt Also einfach das Thema GO und Rueckwaertskompatibilitaet anschauen. https://go.dev/doc/go1compat
:
Bearbeitet durch User
Go ist mehr oder weniger tot. Das war mal ein kleiner Hype vor ein paar Jahren. Die Vorteile bieten inzw. auch andere Sprachen. Das Lesen auf alle Zeit braucht kaum einer weil das Zeug im Webumfeld sowieso nach wenigen Jahren entsorgt wird. Zudem hat man mit anderen Sprachen/Plattformen ganz andere Auswahl an Frameworks,... für go gibts doch praktisch nix, was da offizielle dabei ist das meiste halbfertig. Ich weiss noch wie ich das damals getestet habe, die Anbindungen an MySQL waren alle mehr oder weniger kaputt und das bei einer Sprache die im Web gross rauskommen wollte mit Webservices,.. und dann geht nicht mal die Anbindung an die Allerwelts-DB die im Web praktisch der Standard ist nicht, das war damals der Mega-LOL des Jahres. Dann das Delpoyment: Muss man nur rüberkopieren, nur eine Datei. Ja toll aber da das heute eh alles automatisch geht ist das egal was das Deploymentscript rumkopiert und ob das eine oder 1000 Dateien sind. Vergleicheweise klein ist da auch nix wenn immer alles fett eingelinkt wird. Da ist das Javazeug heute schon schlanker und ebenso fix, stichwort GraalVM, serverless und Quarkus. Go ist heute die überflüssigste Sprache überhaupt, dazu noch schlecht, sie kann nix wirklich besser, das ist alles nur Marketinggelaber, andere Sprachen/Plattformen haben aufgeholt. Man sieht es schon an den Jobangeboten, Büchern, Tuts, da gibts kaum was, das Zeug braucht heute keiner mehr, es kam Jahre zu spät. Und der Vater des ganzen war auch eher lernresistent wenn da Vorschläge und Bugfixes gemeldet wurden. Da hauen dann irgendwann die Leute ab und ziehen weiter. Go kann auf dem Friedhof der toten Googleprojekte beerdigt werden, das vermisst keiner.
Franko S. schrieb: > Go ist mehr oder weniger tot. Man kann Go mögen oder auch nicht. Aber eine Programmiersprache, die in praktisch allen einschlägigen Statistiken in den Top 20 und sehr oft sogar in den Top 10 liegt, würde ich nicht unbedingt als tot bezeichnen.
Franko S. schrieb: > Go ist mehr oder weniger tot. Mal nachdenken, was so alles in Golang entwickelt worden und weit verbreitet ist. Das hilft bei der Einordnung Deines Kommentars.
Ein T. schrieb: > Mal nachdenken, was so alles in Golang entwickelt worden und weit > verbreitet ist. Das hilft bei der Einordnung Deines Kommentars. Schau in die (deutschen) Stellenanzeigen. Tippe ein "Java" danach "golang" und vergleiche die Anzahl der Stellenanzeigen. Selbst das alte Ranz-Delphi hat mehr Treffer. Schaue ich nur in meiner Region gibt es exakt 5 golangstellen und das sind nicht pure golangstellen sondern wird dort als Alternative bei den Kenntnissen angegeben, eingesetzt wird es gar nicht. Wenn ein paar Hipsterbuden wie google das einsetzen sagt das nix über die Verbreitung, ebensowenig wenn ein paar bekannte Tools damit umgesetzt wurden. Und so ein Schrott wie der Thiobeindex ist so aussagekräftig wie Astrologie, aber Elektriker konnten noch nie Statistik deshalb wird dieser Blödsinn als Argument gebracht. Ihr habt doch was an den Augen. Golang? 2024? LOL!
Franko S. schrieb: > Go ist mehr oder weniger tot. Wie kann eine Programmiersprache tot sein, die aktuell weiter entwickelt und von großen Firmen verwendet wird? > Das Lesen auf alle Zeit braucht kaum einer weil das Zeug im > Webumfeld sowieso nach wenigen Jahren entsorgt wird. Zumindest für das Backend kann ich dir da nicht zustimmen. Da wirfst man nicht einfach so etablierte Software weg. > Da ist das Javazeug heute schon schlanker und ebenso fix Definitiv zweimal nein > die Anbindungen an MySQL waren alle mehr oder weniger kaputt Seit mehr als 3 Jahren funktioniert das einwandfrei. Mir fällt es schwer, deine Einschätzung ernst zu nehmen, wenn sie auf so alter Erfahrung basiert. Dazu kommt die Tatsache, das MySQL für die Cloud eh eine schlechte Wahl ist. > Man sieht es schon an den Jobangeboten, Büchern, Tuts, da gibts kaum was Es gibt reichlich kostenlose Doku direkt von Google. Auch kann ich die deuten Artikel von Bitlöffel empfehlen. Wer braucht schon Bücher, wenn alles Online ist? Für mich ist die Sprache sehr wichtig, weil die Firma sich dafür entschieden hat. Ich wäre sonst raus, und mit 49 Jahren eventuell gar langzeit-arbeitslos. Warum macht die Firma das? Weil die aktiven und potentiellen Kunden das so wollen. Java steht nicht mehr in deren Gunst. Selbst das Argument, dass wir mit Java 20 Jahre Erfahrung haben und damit schneller entwickeln können, hilft nicht.
:
Bearbeitet durch User
Franko S. schrieb: > Schau in die (deutschen) Stellenanzeigen. Nur weil Go in Deutschland (noch) nicht sehr populär ist, ist die Sprache weltweit tot? Kauf dir ein Periskop, damit siehst du besser über den Tellerrand. > Tippe ein "Java" danach "golang" und vergleiche die Anzahl der > Stellenanzeigen. Nur weil eine Sprache weniger häufig nachgefragt wird als Jave, ist sie tot? Mit dieser Argumentation wären die meisten Programmiersprachen tot. Außerdem suchst du nach dem falschen Namen. Die Sprache heißt nicht golang, sondern Go. In manchen Stellenanzeigen für Go wird zwar auch Golang genannt, aber längst nicht in allen. > Und so ein Schrott wie der Thiobeindex ist so aussagekräftig wie > Astrologie, Die Art und Weise, wie Tiobe die Daten erhebt, erlaubt zwar keine Aussage über die Qualität einer Programmiersprache, sehr wohl aber darüber, wie lebendig diese ist. Dasselbe gilt für die diversen Github-Statistiken.
Steve van de Grens schrieb: > Wer braucht schon Bücher, wenn > alles Online ist? Wer braucht schon online Doku, wenn es ChatGPT & Konsorten gibt ;-) ciao Marci
Franko S. schrieb: > Ein T. schrieb: >> Mal nachdenken, was so alles in Golang entwickelt worden und weit >> verbreitet ist. Das hilft bei der Einordnung Deines Kommentars. > > Schau in die (deutschen) Stellenanzeigen. Ist Deutschland der Nabel der Welt? Deutsche Unternehmen sind nach meinen Erfahrungen sehr vorsichtig und zurückhaltend hinsichtlich der Einführung neuer Technologien, ob das also wirklich ein Maßstab ist? Wie der "Typ" bereits geschrieben hatte, ist Go zudem keine General Purpose Language, sondern besonders für bestimmte Themenbereiche und Anwendungsfälle sinnvoll. Infrastrukturkomponenten wie Docker, Kubernetes, etcd oder Consul benutzen zwar viele Unternehmen in Deutschland, aber nur wenige entwickeln solche Dinge selbst. Ähnliches gilt für performante Webserver, Proxies und Werkzeuge für die Kommandozeile. Und, da Du es erwähnst: was Java angeht, habe ich eher das Gefühl, dass Oracle das mit seiner neuen Release- und Lizenzpolitik zumindest behindert. Aber Java hat sich im Consumermarkt ohnehin nicht durchsetzen können, ähnlich wird auch bei Golang sein. Dafür ist Java im Enterprisebereich sehr stark vertreten, und dort verorte ich tendenziell auch Golang, zumal es dort seine besondere Stärke bezüglich der sich zunehmend verbreiteten Weboberflächen ausspielen kann.
Purzel H. schrieb: > Das soll GO also loesen. Auf alle Zeiten. Da ist allerdings ein ziemlich langer Zeitraum. Könnte scheitern… Oliver
Sheeva P. schrieb: > Ist Deutschland der Nabel der Welt? Deutsche Unternehmen sind nach Ich lebe nun mal hier, da zählt erst mal was hier los ist und nicht in der Hippsterbude in CA. Selbst wenn man die USA berücksichtigt stinkt go noch immer drastisch ab. > meinen Erfahrungen sehr vorsichtig und zurückhaltend hinsichtlich der > Einführung neuer Technologien, ob das also wirklich ein Maßstab ist? Der Zug ist lang abgefahren, da wird nix mehr eingeführt mit go. Hast du eigentlich die letzen 10 Jahren vom Hype bis heute miterlebt? Da ist nix mehr übrig von der Hypewelle, die ist ausgelaufen, die Luft ist raus. > Wie der "Typ" bereits geschrieben hatte, ist Go zudem keine General > Purpose Language, sondern besonders für bestimmte Themenbereiche und > Anwendungsfälle sinnvoll. Infrastrukturkomponenten wie Docker, > Kubernetes, etcd oder Consul benutzen zwar viele Unternehmen in > Deutschland, aber nur wenige entwickeln solche Dinge selbst. Und? Wird go übermässig in Projekten verwendet? nein. Ob irgendwelche Drittsoftware die zwar populär und verbreitet sind sagt nix über die generelle Verbreitung und akzeptanz von go aus. > Ähnliches > gilt für performante Webserver, Proxies und Werkzeuge für die > Kommandozeile. Manchen zig andere Sprachen ebenso, sonst hätte sich hier go schon lange breit gemacht tut es aber nicht, wie oft muss ich das noch erklären. Eure Versuche hier Proargumente herbeizufabulieren funktioniert nicht, lasst es endlich bleiben. > Und, da Du es erwähnst: was Java angeht, habe ich eher das Gefühl, dass > Oracle das mit seiner neuen Release- und Lizenzpolitik zumindest > behindert. Oracles Lizenzpolitik interessiert niemanden es gibt inzw. zig alternative JDK-Anbieter, ebenso mit Support. Amazon Coretto, Alibaba, SAPMachine, MS, Azul, IBM/Eclipse AdoptJDK/Semeru/Temurin, Liberica, Mandrel,Trava, Tencent,... such dir eines aus, gibts auch mit Support wie bei Oracle. Azul und anderen bieten z.B. Bugfixes noch für uralte JDKs, teils kostenlose , an die Oracle längst nicht mehr pflegt bzw. nur für sehr viel Geld. Oracles JDK nimmt man nur wenn man muss. > Aber Java hat sich im Consumermarkt ohnehin nicht durchsetzen > können, ähnlich wird auch bei Golang sein. Dafür ist Java im Wir reden auch nicht vom Consumermarkt weil der irrelevant ist. > Enterprisebereich sehr stark vertreten, und dort verorte ich tendenziell > auch Golang, zumal es dort seine besondere Stärke bezüglich der sich > zunehmend verbreiteten Weboberflächen ausspielen kann. Rede doch keinen Blödsinn wenn du keine Ahnung hast dann sei doch einfach still. Java ist dort DER Standard auch wenn es technisch zT. nicht taugt (serverless/GraalVM) kein Schwein setzt dort ersthaft und grossflächig auf go. Schau dir die Stellenanzeuigen, Projektbörsen im Enterpriseumfeld, Bücher, Schulungen, ... endlich mal an und sehe es endlich ein, go spielt dort keine Rolle als Entwicklungssprache.
Franko S. schrieb: > Der Zug ist lang abgefahren, da wird nix mehr eingeführt mit go... > Da ist nix mehr übrig von der Hypewelle, die ist ausgelaufen, > die Luft ist raus. Das ist nicht korrekt. Konkretes Beispiel: Unsere Firma führt damit gerade die "tebio Business Cloud" ein. Unsere GF haben einige Millionen Euro in das Projekt versenkt, was für eine 20 Mann Firma keine Kleinigkeit ist. Die würden das nicht machen, ohne von dem Konzept überzeugt zu sein. Ich halte sie nicht für Dummköpfe, denn dafür haben sie es bisher zu weit gebracht. Zuvor wollten unsere Kunden Java EE. Das ist (bei uns) ein Auslaufmodell. Unsere Softwareentwickler wären gerne bei Java geblieben, aber die Kunden lehnen es (im Gegensatz zu Go) ab. > Wird go übermässig in Projekten verwendet? nein Man muss nicht übermäßig verwenden, um sagen zu können "es lebt". > Oracles Lizenzpolitik interessiert niemanden Oracles Lizenzpolitik ist für einige Firmen existenziell bedrohlich geworden, weswegen entsprechende Konsequenzen gezogen wurden. Was Oracle macht ist also durchaus von Interesse, sogar sehr wichtig. > Rede doch keinen Blödsinn wenn du keine Ahnung hast dann sei doch > einfach still. So ist keine vernünftige Diskussion möglich, lass das bitte.
:
Bearbeitet durch User
Franko S. schrieb: > Ich lebe nun mal hier, da zählt erst mal was hier los ist und nicht > in der Hippsterbude in CA. Selbst wenn man die USA berücksichtigt stinkt > go noch immer drastisch ab. Soviel zu Deinem Blick über den eigenen Tellerrand und zu der Arroganz, eines der erfolgreichsten Unternehmen der Welt als "Hippsterbude" abzutun. Mir ist bis dato kein europäisches oder gar deutsches Unternehmen bekannt, das auch nur näherungsweise so erfolgreich wäre wie die "Hipsterbude" Google. >> meinen Erfahrungen sehr vorsichtig und zurückhaltend hinsichtlich der >> Einführung neuer Technologien, ob das also wirklich ein Maßstab ist? > Der Zug ist lang abgefahren, da wird nix mehr eingeführt mit go. Hast du > eigentlich die letzen 10 Jahren vom Hype bis heute miterlebt? Da ist nix > mehr übrig von der Hypewelle, die ist ausgelaufen, die Luft ist raus. Komisch, ein Teilnehmer dieses Thread berichtet, daß sein Arbeitgeber gerade auf Go umschwenkt. Mir persönlich sind vier internationale Konzerne aus der Finanzbranche bekannt, die Projekte mit Go umsetzen, teilweise als Ersatz für alte Cobol-Anwendungen und in mindestens zwei Fällen als Ersatz für eine in die Jahre gekommene Java-Applikation. Genau, die Luft ist raus, da stimme ich Dir zu, meine damit aber Deine "sachkundige" Argumentation. > Und? Wird go übermässig in Projekten verwendet? nein. Aber ja doch, es wird übermässig in Infrastrukturprojekten verwendet. Daß die eher selten in Europa oder gar Deutschland entwickelt werden, ändert daran ja rein gar nichts. > Ob irgendwelche > Drittsoftware die zwar populär und verbreitet sind sagt nix über die > generelle Verbreitung und akzeptanz von go aus. Von einer spezialisierten Sprache eine "generelle Verbreitung" zu erwarten und sie für tot zu erklären, wenn sie diese naturgemäß nicht erreichen kann und nicht einmal soll, ist zwar sehr lustig, aber kaum seriös. >> Ähnliches >> gilt für performante Webserver, Proxies und Werkzeuge für die >> Kommandozeile. > Manchen zig andere Sprachen ebenso, Nein, tun sie nicht. Go vereint verschiedene Eigenschaften, die es einzeln zwar auch bei anderen Sprachen gibt, aber nicht in dieser Kombination. > sonst hätte sich hier go schon lange > breit gemacht tut es aber nicht, wie oft muss ich das noch erklären. Du erklärst ja nicht, sondern behauptest nur. > Eure Versuche hier Proargumente herbeizufabulieren funktioniert nicht, > lasst es endlich bleiben. > > Rede doch keinen Blödsinn wenn du keine Ahnung hast dann sei doch Wenn Du sachliche Argumente durch persönliche Angriffe zu ersetzen versuchst, zeigt das nur, wie wenig Du selbst von Deinen "Argumente" überzeugt bist. > Oracles Lizenzpolitik interessiert niemanden es gibt inzw. zig > alternative JDK-Anbieter, [...] > Java ist dort DER Standard auch wenn es technisch zT. > nicht taugt (serverless/GraalVM) kein Schwein setzt dort ersthaft und > grossflächig auf go. Schon lustig: Du siehst es, und verleugnest es trotzdem sehenden Auges. Schau, Java ist nicht nur eine Sprache, sondern -- wie Du ja selbst sagst -- auch ein Standard. Das war sogar schon Gegenstand eines längeren Gerichtsprozesses, als Microsoft in seiner klassischen "embrace, extend and extinguish"-Strategie den Java-Standard unterminieren und vereinnahmen wollte und deswegen von damaligen Inhaber der Rechte an Java, Sun Microsystems, erfolgreich verklagt wurde. Das Ende vom Lied war, daß Microsoft die eigene JVM eingestampft hat und anstelle dessen eine neue Sprache namens C# entwickelt hat. Mittlerweile ist Oracle der "Chef über Java" und bestimmt, in welche Richtung dieser Standard weiterentwickelt wird -- und dies gilt insbesondere für Java Enterprise Edition (Java EE). Wenn die anderen da nicht folgen, sind sie bald abgehängt, und Java-Nutzer, die 100%ige Kompatibilität zum Standard wollen, sind jetzt schon auf die Oracle-JVM angewiesen. Weißt Du, ich rede hier nicht von kleinen Hackerklitschen, sondern von großen Konzernen, die auf Stabilität, Sicherheit und Support angewiesen sind und sich das leisten können. Das hat bereits zu einer Zerfaserung im Java-Umfeld geführt und unterminiert dadurch eine der Garantien, für die Java einstmals gestanden hat: "write once, run anywhere". Darum liefern einige Projekte sogar schon die Laufzeitumgebung in ihren Paketen mit, zum Beispiel Elasticsearch. > Schau dir die Stellenanzeuigen, Projektbörsen im > Enterpriseumfeld, Bücher, Schulungen, ... endlich mal an und sehe es > endlich ein, go spielt dort keine Rolle als Entwicklungssprache. Wie gesagt, ich schaue nicht auf Stellenanzeigen, sondern auf das, was bei unseren (vornehmlich Fintech-) Kunden stattfindet. Jetzt. Heute. In der Praxis und nicht durch irgendeinen Argumentationshilfsproxy wie Stellenanzeigen. Bei unseren Kunden würde übrigens niemand auf Stellenanzeigen schauen, um die Eignung oder die Lebendigkeit einer Sprache zu beurteilen...
News zum Thema: https://www.heise.de/news/Neue-Sicherheitsstrategie-bei-Google-Rust-statt-C-9646686.html "Google stellt seinen Code verstärkt auf speichersichere Sprachen wie Java, Go, Carbon und insbesondere auch Rust um. Das betrifft allen neu geschriebenen Code und die Teile der bestehenden, sicherheitsrelevanten Basis." An anderen Stellen wird auch noch Rust genannt.
:
Bearbeitet durch User
Steve van de Grens schrieb: > An anderen Stellen wird auch noch Rust genannt. Dann schaust du mal in die Kommentare wo sie go verwenden und warum go nicht auch in anderen Bereichen verwendet wird sondern rust, zudem wird die Geschichte von go und das Umfeld erwähnt, das bestätigt doch wieder das go seinen Hypezenit schon lange überschritten hat. Wer mit diesem Käse auf den grossen Durchbruch hofft der hat doch schon zweimal den Schuss nicht gehört.
Franko S. schrieb: > Dann schaust du mal in die Kommentare wo sie go verwenden und warum go > nicht auch in anderen Bereichen verwendet wird sondern rust, zudem wird > die Geschichte von go und das Umfeld erwähnt, das bestätigt doch wieder > das go seinen Hypezenit schon lange überschritten hat. Ein seriöser Kommentator hätte solche Behauptungen durch Links auf "die Kommentare" belegt. Daraus folgt: Du bist kein seriöser Kommentator. > Wer mit diesem > Käse auf den grossen Durchbruch hofft Tut das denn jemand? Ach so, nein, das ist nur so eine Unterstellung von Dir, damit Du etwas hast, an dem Du Dich hochziehen kannst. Naja, Du entscheidest selbst, wie Du Dich hier einbringst und was das dann über Dich und Deine "Beiträge" aussagt. Darum danke für die Klarheit.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.