Wie seht ihr die Changen von Google Go?

[Saxo]

Du meinst Go ist nicht gut in der Objekt-Orientierung. Das ist nur auf den ersten Blick so. Es hat auch Klassen. Sie werden nur etwas unorthodox deklariert. Go hat zwar keine Vererbung, keine einfache oder multiple. Es hat auch keine Traits und keine Mixins. Die Delegates in Go erschlagen das aber alles. Ich entwickle seit 20 Jahren objekt-orientiert. Ich weiß also schon was Vererbung ist. Die Delegates in Go sind eine geniale Idee. Der ganze Schmodder wird dadurch ersetzt. Ist eine geniale Vereinfachung. Wenn man sich dagegen Scala anguckt: eine katastrophe wie aufgeblasen diese Sprache ist...

-- Saxo

[volkard]

Dein Wort interessiert mich. Kannste mir eine gute Seite empfehlen, die OO in Go mit erzählt? In der Tat hatte ich das wohl übersehen, weil ich es zu oberflächlich anschaute.

[Saxo]

Dieser Link ist ganz gut: http://www.infoq.com/articles/google-go-primer Gibt ein Kapitel "Object Orientation", siehe unter "Inheritance".

[volkard]

Saxo schrieb:

Dieser Link ist ganz gut: http://www.infoq.com/articles/google-go-primer Gibt ein Kapitel "Object Orientation", siehe unter "Inheritance".

thx. Das wird meine perfekte Nachtlektüre. Bis morgen.

[Mechanics]

In dem Zusammenhang hab ich grad das hier gefunden:

http://ecs.victoria.ac.nz/twiki/pub/Main/TechnicalReportSeries/ECSTR11-01.pdf

Nicht uninteressant, wenn man sich ernsthaft mit Go und OOP beschäftigen will. Trotzdem, ich seh keinen Bedarf dafür.

[Saxo]

Super Link, danke! Ich hatte vor mit der @Delegate AST-Transformation in Groovy diese Delegates in Go zu simulieren um so besser erkennen zu können, ob sich Vererbung und alles so umsetzen lässt.

In dem http://www.infoq.com/articles/google-go-primer - Artikel, gibt es diesen Abschnitt:

type Base struct {}
func (Base) Magic() { fmt.Print("base magic") }
func (self Base) MoreMagic() {
self.Magic()
self.Magic()
}

type Foo struct {
Base
}
func (Foo) Magic() { fmt.Print("foo magic") }

When you create a Foo object, it will respond to both methods that Base does. However, when you call MoreMagic you will not get the results you expect:

f := new(Foo)
f.Magic() //=> foo magic
f.MoreMagic() //=> base magic base magic

Dass in der letzten Zeile "base magic base magic" rauskommt statt "foo magic foo magic", ändert in Go die Umsetzung für viele Dinge wie sie "traditionell" in OOP-Spraachen umgesetzt werden. Schauen wir mal, was in dem Dokument von der Uni Wellington so geschreiben wird ;-).

[Saxo]

Was mich noch erstaunt, ist, wie ungezwungen die Leute im Forum hier offensichtlich sowol mit Java und/oder C# ihr Geld verdienen. Ich kenne nur die reinen Java-Läden, wo mit M-Produkten arbeiten nicht mit der Entwickler-Ehre vereinbar ist. Nicht, weil man als Java-Entwickler nicht mit C# entwickeln darf, sondern weil die Leute bei Microsoft nur an M denken ...

Ich denke Ahnung von Java als auch C# nützt einem wohl nur als Freelancer was, oder? I.d.R. sind die Firmen entweder ganz auf Java oder .NET ausgerichtet und haben keine Mischung dazwischen ...

-- Saxo

[Zeus]

Saxo schrieb:

Super Link, danke! Ich hatte vor mit der @Delegate AST-Transformation in Groovy diese Delegates in Go zu simulieren um so besser erkennen zu können, ob sich Vererbung und alles so umsetzen lässt.

In dem http://www.infoq.com/articles/google-go-primer - Artikel, gibt es diesen Abschnitt:

Dass in der letzten Zeile "base magic base magic" rauskommt statt "foo magic foo magic", ändert in Go die Umsetzung für viele Dinge wie sie "traditionell" in OOP-Spraachen umgesetzt werden. Schauen wir mal, was in dem Dokument von der Uni Wellington so geschreiben wird ;-).

Das zeigt doch nur, dass man in Go nicht überschreiben kann.

