Google stellt neue Programmiersprache vor (GO)

[microkernel]

Hallo,
google hat eine neue Programmiersprache vorgstellt, namens "GO". (Golem, Go Website)
Also ich werde sie mir aufjedenfall mal näher anschauen...
Was haltet ihr davon?

[nemomuk]

Schaut interessant aus... wede mir das mit Sicherheit auch ansehen.

[BlackJack]

Bäh, ich weiss nicht wieso die bei Wikipedia im Zusammenhang mit Python gebracht wird. Statische Typisierung, geschweifte Klammern, keine Ausnahmen -- was hat der Mist mit Python zu tun? Sieht mir nach einem Marketingtrick aus.

[Leonidas]

Bäh, ich weiss nicht wieso die bei Wikipedia im Zusammenhang mit Python gebracht wird. Statische Typisierung, geschweifte Klammern, keine Ausnahmen -- was hat der Mist mit Python zu tun? Sieht mir nach einem Marketingtrick aus.

Dem muss ich mich anschließen. Neben der Kritik dass es mit Python mehr oder weniger überhaupt nichts zu tun hat, werfe ich noch ein, dass da überhaupt keine interessanten Konzepte drin sind, wie das etwa bei Nemerle oder Scala der Fall ist. Es ist einfach eine Sprache die wenn man von 3 Kilometern auf den Quelltext schaut, eine grobe Ähnlichkeit zu Python hat, mehr aber auch nicht.

[BlackVivi]

Bäh, ich weiss nicht wieso die bei Wikipedia im Zusammenhang mit Python gebracht wird. Statische Typisierung, geschweifte Klammern, keine Ausnahmen -- was hat der Mist mit Python zu tun? Sieht mir nach einem Marketingtrick aus.

*nachdenk* Ich seh eigentlich ... keine Ähnlichkeit. Keine anonymen Funktionen, nicht von Grund auf Objektorientiert... Vala und D hat mehr Gemeinsamkeiten mit Python als die Sprache. Wenn ich wirklich Systemnah programmieren möchte, nehme ich die.

Die Sache mit Unicode ist doof gelöst. Strings sind definiert als ein Array aus bytes - auch unicode. Wenn man also durchiteriert, bekommt man nur Mist. Man braucht spezielle Methoden dafür. Warum nicht gleich richtig? Wenn man schon eine neue Sprache entwickelt.

Die Syntax von Go ist ... stellenweise unverständlich für mich.

Man kann Variablen so deklarieren:

Code: Alles auswählen

var s string = "";

oder so

Code: Alles auswählen

var s = "";

oder so

Code: Alles auswählen

s := "";

Ist das schön? Das verstößt so ziemlich gegen alles, für das Python steht.

Für mich ist das C++. C++ mit weniger Objektorientierung. Also C in hässlich.

[nemomuk]

Naja, um eine Ähnlichkeit mit Python gehts mir da jetzt eigentlich nicht, habe dazu eigentlich auch noch nichts gelesen... vllt. liegt das auch daran, dass ich mich erst 19min damit beschäftigt habe... aber anschauen werde ichs mir trotzdem.

[BlackJack]

@BlackVivi: Anonyme Funktionen gibt es. Und objektorientiert ist es doch auch. Man kann ja sogar den Grunddatentypen neue Methoden hinzufügen.

Ich würde die Sprache ja mal ausprobieren, aber leider raucht einer der Tests mit einem Speicherzugriffsfehler ab. Scheint also auch ohne Zeigerarithmetik zu gehen.

[Defnull]

Die Sache mit dem implements finde ich persönlich ziemlich genial. So kann man das Vorhandensein von Interfaces überprüfen ohne sich auf bestimmte Typen oder komplizierte Objekthierarchien (die eh nie auf gehen) festlegen zu müssen. Das ist Duck-Typing done right. Wenn es quack() implementiert, ist es eine Ente. Und wenn ich einmal definiere, das alle Enten quaak() implementieren, dann ist auch jede Ente eine Ente. Punkt.

