Hallo Zentris,
Ja, anhand der Verbreitung ist GoLang (noch) eine Nischen-Sprache.
Andererseits ist die Lieblingssprache von Andreas auch mehr Nische als Mainstream und wird ebenfalls benutzt.
Ich denke, dass jede Programmiersprache ihre Berechtigung hat. Denn irgendjemand (in den 60ern und 70ern in der Regel eine Person, danach selten mehr) hat sich konzeptionelle Gedanken gemacht, wie man irgendeine Aufgabenstellung besser (leichter, schneller, eleganter, didaktisch hervorragender, ...) lösen könnte.
Schwachpunkte anderer Programmiersprachen wurden beseitigt. Irgendwann gab es soviele grundverschiedene Programmiersprachenkonzepte, dass sie sich gegenseitig beeinflusst haben.
In den 90ern habe ich mal in das Thema "Compilerbau" hineinschnuppern dürfen. Die heutigen sog. Programmierer sind fast nur noch in der Lage, viele Bibliotheken zu öffnen und sich von einem Bibliotheksaufruf zum nächsten durchzuhangeln. Gestern habe ich zufällig ein paar Seiten der Homepage von Chris Gray (wiederholt) durchgelesen. Chris Gray hatte mehrere Programmiersprachen entwickelt und dazu Compiler geschrieben. Die bekannteste davon war wohl Draco, das er unter CP/M entwickelte und später auf den Amiga portierte. In dem Zusammenhang hatte ich diese Programmiersprache auch kennen- und schätzen gelernt. Das war nämlich damals der erste Compiler, der in einem Durchlauf vom Quellcode zum lauffähigen Code compilierte. Es gab keine Zwischenstufen (z.B. andere Programmiersprachen, Bytecode oder Assembler). Der Code war vergleichsweise optimiert und für damalige Verhältnisse sauschnell - und stabil sowieso.
Wenn man eine (neue) Programmiersprache lernt und immer im Hinterkopf hat "So genau brauche ich das gar nicht zu verstehen, weil jemand anders meinen Code immer flicken wird, damit's mal funktioniert." wird dort nie so tief einsteigen (können / wollen), eigene Aufgabenstellungen ohne fremde Unterstützung zu lösen.
Wenn man von vornherein weiß, dass an der gleichen Uni, in der gleichen Firma, in der gleichen Stadt niemand ist, der die gleiche Programmiersprache kann oder lernen möchte, dann beschäftigt man sich damit in einer ganz besonderen Intensität. Diese Erfahrung habe ich jedenfalls Ende der 80er mit Draco und 2003 mit Icon gemacht.
Womit ich jetzt nicht andeuten will, dass man - sollte man doch mal Schwierigkeiten bei der Programmierung in Icon haben - alleine im Wald steht. Es gibt mittlerweile einige in Deutschland, die darin recht anständig programmieren können. Und wenn das nicht reicht, gibt es noch die sog. Global Icon Mailing List. Dort kippt man seine Fragen ein. Erstaunlicherweise veranlasst dies einige Leute, Lösungen zu produzieren. Fast immer äußern sich auch die - bärtigen! - Entwickler bzw. die damals zu den Entwicklern zählten. Da antworten Studenten, Doktoranten, Professoren. Und jede Meinung zählt. Keiner will Recht behalten. Allein der Code zählt. Auch der Prof. kann von pfiffigen Ideen eines Studenten lernen. Das ist irgendwie eine ganz andere Art der Kommunikation.
Und wenn man mal völlig daneben liegt, dann bekommt man das ganz schonend vermittelt.
Vor einiger Zeit (um 2014) fragte jemand, ob denn schon Ideen vorliegen, ob und wenn ja, wie man Icon auf den RPi portieren könnte. Ich habe dann meine Erfahrung eingebracht. Das Erstaunen war groß, dass einer aus Europa der erste war...
Und ich finde, das hat was von Pioniergeist, wenn man in Programmierspraschen entwickelt, die nicht Mainstream sind. Denn selten hat jemand das, was ich gerade programmiere, in der gleichen Programmiersprache schon mal vor mir gemacht.
Ich denke, es hängt mit den Anforderungen zusammen, welche man entwickelt:
Für schnelles Scripten sind die bekannten Scriptsprachen und/oder bash über weite Bereiche ausreichend, haben aber (in meinen Augen) das Problem, dass ggf. "eingebaute" Syntaxfehler in Codeteilen, welche nur selten angefahren werden, dementsprechend spät entdeckt werden (von anderen (mir) fehlenden Sprachkonstrukten mal abgesehen).Um allein das zu vermeiden, muss man sehr sorgfältig testen, um einen 100% Codetestabdeckung zu erreichen.
Da bin ich voll bei Dir, Zentris.
Dazu hatte ich mal einen Beitrag über Profiling geschrieben. Da ging es darum, wie man ermitteln kann, wie oft jede Zeile eines Quellcodes durchlaufen wird und wie viel Zeit in jeder Zeile bei deren Ausführung verbracht wird.
Mit ersterem erreicht man die Code-Abdeckung. Und man sollte stutzig werden, wenn im Code Zeilen sind, die nie angesprungen werden. Entweder trat der Fall nicht ein - dann hat der Test noch Lücken. Oder Forderungen des Lastenheftes wurdenfehlerhaft verstanden bzw. umgesetzt. Oder man schaut sich diese nicht erreichten Zeilen sehr genau an, ob sie denn prinzipiell funktionieren würden - so sie doch mal angesprungen werden sollten. Diesen Fall habe ich in dem Profiling-Beitrag auch vorgestellt.
Mit zweitem erhält man Hinweise auf Programmzeilen, die Potential geschwindigkeitsoptimierender Eingriffe bergen.
Zu Deinem anderen Gedanken: Liegt wohl auch daran, dass z.B. BASH so umfangreich ist, dass sich kaum jemand so intensiv damit beschäftigt hat. Sondern immer nur soviel recherchierte, wie gerade mal benötigt wird, um eine (kleine) Automatisierung / Datenkonvertierung / Kopiern / Löschen / Umbenennen hinzubekommen.
Ursprünglich sollte mit solchen Skriptsprachen ja nur erreicht werden, irgendwelche manuellen Aktionen mit wenig Zeilen zu automatisieren, ohne einen Compiler mit etlichen Compilierungsläufen einzusetzen, bevor das Programm funktioniert.
C++ hat die "Erbsünde" der Zeiger, was die Sprache in meinen Augen sehr mächtig macht, aber auch sehr gefährlich, wenn man das Konzept nicht verstanden hat und nicht sauber arbeitet...
Meiner Meinung ist genau dies die Ursache von Memory Leakage, weshalb Anwendungen einer gewissen Komplexität des Codes mit zunehmender Laufzeit immer mehr Speicher verbrauchen und nicht mehr freigeben.
Beste Grüße
Andreas