[Saxo]

Das zeigt doch nur, dass man in Go nicht überschreiben kann.

Yep. Gibt mir auch zu denken. Frage ist, ob das für System-Programmierung nicht so tragisch ist. Ich weiss nicht, warum sie das gemacht haben. Hält den Compiler simpel und damit hat man kurze Build-Zeiten oder Late Binding will man nicht, weil es auf die Laufzeit-Performance geht?

[volkard]

Also muß man sich die Laufzeitpolymorphie auf die harte Tour selber bauen wie in C?
Außer dem eingebauten Multithreading-Zeugs sehe ich an Go jetzt Vorteil gegenüber C.

[Saxo]

Also muß man sich die Laufzeitpolymorphie auf die harte Tour selber bauen wie in C?

Ähm, und wie würde man das machen? Nur aus Interesse ;-).

Außer dem eingebauten Multithreading-Zeugs sehe ich an Go jetzt Vorteil gegenüber C.

Naja, die Build-Zeiten sind schon ein Punkt. Aber ein C oder C++-Projekt muss schon eine ziemliche Code-Größe erreichen bis das wirklich anfängt ein ernstes Thema zu werden. Ein anderer Punkt ist noch die Sicherheit: einen Garbage Collector zu haben löst eine große Zahl von Stabilitätsproblemen wegen falsche Deallozierung. Macht ziemlich Aufwand das von Anfang an richtig zu machen oder im Nachhinein die Bugs zu finden. Da hat auch D seine Vorteile, das für mich wirklich ein "C++ Done Right" ist. Will kein C++-Bashing machen. Ich finde nur, dass die D-Leute sich schon einiges überlegt haben. Schade, dass es kaum bei den Leuten ankommt.

-- Saxo

[volkard]

Saxo schrieb:

Ein anderer Punkt ist noch die Sicherheit: einen Garbage Collector zu haben löst eine große Zahl von Stabilitätsproblemen wegen falsche Deallozierung.

Es gibt in C++ keine Probleme damit. C++ macht das mit RAII auf exzellente Weise. Ich halte das für wesentlich sicherer als die Probleme in Java oder C#, wenn man wiedermal vergißt, Objekte per Hand abzuschießen und Dateien zu lange offen bleiben, alle verfügbaren Timer verbraucht werden, sich Datenbankverbindungen stapen und und und. Bitte nicht von C auf C++ schließen. Es wurde repariert.

[Zeus]

Saxo schrieb:

Also muß man sich die Laufzeitpolymorphie auf die harte Tour selber bauen wie in C?

Ähm, und wie würde man das machen? Nur aus Interesse ;-).

http://www.cs.rit.edu/~ats/books/ooc.pdf

Saxo schrieb:

Außer dem eingebauten Multithreading-Zeugs sehe ich an Go jetzt Vorteil gegenüber C.

Naja, die Build-Zeiten sind schon ein Punkt. Aber ein C oder C++-Projekt muss schon eine ziemliche Code-Größe erreichen bis das wirklich anfängt ein ernstes Thema zu werden. Ein anderer Punkt ist noch die Sicherheit: einen Garbage Collector zu haben löst eine große Zahl von Stabilitätsproblemen wegen falsche Deallozierung. Macht ziemlich Aufwand das von Anfang an richtig zu machen oder im Nachhinein die Bugs zu finden. Da hat auch D seine Vorteile, das für mich wirklich ein "C++ Done Right" ist. Will kein C++-Bashing machen. Ich finde nur, dass die D-Leute sich schon einiges überlegt haben. Schade, dass es kaum bei den Leuten ankommt.

-- Saxo

"C++ Done Right", halt ich für falsch, du solltest D noch genauer ansehen. D Fassade könnte man so nennnen. D insgesamt allerdings nicht.

[volkard]

Saxo schrieb:

Also muß man sich die Laufzeitpolymorphie auf die harte Tour selber bauen wie in C?

Ähm, und wie würde man das machen? Nur aus Interesse ;-).

Im Prinzip

enum RealType{WURSTBROT,SUPERMARKT};

struct Supermarkt{
   enum RealType rt;
   int masse;
}
Supermark__create(Supermarkt* sm,int masse){
   sm->masse=masse;
   sm->rt=Supermarkt;//Immer am Ende des Konstruktors den Typ setzen!
}
bool Supermarkt__kauf(void *sm,int euro){
   switch(((Supermarkt*)&sm)->rt)
      case SUPERMARKT: return Supermarkt__kaufImp(Supermarkt*)&sm,euro);
      case Wurstbrot: return Wurstbrot__kaufImp(Wurstbrot*)&sm,euro);
      default: exit("pure virtual function call");
}