Implements sind genau DER Punkt, den ich liebend gerne auch in Python (oder anderen Script-sprachen) sehen würde. Die meisten Exceptions in meinem api code sind nämlich dazu da, AttributeError oder TypeError ab zu fangen. Das nervt echt. Ich hätte liebend gerne in der Sprache verankerte Typen- oder API Prüfungen. Damit es eben schon beim ersten Funktionsaufruf scheppert und nicht erst in einem speziellen Sonderfall.

Beispiel gefällig? cgi.FieldStorage geht davon aus, das der readline() Aufruf des Input-Objektes einen len-parameter akzeptiert. Das tun aber nicht alle Implementierungen. Folge: Eine nicht abgefangene Exeption tief in den Innereien eines furchtbar unübersichtlichen Moduls, aber auch nur dann, wenn der content-type der richtige ist und zig andere Rahmenbedingungen erfüllt sind. Robuste Software sieht anders aus.

[BlackVivi]

@BlackVivi: Anonyme Funktionen gibt es.

Echt? Wo?

Und objektorientiert ist es doch auch. Man kann ja sogar den Grunddatentypen neue Methoden hinzufügen.

Von der Seite:

Is Go an object-oriented language?

Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, not just structs.

Für mich ist das nicht wirklich objektorientiert. Zumindest gefällt es mir nicht...

[BlackJack]

@BlackVivi: Anonyme Funktionen gibt es im Tutorial gegen Ende und in der Sprachspezifikation unter der Überschrift Function literals.

Was ist denn daran nicht OOP? Immer dran denken, das OOP ein Konzept und keine Spracheigenschaft ist. Die Frage ist also immer wie man dieses Konzept in einer Programmiersprache umsetzen kann. Und für mich sieht's so aus, als würde es gehen. Deutlich besser als mit C, weil durch das "Embedding" so etwas wie Vererbung gemacht werden kann, ohne dass man ständig zu dem "Obertyp" casten muss, wenn man dort etwas aufrufen oder benutzen möchte. Ausser halt, wenn man eine Methode überschreibt und darin sie "Super"-Methode aufrufen möchte.

Da ich Go nicht kompiliert bekomme ist folgendes komplett ungetestet:

Code: Alles auswählen

type HasSomethingToSay interface {
    say();
}

type Person struct {
    Name string;
}

func (p *Person) say() {
    fmt.Printf("Hi, my Name is %s.\n", p.Name);
}

type Dog struct {
}

func (d *Dog) say() {
    fmt.Printf("Wuff\n");
}

type HyperActiveDog struct {
    Dog;
}

func (had *HyperActiveDog) say() {
    for i := 0; i < 5; i++ {
        had.Dog.say();
    }
}

[pillmuncher]

Was ist denn daran nicht OOP? Immer dran denken, das OOP ein Konzept und keine Spracheigenschaft ist. Die Frage ist also immer wie man dieses Konzept in einer Programmiersprache umsetzen kann.

http://c2.com/cgi/wiki?HeInventedTheTerm

Gruß,
Mick.

[BlackJack]

@pillmuncher: Mir ist nicht ganz klar was Du mit dem Link sagen willst.

Inheritance: Jup, Durch "Embedding".
Polymorphismus: Jup, über Interfaces und die "Receiver", die man bei den Methoden angibt.
Kapselung: Namensgebung steuert Sichtbarkeit.

Also nach Alan Kay's Kriterien unterstützt Go OOP, würde ich mal behaupten.

[BlackVivi]

Was ist denn daran nicht OOP? Immer dran denken, das OOP ein Konzept und keine Spracheigenschaft ist. Die Frage ist also immer wie man dieses Konzept in einer Programmiersprache umsetzen kann.

