Hi, die ja noch eher junge Sprache Go macht auf mich einen ziemlich interessanten Eindruck. Weil ich ET studiere aber danach im Job gerne Software machen würde sollte ich Sprachen, in die ich mich einarbeite, danach auswählen, was die Firmen einsetzten und wofür und was gefragt ist - vor allem eben weil Softwareentwicklung im ET-Studium dünn gesäht ist. Hat jemand von euch einen Ein- oder Überblick, wo in Deutschland Go wofür eingestzt wird und vor allem, wie stark es verbreitet ist? Danke!
Einen groben Überblick erhältst du hier: https://github.com/golang/go/wiki/GoUsers https://github.com/golang/go/wiki/SuccessStories Aber darauf bist du bei deiner Suche vermutlich auch schon gestoßen.
:
Bearbeitet durch Moderator
Wenn Du ET studierst und Softwareentwicklung machen möchtest, vermute ich daß Du in den Bereich Embedded-Software gehen möchtest. Dafür halte ich Go für ungeeignet. Denn das Speichermodell erschwert den direkten Hardwarezugriff sehr. Der Einsatz eines Garbage Collectors ist oft riskant, da schnell der Speicher ganz ausgehen kann. Auch für größere Embedded-Prozessoren halte ich Go für ungeeignet, da es keine Shared Libraries verwenden kann, sondern jedes Programm immer komplett statisch zusammengelinkt werden muss. Das kostet unnötig RAM. Auch kannst Du bestehende Libs von Herstellern oder Drittanbietern (z.B. QT für Grafik) nur sehr schwer einbinden. Für Embedded solltest Du in C und C++ sattelfest sein. Ich könnte mir gut vorstellen, daß Rust in Zukunft weitere Verbreitung erfährt. Oder möchtest Du Softwareentwicklung vor allem für klassische PCs und Server machen?
:
Bearbeitet durch User
Ich habe schon in einem mittleren Unternehmen (ca. 100 MA) Embedded-Software in Go geschrieben. Den Namen nenne ich nicht, bin nicht sicher ob diese Information als strategisch öffentlich betrachtet wird. In dem Fall ist "Embedded" aber natürlich als "größerer µC mit Betriebssystem" zu verstehen, Bare-Metal Go macht eher wenig Sinn. Gerd E. schrieb: > Der Einsatz eines Garbage Collectors ist > oft riskant, da schnell der Speicher ganz ausgehen kann. Naja, geht so. Du darfst halt keine Leaks einbauen, dann lässt sich nach oben abschätzen, wie viel der GC mehr belegen kann als tatsächlich in Verwendung ist. > Auch für > größere Embedded-Prozessoren halte ich Go für ungeeignet, da es keine > Shared Libraries verwenden kann, sondern jedes Programm immer komplett > statisch zusammengelinkt werden muss. Das kostet unnötig RAM. Das Argument kann ich nicht nachvollziehen. Warum soll statisches Linken mehr RAM benötigen als dynamisches? Eher das Gegenteil ist der Fall, da der Linker alle nicht benötigten Symbole aus dem Executable entfernen kann, sodass diese weder geladen noch überhaupt gespeichert werden. Das geht bei dynamischem Linken nicht. Blöd ist lediglich, wenn man mehrere Executables haben möchte, was ja durchaus vorkommen kann. Ich würde dann einfach einen "main"-Wrapper schreiben, der abhängig vom übergebenen Argument das eine oder andere Programm ausführt.
:
Bearbeitet durch User
Sven B. schrieb: >> Auch für >> größere Embedded-Prozessoren halte ich Go für ungeeignet, da es keine >> Shared Libraries verwenden kann, sondern jedes Programm immer komplett >> statisch zusammengelinkt werden muss. Das kostet unnötig RAM. > > Das Argument kann ich nicht nachvollziehen. Warum soll statisches Linken > mehr RAM benötigen als dynamisches? Wenn ich eine shared Lib in mehreren Programmen dynamisch linke, muss sie hinterher nur einmal im Speicher liegen. > Blöd ist lediglich, wenn man mehrere Executables haben möchte, was ja > durchaus vorkommen kann. Ich würde dann einfach einen "main"-Wrapper > schreiben, der abhängig vom übergebenen Argument das eine oder andere > Programm ausführt. Dann müssten diese anderen Programme aber auch alle in Go geschrieben sein. Sagen wir mal Du hast ein System, welches aus Backend (macht die eigentliche Arbeit), GUI und Webserver besteht, das wären dann 3 Executables. Von mir aus machst Du Gui und Backend in Go. Aber den Webserver möchtest Du nicht selbst machen, sondern nimmst einen fertigen in einer anderen Sprache. In allen 3 Programmen musst Du aber Verbindungen zu externen Webservern machen um Daten abzufragen und dafür linkst Du dann OpenSSL. Das OpenSSL ist damit dann 2x im Speicher. Bei den Produkten die wir in der Firma herstellen wird eine Vielzahl von Opensource-Projekten verwendet und die werden dann miteinander verknüpft und mit einer schönen Oberfläche versehen. Die sind in vielen verschiedenen Sprachen geschrieben. Viele gängige Libs (wie das genannte OpenSSL, aber noch ne ganze Menge mehr) werden direkt oder indirekt von vielen dieser Projekte gemeinsam genutzt und sind hinterher nur einmal im RAM. Go-Programme sind da eigentlich die einzige Ausnahme und oft echte Speicherfresser und daher bei uns nicht gerne gesehen.
Gerd E. schrieb: > Das OpenSSL ist damit dann 2x im Speicher. Das wäre richtig, wenn Go OpenSSL verwenden würde, was es nicht tut ;) Die TLS-Implementierung ist in Go geschrieben. Da die gängigen Go-Bibliotheken, gerade für Embedded, eh fast nichts bekanntes externes verwenden, ist das dynamic linking-Argument zwischen Go- und nicht-Go-Anwendungen auch irgendwie hinfällig. Man kann natürlich ein anderes Fass daraus aufmachen, aber dynamic linking würde hier nicht helfen.
:
Bearbeitet durch User
Gerd E. schrieb: > Wenn Du ET studierst und Softwareentwicklung machen möchtest, vermute > ich daß Du in den Bereich Embedded-Software gehen möchtest. Embedded wäre nur eine Möglichkeit von vielen, und Embedded heißt nicht gleich "kleiner µC". Das können durchaus auch linuxbasierte ARM oder sogar x86-Systeme sein. Da sind grundsätzlich alle Programmiersprachen denkbar, also auch Go. Außerdem gibt es natürlich auch Elektroingenieure, die PC-Software entwickeln, z.B. für Simulation. Sprachen wie Matlab und Python sind da sehr weit verbreitet. Go wäre aber auch denkbar. Aber eigentlich spielt es ja auch keine große Rolle, welche Sprache man nutzt. Es schadet nicht, sich mal eine neue Sprache anzuschauen, wenn sie interessant klingt. Dadurch lernt man, flexibel zu sein. Wenn man im Berufsleben mit einer völlig neuen Programmiersprache konfrontiert wird, ist das ein Vorteil.
Sven B. schrieb: > Ich habe schon in einem mittleren Unternehmen (ca. 100 MA) > Embedded-Software in Go geschrieben. Warum? Ich meine: so eine Wahl muss doch wenigstens an irgendeiner Stelle irgendeinen Nutzeffekt erzeugen. Oder doch zumindest eine berechtigte Hoffnung auf einen solchen...
Antonia W. schrieb: > Hat jemand von euch einen Ein- oder Überblick, wo in Deutschland Go > wofür eingestzt wird Webservices die man dann in einen Container schmeisst. Geht aber auch mit jeder anderen Sprache. Go kompiliert halt in ein binary, man muss sonst nix bereitstellen, das ist auf den ersten Blick ein Vorteil, in der Praxis ist es egal ob ich noch 120 andere Dateien in den Container werfe. > und vor allem, wie stark es verbreitet ist? Im obigen Bereich etwas verbreitet, verglichen mit anderen Sprachen. Der Hype ist längst verpufft und go längst wieder auf dem absteigenden Ast. In .de ist der kurze Hype sowieso nie richtig angekommen. Oben schrieb jemand er hat es im embeddedbereich verwendet, ist glaube das ist ein noch viel exotischer Anwendungsfall, ausser embedded = fetter linuxbasierter Controller. Schau dir lieber relevantere Sprachen in deiner Domäne an und berherrsche diese im Schlaf, das ist wichtiger als 20 verschiedene nur oberflächlich zu kennen. Go bietet nix grundlegend neues ausser dass es etwas einfacher ist.
Antonia W. schrieb: > Weil ich ET studiere aber danach im Job gerne Software machen > würde sollte ich Sprachen, in die ich mich einarbeite, danach > auswählen, was die Firmen einsetzten und wofür und was gefragt ist Dann würde ich an deiner Stelle in jedem Fall erstmal mit C anfangen, sowie die Grundlagen von C++ oben drauf (nicht unbedingt kompliziert). Damit fährst du deutlich breiter - mit Go alleine bist du eher ein One-Trick-Pony. Auch, wenn es da recht coole Dinge gibt. Wie es dann weitergeht, hängt von der konkreten Firma ab, bei der du landest. In meinem Fall zählen z.B. grundlegendes Java bzw. Kotlin dazu, die man da eher nicht einordnet. Aber die Android-Plattform zählt auch unter Embedded (viel C++), und da muss man gelegentlich auch kleine Apps zusammenpfuschen und fremde Apps flicken können.
c-hater schrieb: > Sven B. schrieb: > >> Ich habe schon in einem mittleren Unternehmen (ca. 100 MA) >> Embedded-Software in Go geschrieben. > > Warum? > > Ich meine: so eine Wahl muss doch wenigstens an irgendeiner Stelle > irgendeinen Nutzeffekt erzeugen. Oder doch zumindest eine berechtigte > Hoffnung auf einen solchen... Gibt immer Argumente dafür und dagegen. Dafür spricht z.B. - go ist eine der wenigen Sprachen die die Nische "automatisches Memory-Management, statisch stark typisiert, erzeugt beim Kompilieren native Binaries ohne externe VM" füllt. Mir fällt spontan gar keine andere ein. Vielleicht sowas wie Haskell. Trotzdem sind aber alle drei Eigenschaften u.U. für ein Embedded-System wünschenswert. - Wenn es so ein bisschen Richtung Sicherheit geht, ist go vermutlich nicht schlecht, weil es einige der Fehlerklassen aus C ausschließt, insb. die ganzen Memory-Corruption-Probleme. - umfangreiche Standardbibliothek, die sehr viel Kram mitbringt (zB TLS, HTTP, eine Template-Engine, XML-Parser, ...), was auch einfach viel Nachdenken und Diskussionen spart, welche externe Bibliothek jetzt denn benutzt werden soll - insb. verglichen mit C/C++ sehr einheitliches Code-Bild, die Sprache ist wirklich sehr klein und sehr streng damit, was man wie machen kann. Naja. So der ultimative Verfechter dass es die perfekte Wahl ist bin ich jetzt nicht, aber ich glaube Python oder Java wären schlechter geeignet.
:
Bearbeitet durch User
Go gibt's wohl auch "bare metal" für Embedded https://github.com/inversepath/tamago-go https://media.ccc.de/v/36c3-10597-tamago_-_bare_metal_go_framework_for_arm_socs
Hier noch ein paar Gründe, warum man sich den Einsatz von go sehr gut überlegen sollte: https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.