struct Wurtsbrot{
   Supermarkt base;
   int farbe;
}
Wurtbrot__create(Wurstbrot* sm,int masse,int farbe){
   Supermarkt__create(sm,masse);
   sm->farbe=farbe;
   rt=Wurstbrot;//Immer am Ende des Konstruktors den Typ setzen!
}

Statt switsch geht auch proma ein Zeiger auf eine Tabelle von Funktionszeigern. Oder eine if-else-Orgie. Will man ein wenig mehr Laufzeit bezahlen, aber dafür weniger am Code Hand anlegen müssen, dann auch Hashtables.

Uns so machens wohl die Profis. (Bis jetzt nicht ganz sicher, aber es schaut irgendwie wie handgemachte Laufzeitpolymorphie aus.)
http://lxr.free-electrons.com/source/include/linux/kobject.h

[Saxo]

Okay, danke. Ich dachte es sei was schlaueres als case switch (nicht böse gemeint). Wie auch immer, ich habe so das sichere Gefühl, das niemand irgendwo ein Go-Projekt aufsetzen kann, wenn er nicht selbst ein C/C++-Guru ist, weil ihn die dort arbeitenden C/C++-Entwickler sonst nie für voll nehmen werden. Wenn wirklich ein Go-Entwickler gesucht wird, wird eh jemand genommen, der schon C/C++ gut kann. Deswegen kann ich mir Go aus dem Kopf schlagen. Ist höchstens für Hobby/Muße was.

In C/C++ als Nebenjob zu Java reinkommen kann ich wohl auch vergessen. Auf ein Anfängergehalt kann ich nicht mehr runter (Haus, Familie, Krankenkasse, private Rentenvorsorge) selbst wenn ich was finden würde. Bleibt höchstens noch C#. Ist immerhin weiter als Java als Sprache auch wenn ich M$ nicht mag.

-- Saxo

[GPC]

Saxo schrieb:

Bleibt höchstens noch C#. Ist immerhin weiter als Java als Sprache auch wenn ich M$ nicht mag.

Kein Grund für bad feelings, C# ist als Sprache sehr angenehm zu programmieren. Außerdem ist das .NET Framework enorm umfangreich und mächtig.

Ansonsten arbeite dich in HTML5 + JS ein, da geht in Zukunft bestimmt auch einiges

[Mechanics]

Saxo schrieb:

Was mich noch erstaunt, ist, wie ungezwungen die Leute im Forum hier offensichtlich sowol mit Java und/oder C# ihr Geld verdienen. Ich kenne nur die reinen Java-Läden, wo mit M-Produkten arbeiten nicht mit der Entwickler-Ehre vereinbar ist. Nicht, weil man als Java-Entwickler nicht mit C# entwickeln darf, sondern weil die Leute bei Microsoft nur an M denken ...

Ich denke Ahnung von Java als auch C# nützt einem wohl nur als Freelancer was, oder? I.d.R. sind die Firmen entweder ganz auf Java oder .NET ausgerichtet und haben keine Mischung dazwischen

Diese M$ Einstellung erwarte ich eher bei Unix-C Programmierern. Java Programmierer sind meist Wirtschaftsinformatiker und denen ist egal, ob sie Java oder C# machen und Microsoft ist da kein Feindbild. Noch mehr Klischees

Diese M$-Mentalität halte ich für Quatsch und unprofessionell. Außerdem ist Oracle sicherlich nicht weniger geldgeil.

Die ganzen kleinen/mittelständischen Firmen sind über jeden Auftrag froh und denen ist völlig egal, ob sie in Java oder C# entwicklern, Hauptsache es kommt was rein. Und ähnlich genug sind sie ja. In meiner alten Firma haben wir beides gemacht. Für Desktop C# und Webanwendungen in J2EE.

[Assante2k13]

Da ich eh noch neu dabei bin, würde ich mir die Sprache auch aneignen. Kann ja ned schaden, wenn man als Erster mit auf den Zug aufspringt. Davon abgesehen, fand ich die Grundansätze von Google GO gar nicht so übel, obwohl mir C++ potenter erscheint.

[Swordfish]

...