Frage: Würdet Ihr ein von mir in Go geschriebenes Tool benutzen?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • 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. :D


    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

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (25. Juni 2017 um 17:26)

  • Frage: Würdet Ihr ein von mir in Go geschriebenes Tool benutzen?? Schau mal ob du hier fündig wirst!


  • meigrafd:


    Ich vermute mal Du berufst Dich hier auf meinen Beitrag im "Hau den m..."?

    Nein. Es gab schon einige Situationen wo sich Benutzer wegen " :fies: " von mir angegriffen/angesprochen/angepisst/whatever fühlten, selbst dann wenn diejenigen nicht direkt angesprochen wurden ( Benutzer etcpp)... Es wurden auch schon einige Smilies aus dem Forum gelöscht weil diese gezielt genutzt wurden um anderen ans Bein zu pinkeln, wie zB wo der Smilie sich was runter zog und der blanke Hintern gezeigt wurde... Wer es darauf an legt kann aber selbst bei einem " ;) " sich angegriffen fühlen


    framp: Zeigst du nun Golang-Code oder sabbelt ihr hier erst noch länger um den heißen Brei rum? :D


    Andreas hat etliche Threads zum Thema ICON hier im Forum: https://www.google.de/#q=site:https:…de+Andreas+ICON
    => Icon: Teil 1, Tutorial zum Erlernen der Programmiersprache Icon: Installation

  • Hallo framp,

    Ja, einige.

    • Das bekannteste ist wohl HostRepair (gestern habe ich eine neue Version gepostet). Damit werden verlorene Netzwerkverbindungen zurückgeholt (Stichwort Mysterium)
    • Dann z.B. Der LinuxCompilator (ermöglicht die GUI-unterstützte Compilierung eines neuen individuellen Kernels)
    • GPIO-Kommandozentrale (nomen est omen)
    • Prozesssimulationen, Prozessleitsysteme
    • Diagnosetools, Monitoring-Programme
    • DiaShower (Abspielprogramm für Bilder beliebigen Formats)
    • Konvertierungsprogramme
    • Kurvendiskussion mit analytischer Ableitung
    • Widerstandsmesser (analysiert Farbcode von Widerständen - recht tiefgehende Programmierung zum Thema Farberkennung)
    • Tool zur Erkennung von Problemen bei der seriellej Kommunikation
    • Unendlichbruch (Berechnung zahlreicher Funktionen über Unendlichbrüche, die schneller genauer das Ergebnis liefern)
    • Etliche Programme zum Thema LIA (Large Integer Arithmetic)
    • Updater (Update.Programm, mit dem man gezielte Updates fahren kann und während des Updates überflüssige Dateien entfernen kann)
    • Mathe-Bibliotheken
    • Analyse von Sprühwolken
    • Reset-/Reboottaster
    • Video-/Zeichentrick-Simulation (Das Rad)


    (so mal auf die Schnelle eine (kleine) Auswahl)


    [quote='framp','http://test.forum-raspberrypi.de/forum/index.ph…8507#post288507']
    [quote='Zentris','http://test.forum-raspberrypi.de/forum/index.ph…8498#post288498']
    Da ICON auch kompiliert wird steht er auch - sofern er Tools der Algemeinheit zur Verfügungs stellen sollte- vor demselben Problem wie ich.


    Nee, nicht mehr. Bei den letzten Linux-Versionen wird Byte-Code erzeugt, der interpretiert wird. Man kann aber auch einen Shebang einragen und den Icon-Code analog Python interpretieren.
    Ältere Versionen (inkl. der aktuellen Windows-Version) haben jedoch compiliert und Objektcode etc. erzeugt.


    Hier im Forum haue ich mit Icon-Code nur so um mich. In der Global Icon Mailing List ebenso.

    Bei Auftragsentwicklungen vermeide ich es, Quellcode herauszugeben. Hier gebe ich in der Regeln nur zeitlich limitierten Bytecode heraus. Oder solchen, der an einen Datenträger gebunden ist (inkl. Crypto-Code). Den Quellcode gibt's erst nach Bezahlung.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (25. Juni 2017 um 01:49)


  • framp: Zeigst du nun Golang-Code oder sabbelt ihr hier erst noch länger um den heißen Brei rum? :D

    Mir scheint Du hast nicht ganz verstanden warum ich diesen Thread eröffnet habe :( golang Code habe ich zu Genüge hier auf github bzw in einem Blog allen Interessenten zur Verfügung gestellt. Ein Tutorial hatte ich auch ins Auge gefasst - aber der Aufwand ist gemessen an der Anzahl möglicher Interessenten einfach überproportional zu gross. Deshalb bin ich auf den Blog ausgewichen.

    Meine Frage ist einfach - noch mal für Dich zusammengefasst :) - ist es verschwendete Zeit weil sowieso niemand irgendwelchen binary Code traut, RaspiTools in golang zu schreiben? Ich kann die weiterhin in bash oder Python schreiben - aber ich würde doch lieber golang dazu benutzen.

  • Habe das schon verstanden... Aber seit einigen Beiträgen geht es gar nicht mehr um dein ursprüngliches Anliegen ...

    Wenn dir Golang spaß macht dann sollte es doch wurscht sein wie viele "andere" es letztlich nutzen?

  • Hallo framp,

    Ja, einige.

    • Das bekannteste ist wohl HostRepair (gestern habe ich eine neue Version gepostet). Damit werden verlorene Netzwerkverbindungen zurückgeholt (Stichwort Mysterium)
    • Dann z.B. Der LinuxCompilator (ermöglicht die GUI-unterstützte Compilierung eines neuen individuellen Kernels)
    • GPIO-Kommandozentrale (nomen est omen)
    • Prozesssimulationen, Prozessleitsysteme
    • Diagnosetools, Monitoring-Programme
    • DiaShower (Abspielprogramm für Bilder beliebigen Formats)
    • Konvertierungsprogramme
    • Tisch-Sonar (zusammen mit Arduino)
    • Kurvendiskussion mit analytischer Ableitung
    • Widerstandsmesser (analysiert Farbcode von Widerständen - recht tiefgehende Programmierung zum Thema Farberkennung)
    • Tool zur Erkennung von Problemen bei der seriellen Kommunikation
    • Unendlichbruch (Berechnung zahlreicher Funktionen über Unendlichbrüche, die schneller genauer das Ergebnis liefern)
    • Etliche Programme zum Thema LIA (Large Integer Arithmetic)
    • Updater (Update-Programm, mit dem man gezielte Updates fahren kann und während des Updates überflüssige Dateien entfernen kann)
    • Mathe-Bibliotheken
    • Analyse von Sprühwolken
    • Reset-/Reboottaster
    • Video-/Zeichentrick-Simulation (Das Rad)
    • zwei Programme zum Erzeugen von graphischen Symbolen zur Unterlegung von in Icon programmierten GUI-Anwendungen
    • Verschlüsselungs-/Entschlüsselungspakete


    (so mal auf die Schnelle eine (kleine) Auswahl)


    [quote='framp','http://test.forum-raspberrypi.de/forum/index.ph…8507#post288507']
    [quote='Zentris','http://test.forum-raspberrypi.de/forum/index.ph…8498#post288498']
    Da ICON auch kompiliert wird steht er auch - sofern er Tools der Algemeinheit zur Verfügungs stellen sollte- vor demselben Problem wie ich.


    Nee, nicht mehr. Bei den letzten Linux-Versionen wird Byte-Code erzeugt, der interpretiert wird. Man kann aber auch einen Shebang einragen und den Icon-Code analog Python interpretieren.
    Ältere Versionen (inkl. der aktuellen Windows-Version) haben jedoch compiliert und Objektcode etc. erzeugt.


    Hier im Forum haue ich mit Icon-Code nur so um mich. In der Global Icon Mailing List ebenso.

    Bei Auftragsentwicklungen vermeide ich es, Quellcode herauszugeben. Hier gebe ich in der Regeln nur zeitlich limitierten Bytecode heraus. Oder solchen, der an einen Datenträger gebunden ist (inkl. Crypto-Code). Den Quellcode gibt's erst nach Bezahlung.


    EDIT:
    Nach Erfahrung hast Du auch noch gefragt.

    Die "Renner" sind wohl HostRepair und dieses Reset-/Reboot-Taster-Teil. Es gibt einige, die sich Icon installiert haben (d.h. nach Anleitung aus dem Quellcode auf den RPi portiert haben), nur um diese Programme ablaufen lassen zu können. Quellcode ins Icon-Arbeitsverzeichnis kopiert, in Geany F5 gedrückt. Und schon ist das "ausführbare" Programm (der Bytecode öffnet den Interpreter) erzeugt.

    Bytecode habe ich bislang nur bei der GPIO-Library herausgegeben. Obwohl ich den dazugehörigen Quellcode auch gepostet habe - wenn auch nicht in jeder Version.

    2013 habe ich mal einen Auftrag aus der Industrie erhalten. Zu meiner Überraschung hat sich niemand an Icon gestoßen. Mag sein, dass es an der Qualität des Lastenheftes, des Pflichtenheftes und des Technischen Designs lag, die ich im Rahmen einer Computersystemvalidierung erstellen musste. Über das Projekt habe ich anderweitig ausführlicher geschrieben.

    Sehr häufig habe ich die Erfahrung gemacht, dass mein Icon-Code Ergebnisse liefert, während andere noch am Konzept für die Umsetzung in anderen (gängigeren) Programmiersprachen diskutieren.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (25. Juni 2017 um 01:11)


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

    Kann ich so nicht stehen lassen! :lol:

    Ich habe jahrelang an einem Telekommunikations-Backbone System mitentwickelt, geschrieben in Java und C++ , das Installations- / Fallback-Framework wurde mit Java, bash und Perl geschrieben...
    Diese SW läuft massiv verteilt auf dutzenden Nodes und 24/7/365 ... da kann man nicht mal eben neu booten, weil der Speicher mal wieder "aufgefressen" wurde.
    Sicher: Wir haben wirklich massiv getestet, damit es zu keinem Memory-Leak kommt... Es ist auf jeden Fall machbar!
    (Ich hatte mal eins "eingebaut" , genau 4 Byte hatte ich vergessen: bei ca. 500 Requests / sec werden da recht schnell kByte/MByte... fiel dennoch erst bei den erweiterten Dauertests auf... fast zu spät...)

    Ich fand "Turbo-Pascal" (wurde dann zu "Delphi" weiter entwickelt) mal absolute cool... aber leider nicht portable...

    GoLang hat die Zeiger nicht, man operiert jedoch damit (was ich derzeit noch etwas verwirrend finde, aber ich lerne ja noch..)
    Das Memory-Handling an sich scheint ebenfalls geschmeidiger zu sein, muss ich noch ergründen...

  • Hallo Zentris,

    dann habe ich mich da missversändlich ausgedrückt - und den Smilie nicht bemerkt. :thumbs1: Korrekt wäre wohl "Memory Leakages passieren, wenn die Erfahrungen des Entwicklers umgekehrt proportional zur Komplexität der Programmieranforderungen stehen."

    Klar, mit einem großen Testaufwand kann man sie entdecken - macht man aber auch nur im professionellen Bereich, dann aber auch nicht so intensiv. Der Hobbyprogrammierer akzeptiert unerklärliche Abstürze...wenn / weil er es nicht besser weiß.


    Sicher: Wir haben wirklich massiv getestet, damit es zu keinem Memory-Leak kommt... Es ist auf jeden Fall machbar!
    (Ich hatte mal eins "eingebaut" , genau 4 Byte hatte ich vergessen: bei ca. 500 Requests / sec werden da recht schnell kByte/MByte... fiel dennoch erst bei den erweiterten Dauertests auf... fast zu spät...)


    Aber damit gibst Du mir schon irgendwie Recht, dass diese mistigen Speicherlecks nicht so ganz ohne sind. Die lassen sich nicht so leicht eben mal aufspüren.



    Ich fand "Turbo-Pascal" (wurde dann zu "Delphi" weiter entwickelt) mal absolute cool... aber leider nicht portable...


    Sag bloß, Du kennst Lazarus / FreePascal (noch) nicht? Gibt's für alle gängigen Betriebssysteme.



    GoLang hat die Zeiger nicht, man operiert jedoch damit (was ich derzeit noch etwas verwirrend finde, aber ich lerne ja noch..)
    Das Memory-Handling an sich scheint ebenfalls geschmeidiger zu sein, muss ich noch ergründen...


    Icon kennt auch keine Zeiger. Jeglicher Speicher, der nicht mehr benötigt wird, wird sofort freigeben. Bei Programmende wird dann richtig aufgeräumt. Speicherlecks sind da praktisch kaum denkbar.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (25. Juni 2017 um 08:43)

  • Wenn dir Golang spaß macht dann sollte es doch wurscht sein wie viele "andere" es letztlich nutzen?

    Wenn ich ein Tool für mich schreibe werde ich definitiv golang benutzen. Wenn dann irgendwo Fehler auftreten reicht mir ein Stacktrace und ich weiss was los ist und kann es fixen.

    Wenn ich es aber auch der Community zur Verfügung stelle habe ich an mich den Anspruch es möglichst Bulletproof zu machen. Es ist ein grosser Aufwand sorgfältig alle möglichen Fehlermöglichkeiten mit Fehlermeldungen zu versehen sowie Benutzereingaben sorgfältig zu prüfen und sinnvolle Fehlermeldungen ausgeben. Je nach Umfang ist auch Logging sinnvoll um damit Probleme debuggen zu können so dass man einen Fix bauen kann. Diesen Aufwand treibe ich aber nur wenn ich weiss dass es sich lohnt.

  • Für mich ist es letztendlich in erster Linie immer eine Frage des Vertrauens. Go-Programme, die ich mir von Git-Hub oder sonstwo runterlade kompiliere ich immer selber und ich schau mir vorher den Source-Code genauer an. Anders beispielsweise beim Hypervisor LXD (unter Debian/Ubuntu, nicht Raspbian), der in Go geschrieben wurde, aber Teil der Linux Distro ist. Ich mach da aber eigentlich keinen Unterschied zu Programmen, die in anderen Sprachen geschrieben sind.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!