Das ist richtig und das weiß ich auch sehr wohl. Aber GO hilft einem in der Objektorientierung in vielerlei Dingen nicht, finde ich. Sie's nich so Objektorientiert wie Python oder Smalltalk. Eher so wie ... C mit'n paar Präprozessor-Sachen. Ansonsten kann man ja ASM auch Objektorientiert bezeichnen (was gar nicht so falsch ist. Gibt sogar Bücher darüber).

Nagut, ich drücks mal anders aus: Die Art, wie GO die Objektorierntierung syntaktisch unterstützt, gefällt mir nicht. Das mit den anonymen Funktionen hab ich nicht gesehen - schade. Nicht genug drauf geachtet. Verzeiht meine Unwissenheit

[pillmuncher]

@pillmuncher: Mir ist nicht ganz klar was Du mit dem Link sagen willst.

Nur das:

Inheritance: Jup, Durch "Embedding".
Polymorphismus: Jup, über Interfaces und die "Receiver", die man bei den Methoden angibt.
Kapselung: Namensgebung steuert Sichtbarkeit.

Also nach Alan Kay's Kriterien unterstützt Go OOP, würde ich mal behaupten.

Mick.

[sma]

@Leonidas, Go hat IMHO zwei interessante Konzepte: strukturelle Typen statt den sonst üblichen nominellen Typen und Goroutinen als Sprachkonzept für eingebaute Nebenläufigkeit. Beides gab es zwar auch schon in anderen Sprachen, doch keine davon hat es AFAIK in den "Mainstream" geschafft.

@blackvivi, was genau ist doof an deren UTF8-Unterstützung? Irgendwie muss man's machen und bei Java wollte man mittels UCS-16 jedes Unicode-Zeichen in einem "char" speichern, konnte dies aber auch nicht durchhalten nachdem es mehr als 65536 Zeichen gab und muss jetzt damit leben, dass Strings dort UTF-16 kodiert ist, was kaum ein Entwickler weiß oder gar berücksichtigt und daher funktionieren da eigentlich so gut wie keine Programme korrekt, wenn man mal die Basic-Plane verlassen würde. Auch keine gute Lösung. Daher also lieber gleich sagen, dass es nicht so einfach ist, in einen String hineinzu-indizieren und gut ist.

Go ist IMHO sehr wohl objektorientiert. Und ich bin mir sicher, Alan Kay würde zustimmen, denn für ihn war und ist der wichtigste Aspekt der Objektorientierung das "message passing", was nicht nur flexibel durch die selbst an (abgeleitete) Basistypen anfügbaren Methoden realisiert werden kann, sondern auch zwischen Goroutinen per Kanal.

Siehe letzte Bemerkung von http://c2.com/cgi/wiki?AlanKaysDefiniti ... ctOriented

Übrigens: Setzt man Prozesse gleich Objekte, ist auch Erlang sehr nah an der ursprünglichen Vision aus den 70ern (man vergleiche "he early history of Smalltalk", wo noch von von aktiven miteinander kommunizierenden Objekten die vergleichbar mit Prozessen wären gesprochen wird).

Objektorientierung heißt (für mich) nicht, dass es zwingend Klassen oder Vererbung gibt. Das ist eine späte, leider auch von Lehrbüchern verfremdende Definition, die nicht der ursprünglichen Idee folgt, auch wenn es selbst von Kay mal so eine Definition gab. Die IMHO reinste OO-Sprache ist Self und da gibt es weder Klassen noch Vererbung, sondern nur Objekte und Delegation. Self war übrigens auch das Vorbild für JavaScript.

Wichtig finde ich noch den Aspekt, dass Go ja C als Systemprogrammiersprache ablösen will. Auf dieser Ebene Garbage Collection einzuführen finde ich wichtig und überfällig, ist aber sicherlich auch mutig, denn in C/C++-Umfeld leben glaube ich ich ettliche Leute noch in dem Glauben, dass sie den Programmspeicher besser und effizienter verwalten könnten, als die Sprache selbst. Nebenläufigkeit auf Sprachebene (ähnlich - mit Threads in der Sprache - fing ja auch Java vor 15 Jahren an) ist auch ein wichtiger und aus C-Sicht innovativer Aspekt, der die Sprache fit für eine Zukunft macht, in der jeder Prozessor 4, 8 oder noch mehr Kerne haben wird.

