Forum: PC-Programmierung Was haltet ihr von Google Go (Golang)?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Joe (Firma: IBM Deutschland) (joe_the_boss)


Lesenswert?

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
von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.)

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Franko S. (frank_s866)


Lesenswert?


von Franko S. (frank_s866)


Lesenswert?

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.

von Xanthippos (xanthippos)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Xanthippos (xanthippos)


Lesenswert?

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.

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Harald K. (kirnbichler)


Lesenswert?

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.

von Xanthippos (xanthippos)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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.

von Manfred P. (pruckelfred)


Lesenswert?

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.

von Xanthippos (xanthippos)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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
von Steve van de Grens (roehrmond)


Lesenswert?

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
von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Oliver S. (oliverso)


Lesenswert?

Vanye R. schrieb:
> Da wuerde eine einfachere Sprache es erlauben Geld zu sparen.

Google hat halt sein Geschäft vollständig verstanden…

Oliver

von Le X. (lex_91)


Lesenswert?

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
von Le X. (lex_91)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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?

von MaWin O. (mawin_original)


Lesenswert?

Harald K. schrieb:
> Welches C bitte mag Threads als Sprachbestandteil kennen?

C11

https://en.cppreference.com/w/c/thread

von Harald K. (kirnbichler)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

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
von Norbert (der_norbert)


Lesenswert?

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$

von Oliver S. (oliverso)


Lesenswert?

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

von Norbert (der_norbert)


Lesenswert?

Interessantes Lesematerial, Danke.

Habe bis jetzt immer nur libc als libc angesehen, alles andere als 
zusätzliche Bibliotheken.

von Random .. (thorstendb) Benutzerseite


Lesenswert?

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
von Steve van de Grens (roehrmond)


Lesenswert?

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
von Xanthippos (xanthippos)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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"?

von Xanthippos (xanthippos)


Lesenswert?

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

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Random .. (thorstendb) Benutzerseite


Lesenswert?

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.

von Franko S. (frank_s866)


Lesenswert?

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
von Xanthippos (xanthippos)


Lesenswert?

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

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Marci W. (marci_w)


Lesenswert?

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

von Marci W. (marci_w)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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

von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Franko S. (frank_s866)


Lesenswert?

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
von Xanthippos (xanthippos)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Xanthippos (xanthippos)


Lesenswert?

> 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?

von Ein T. (ein_typ)


Lesenswert?

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.

von Vanye R. (vanye_rijan)


Lesenswert?

> 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

von Xanthippos (xanthippos)


Lesenswert?

> 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?

von Jens K. (jensky)


Lesenswert?

Joe schrieb:
> Was haltet ihr von Google Go (Golang)?

Meta ite domum!

von Xanthippos (xanthippos)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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?

von Ein T. (ein_typ)


Lesenswert?

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.

von G. K. (zumsel)


Lesenswert?

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.

von G. K. (zumsel)


Lesenswert?

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
von Joe (Firma: IBM Deutschland) (joe_the_boss)


Lesenswert?

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.

von Franko S. (frank_s866)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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?

von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Xanthippos (xanthippos)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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.

von Norbert (der_norbert)


Lesenswert?

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 Xanthippos (xanthippos)


Lesenswert?

> 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?

von G. K. (zumsel)


Lesenswert?

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.

von Xanthippos (xanthippos)


Lesenswert?

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

von Franko S. (frank_s866)


Lesenswert?

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,...).

von Xanthippos (xanthippos)


Lesenswert?

> 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?

von Ein T. (ein_typ)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Ein T. (ein_typ)


Lesenswert?

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.

von Purzel H. (hacky)


Lesenswert?

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
von Franko S. (frank_s866)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Franko S. (frank_s866)


Lesenswert?

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!

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Marci W. (marci_w)


Lesenswert?

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

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

Purzel H. schrieb:
> Das soll GO also loesen. Auf alle Zeiten.

Da ist allerdings ein ziemlich langer Zeitraum. Könnte scheitern…

Oliver

von Franko S. (frank_s866)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Ein T. (ein_typ)


Lesenswert?

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

von Steve van de Grens (roehrmond)


Lesenswert?

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
von Franko S. (frank_s866)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.