1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Rust: Ist die neue…

Go

  1. Thema

Neues Thema Ansicht wechseln


  1. Go

    Autor: embr 14.06.16 - 12:12

    Go sehe ich als einzig würdigen Konkurrent zu C++, auf Rust bin ich die nächsten Jahre über mal gespannt. Vor allem, ob und wenn ja welche massiven Frameworks sich damit noch entwickeln.

  2. Re: Go

    Autor: peter.kleibert 14.06.16 - 12:29

    Ich mag auch GO aber wegen anderen Vorzügen. Ich bin mir jedoch nicht sicher, ob GO auf System-Ebene wirklich brauchbar ist, da habe ich meine Zweifel, aber da bin ich auch nicht der Richtige um das zu beurteilen.

    Für mich sehr schön ist die stark vereinfachte Objekt-Orientierung. Bis anhin kam bei der Einführung mit Java mit unseren Programmier-Neulingen mindestens 10 mal pro Tag der Satz "Das ist wegen der Objektorientierung, das kann ich erst erklären, wenn ihr Grundlagen intus habt".
    Da habe ich jetzt mit GO wesentlich bessere Erfahrungen gemacht. Es ist viel einfacher verständlich als das komplette OO-Konzept.

  3. Re: Go

    Autor: Steffo 14.06.16 - 12:32

    Go ist keine Systemprogrammiersprache wegen dem GC und bietet auch nicht die Sicherheitsgarantien, die rust bietet. Insofern ist Go keine Konkurrenz zu rust.

  4. Re: Go

    Autor: crypt0 14.06.16 - 13:35

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > Go ist keine Systemprogrammiersprache wegen dem GC [...]

    Das ist eine mehr als gewagte Behauptung - der golang-gc ist schließlich auch in Go geschrieben... (Non-heap memory management)
    Go forciert die "Systemprogrammierung" nicht so wie Rust - ja, aber das heißt nicht, dass man sie dafür nicht einsetzen kann - Die alte Aussage: "GC und Systemsprache schließen sich aus" ist einfach nicht richtig / zeitgemäß

  5. Re: Go

    Autor: Steffo 14.06.16 - 13:42

    crypt0 schrieb:
    --------------------------------------------------------------------------------
    > Steffo schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Go ist keine Systemprogrammiersprache wegen dem GC [...]
    >
    > Das ist eine mehr als gewagte Behauptung - der golang-gc ist schließlich
    > auch in Go geschrieben... (Non-heap memory management)
    > Go forciert die "Systemprogrammierung" nicht so wie Rust - ja, aber das
    > heißt nicht, dass man sie dafür nicht einsetzen kann - Die alte Aussage:
    > "GC und Systemsprache schließen sich aus" ist einfach nicht richtig /
    > zeitgemäß

    Du kannst einen Compiler in jeder beliebigen Sprache schreiben. Der Java-Compiler ist auch in Java geschrieben, trotzdem ist Java keine Systemsprache in der du Treiber, geschweigedenn ein OS programmierst. Gerade was Realtime angeht, schließt das GC-Sprachen einfach aus. Gleiches gilt für Mikrocontroller wo du bspw. nur wenige kb RAM hast.

  6. Re: Go

    Autor: mnementh 14.06.16 - 13:45

    Steffo schrieb:
    --------------------------------------------------------------------------------
    > crypt0 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Steffo schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Go ist keine Systemprogrammiersprache wegen dem GC [...]
    > >
    > > Das ist eine mehr als gewagte Behauptung - der golang-gc ist
    > schließlich
    > > auch in Go geschrieben... (Non-heap memory management)
    > > Go forciert die "Systemprogrammierung" nicht so wie Rust - ja, aber das
    > > heißt nicht, dass man sie dafür nicht einsetzen kann - Die alte Aussage:
    > > "GC und Systemsprache schließen sich aus" ist einfach nicht richtig /
    > > zeitgemäß
    >
    > Du kannst einen Compiler in jeder beliebigen Sprache schreiben. Der
    > Java-Compiler ist auch in Java geschrieben, trotzdem ist Java keine
    > Systemsprache in der du Treiber, geschweigedenn ein OS programmierst.
    > Gerade was Realtime angeht, schließt das GC-Sprachen einfach aus. Gleiches
    > gilt für Mikrocontroller wo du bspw. nur wenige kb RAM hast.

    Ich nehme an golang-gc meint den Garbage Collector, nicht den Compiler.

    Ich sehe nicht, dass ein Garbage Collector Systemprogrammierung unmöglich macht, man kann auch GC-Implementierungen haben die Realtime-Anforderungen genügen.

    Aber abgesehen davon ist das gar nicht das Ziel von Go. Go soll für die Anwendungsprogrammierung sein. Es macht auch Sinn getrennte Sprachen für System- und Anwendungsprogrammierung zu haben. Viele sind nur zu faul verschiedene Sprachen zu lernen und nehmen halt den Hammer den sie kennen um die Schraube festzumachen. IMHO hätte beispielsweise C nie in dem Maße für Anwendungsprogrammierung genutzt werden sollen. Aber gut, zu spät.

  7. Re: Go

    Autor: demonkoryu 14.06.16 - 13:49

    Ich hatte urspruenglich mal vor, in go mein Hobby-OS weiterzuschreiben, aber systemnahe Programmierung ist damit ein Graus. Keine Alternative in der Hinsicht zu C oder C++.

  8. Re: Go

    Autor: pythoneer 14.06.16 - 14:48

    Ich habe eine Zeit lang in Go programmiert und fand es auch echt super – am Anfang. Nach einer weile steht Go einem nur noch im Wege und bin jetzt glücklicher Rust "user". Da ich weder Go noch Rust momentan produktiv einsetzen kann und nur als Hobby pflege habe ich auch keine Probleme damit, wenn das ein oder andere noch nicht so läuft sonder sehe da eher das potenzial, was bei Rust meiner Meinung nach viel größer ist. Go ist einfach populärer weil es sehr von Google getragen wurde und es macht auch Spaß es zu lernen weil die Sprache ziemlich einfach ist. Aber bei größeren Sachen macht die Explizitheit von Rust einfach mehr Sinn. Gerade was das Typsystem angeht. Affine Typen algebraische Typen etc. sind einfach Gold wert wenn man sichere API's schreibt. Außerdem habe ich Go verlassen, weil es damals keine generische Typisierung gab, sowas ist für mich einfach ein Ausschlusskriterium wenn es um produktives Programmieren geht. Für mich persönlich ist der Go Zug abgefahren nachdem ich es eine weile benutzt habe. Interessanterweise höre ich das von immer mehr Leuten, die mal Go versucht haben – dass sie anfangs sehr angetan waren aber später ziemlich enttäuscht.



    1 mal bearbeitet, zuletzt am 14.06.16 14:51 durch pythoneer.

  9. Re: Go

    Autor: shoggothe 15.06.16 - 00:04

    Ein paar Punkte

    a. Es gibt JavaCard für Chipkarten mit 16-32KiB Speicher. Das ist ganz normales Java, das man mit jeder Java-IDE/javac kompiliert. Es gibt nur Hinweise wie man programmieren sollte, um GCs zu vermeiden. Das Schlüssewort new nur im Constructor / bei Memberinitialisierung verwenden. Objekte, wenn möglich, immer wieder verwenden.

    b. Go ist deshalb schon besser zur Systemprogrammierung geeignet, weil es Wertetypen/Structs unterstützt, die ohne irgendwelche Metadaten direkt auf Speicher abbilden. In Java gibt es die fest definierten primitiven Typen und fette Objekte (Java 10 soll aber Wertetypen einführen).

    c. Der Go-GC ist mittlerweile schnell. Man liest in Veröffentlichungen von 4-10 ms, selbst in Programmen mit mehreren 100 GiB Heap (Tweets und Präsentationen). Und wie schon bei JavaCard kann man Garbage aktiv vermeiden.

    Edit: ein Tweet https://twitter.com/brianhatfield/status/692778741567721473

    d. Manuelle Speicherverwaltung ist auch nicht Echtzeit-geeignet, wenn malloc in einem fragmentierten Heap undefiniert lange nach einem freien Speicherbereich suchen muss.



    1 mal bearbeitet, zuletzt am 15.06.16 00:09 durch shoggothe.

  10. Re: Go

    Autor: jungundsorglos 15.06.16 - 09:10

    > a. Es gibt JavaCard für Chipkarten mit 16-32KiB Speicher. Das ist ganz
    > normales Java, das man mit jeder Java-IDE/javac kompiliert.
    > Es gibt nur
    > Hinweise wie man programmieren sollte, um GCs zu vermeiden.
    So dass man die Vorteile des GCs also aufgibt. Die meisten Bibliotheken lassen sich so nicht verwenden, geschweige denn übliche Javaidiome. Was bringt es dann noch?
    Siehe unten.

    > b. Go ist deshalb schon besser zur Systemprogrammierung geeignet, weil es
    > Wertetypen/Structs unterstützt, die ohne irgendwelche Metadaten direkt auf
    > Speicher abbilden. In Java gibt es die fest definierten primitiven Typen
    > und fette Objekte (Java 10 soll aber Wertetypen einführen).
    Rust kann das nicht? Soweit mir bekannt werden die Metadaten während der Compilierung verwendet, nicht zur Laufzeit.

    > c. Der Go-GC ist mittlerweile schnell. Man liest in Veröffentlichungen von
    > 4-10 ms, selbst in Programmen mit mehreren 100 GiB Heap (Tweets und
    > Präsentationen). Und wie schon bei JavaCard kann man Garbage aktiv
    > vermeiden.
    4-10 ms sind im Echtzeitbereich sehr viel. Außerdem braucht man da garantierte Laufzeiten, nicht durchschnittliche oder übliche.
    Man kann natürlich einen Puffer allozieren und diesen dann für die gesamte Dauer der Echtzeitberechnungen/Capturen verwenden... Aber dann macht man eben doch wieder alles "zu Fuß".

    > d. Manuelle Speicherverwaltung ist auch nicht Echtzeit-geeignet, wenn
    > malloc in einem fragmentierten Heap undefiniert lange nach einem freien
    > Speicherbereich suchen muss.
    Dafür kann man ja einen Speichermanager schreiben, bzw. einen Teil des Heaps allozieren, oder je nach Größe unterschiedliche Heaps anlegen um die Fragmentierung auszuschließen.
    Das lässt sich alles relativ leicht erreichen, und man kann dann normal programmieren, ohne Verrenkungen. Es ist auch klar ersichtlich wann Speicher alloziert und freigegeben wird, und somit einfacher Laufzeitverhalten zu beschreiben.

    Wenn man das noch explizit annotieren könnte, dann wäre das natürlich noch besser. Aber eine Sprache so zu "mißbrauchen" dass sie sich so verhält wie gewünscht, indem man ihre eigentliche Speicherverwaltung durch vorsichtiges Verwenden gewisser Idiome umschifft, ist keine guter Stil. Hacks sollten nicht die Basis eines Designs sein.

    Wenn man die Sprache nicht gemäß ihrer natürlichen Idiome verwenden kann, hat es auch keinen Vorteil mehr dies zu tun, bis darauf dass man sagen kann, dass es auch mit dieser Sprache geht.

    Gute Programme sind offensichtlich in ihren Absichten und beschreiben diese so explizit wie möglich, ohne Hacks. Ein gutes Sprachdesign erlaubt es dann sich auch kurz auszudrücken, weil gewisse Vereinbarungen getroffen und so allgemeingültig sind, dass man sie lernen und verinnerlichen kann, ohne zig. Sonderregeln beachten zu müssen.
    Hacks brechen diesen Vertrag und damit die Klarheit, und sind daher eine Notlösung oder nette Spielerei.

  11. LOL

    Autor: Hello_World 15.06.16 - 10:56

    Eine Sprache mit GC und ohne Generics/Templates als Konkurrenten für C++ zu bezeichnen… Keine Ahnung, aber davon eine Menge :D

  12. Re: Go

    Autor: zZz 23.06.16 - 15:22

    Ich erinnere mich an einen Artikel (Wired?), in dem die Dropbox-Macher ihre Entscheidung damit begründen, anstelle von Go auf Rust zu setzen, weil Go zuviel RAM verbrauchen würde. Zugegeben, Dropbox ist sicher ein extremes Beispiel, weil extreme Anforderungen und deshalb nicht unbedingt mit 08/15-Projekten vergleichbar.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BIM Berliner Immobilienmanagement GmbH, Berlin
  2. Deutsche Forschungsgemeinschaft e. V., Bonn
  3. Lebensversicherung von 1871 a. G. München, München
  4. RheinEnergie AG, Köln

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (aktuell u. a. Noblechairs Hero Limited Gaming-Stuhl für 299€, Intel Core i9-9900K 3,6 GHz für...
  2. (Gaming-PCs & Notebooks, Gaming-Zubehör, Virtual Reality, Spielkonsolen und vieles mehr)
  3. 39,99€ statt 47,51€ im Vergleich
  4. (aktuell u. a. Seagate Firecuda Hybrid 2TB für 74,90€, Transcend 220S 512GB PCIe-SSD für 87...


Haben wir etwas übersehen?

E-Mail an news@golem.de


CPU-Fertigung: Intel hat ein Netburst-Déjà-vu
CPU-Fertigung
Intel hat ein Netburst-Déjà-vu

Über Jahre hinweg Takt und Kerne ans Limit treiben - das wurde Intel einst schon beim Pentium 4 zum Verhängnis.
Eine Analyse von Marc Sauter

  1. Comet Lake H Intel geht den 5-GHz-Weg
  2. Security Das Intel-ME-Chaos kommt
  3. Intel Arctic Sound Xe-HP-Grafik-Chiplets benötigen bis zu 500 Watt

Verschlüsselung: Ist die Crypto AG wirklich Geschichte?
Verschlüsselung
Ist die Crypto AG wirklich Geschichte?

Der Fall der Crypto AG wirbelt in der Schweiz immer noch Staub auf. In Deutschland hingegen ist es auffallend still.
Eine Analyse von Christiane Schulzki-Haddouti

  1. Schweizer Crypto AG Wie BND und CIA eine Verschlüsselungsfirma hackten
  2. Bundesverfassungsgericht Was darf ein deutscher Auslandsgeheimdienst?
  3. Gerichtsverfahren Bundesregierung verteidigt Auslandsspionage des BND

Dell Ultrasharp UP3218K im Test: 8K ist es noch nicht wert
Dell Ultrasharp UP3218K im Test
8K ist es noch nicht wert

Alles fing so gut an: Der Dell Ultrasharp UP3218K hat ein schön gestochen scharfes 8K-Bild und einen erstklassigen Standfuß zu bieten. Dann kommen aber die Probleme, die beim Spiegelpanel anfangen und bis zum absurd hohen Preis reichen.
Von Oliver Nickel

  1. Dell Anleitung hilft beim Desinfizieren von Servern und Clients
  2. STG Partners Dell will RSA für 2 Milliarden US-Dollar verkaufen
  3. Concept Duet und Concept Ori Dells Dualscreen-Geräte machen Microsoft Konkurrenz