Stefan

[sma]

Hier sind noch zwei interessante Blogbeiträge zu Go: 1 und 2.

Stefan

[Darii]

So wirklich zusagen tut mir Go nicht. Die Schleifen haben sie ja gründlich versiebt, da wäre ein zusätzliches Python-For + while besser gewesen.

Ein kleines, simples Objektmodell hätte Go wohl auch nicht geschadet. Dazu kommt ich bin ein großer Fan von Operatorüberladung

[sma]

Das "for" in C ist ja nur ein Makro für "while". Ein "for(i=0; i< 10; i++)", bei dem man nur den mittleren Teil braucht entspricht dem while. Kann man also auch umdrehen. Ob man nun "for(;i<10;)" oder wie in Go "for i < 10" schreibt, ist doch egal. Und da sie das fehleranfällige "if (c=getc())" durch "if c=getc(); c != 0" ersetzt haben, was für while dann "while c = getc(); c != 0" wäre was "zufällig" genau dem "for" entspricht, ist es doch konsequent, auf das Schlüsselwort "while" zu verzichten.

Go hat ein kleines simples Objektmodell. Zustand kann man in structs halten, Verhalten mit Methoden implementieren.

Und wo kann man Operatoren überladen (oder sonst welche Funktionen)? Im Gegenteil, das Fehlen der Möglichkeit, eigene Datentypen mit "+", "-", usw. zu bearbeiten ist ein berechtigter der Kritikpunkt der Attitüde "ihr dürft nicht, was wir dürfen", die sich leider durch die Sprache zieht.

Stefan

[Darii]

Das "for" in C ist ja nur ein Makro für "while". Ein "for(i=0; i< 10; i++)", bei dem man nur den mittleren Teil braucht entspricht dem while. Kann man also auch umdrehen. Ob man nun "for(;i<10;)" oder wie in Go "for i < 10" schreibt, ist doch egal. Und da sie das fehleranfällige "if (c=getc())" durch "if c=getc(); c != 0" ersetzt haben, was für while dann "while c = getc(); c != 0" wäre was "zufällig" genau dem "for" entspricht, ist es doch konsequent, auf das Schlüsselwort "while" zu verzichten.

Ich persönlich finde "while condition" einfach eingänglicher als "for condition". Sie hätten statt das c-for irgendwie zu verbessern ein for einbauen können, dass über Iteratoren iteriert wie in Python, statt dieses komische range einzubauen, dass sowieso nur bei eingebauten Datentypen funktioniert. Ich zähle ja for ... in ... und yield mit zu den besten Sprachfeatures in Python. Hier hat sich auch jemand mal die Mühe gemacht, das für C(+Blöcke) nachzubasteln.

Mit den Interfaces hätten sie ja die Möglichkeit ein generisches Iteratorprotokoll zu implementieren(wobei das glaube ich so einfach auch nicht möglich ist, da Go keine Typinferenz bietet).

Go hat ein kleines simples Objektmodell. Zustand kann man in structs halten, Verhalten mit Methoden implementieren.

Hmm ich glaube diese Interfaces könnten etwas sein, was ganz bauchbar ist.

Und wo kann man Operatoren überladen (oder sonst welche Funktionen)? Im Gegenteil, das Fehlen der Möglichkeit, eigene Datentypen mit "+", "-", usw. zu bearbeiten ist ein berechtigter der Kritikpunkt der Attitüde "ihr dürft nicht, was wir dürfen", die sich leider durch die Sprache zieht.

Kann man nicht, das war ja auch mein Kritikpunkt, war bloß etwas in Eile deswegen war das so knapp. Ich finde Go ist nichts ganzen und nichts halbes, es hat einige nette Ansätze aber geht imo nicht weit genug, um eine Alternative zu C/C++ zu sein.