Wie seht ihr die Changen von Google Go?

[Saxo]

Aber ein C#-Projekt mit 3000 Dateien ist hingegen in ein paar Sekündchen durchgeflutzscht! Bombastisch!

C# linked nicht statisch, oder? In der CLR ist ja alles drin, was es braucht. Das geht deswegen so schnell wie es bei java auch geht. Kann man mit C# auch Treiber und sowas machen...?

Das ist aber nicht mehr so zwingend. Denn was heutzutage so auf dem Schreibtisch steht, ist das, was gestern noch ein Großrechner oder Supercomputer war.

Schon, bei großes Projekten funktioniert das aber auch nicht mehr. Hier ist ein schöner Artikel dazu von Robert Pike von Google: http://talks.golang.org/2012/splash.slide#1 Allerdings hat Google schon größere Builds als so eine gewöhnliche Bude.

Und wir haben teilweise alten Code, den man fast komplett neu kompilieren muss, wenn man eine zentrale Headerdatei ändert.

Bei C/C++ ist es so, dass schon includierte Include-Datei wieder reingeholt werden, wenn sie von einer anderen Source-Datei wieder referenziert wird. Das kann dann schneeballartig losgehen. Das ist bei Go genau deswegen nicht so gemacht worden. Habe mal dazu einen guten Artikel gelesen.

-- Saxo

[volkard]

Saxo schrieb:

Aber ein C#-Projekt mit 3000 Dateien ist hingegen in ein paar Sekündchen durchgeflutzscht! Bombastisch!

C# linked nicht statisch, oder? In der CLR ist ja alles drin, was es braucht. Das geht deswegen so schnell wie es bei java auch geht. Kann man mit C# auch Treiber und sowas machen...?

Geh für alle praktischen Erwägungen davon aus, daß C# exakt genau gleich wie Java ist. Der einzige Unterschied ist, daß mal Sun und mal MS den GC schneller gekriegt hat und so ein Schmonz. Oder daß eine Native-Lib (weils halt doch schneller ist für Video-Abspielen, Crypto, Schach, ...) gebaut wurde und als vollkommen komplett neue Technologie verkauft wird. Die andere Seite wird folgen.

[volkard]

Saxo schrieb:

Hier ist ein schöner Artikel dazu von Robert Pike von Google: http://talks.golang.org/2012/splash.slide#1 Allerdings hat Google schon größere Builds als so eine gewöhnliche Bude.

Ich halte Go für viel besser als C und zugleich viel schlechter als C++.
Nochmal die Slides angesehen bestärkte mich.

Entsprechend mag ich nicht, daß Du Go mit C/C++ vergleichst. Das paßt nicht.

[Saxo]

Ich halte Go für viel besser als C und zugleich viel schlechter als C++.

Okay, ich kann nicht folgen. Bin wie gesagt kein C/C++-Experte. Was meinst du mit "..und zugleich viel schlechter als C++"?

-- Oliver

P.S.: D habe ich auch angeschaut: http://dlang.org/. Abere es hat überhaupt nie angezogen. Go hat in 2 Jahren viel mehr losgetreten als D. Tut mir leid für die D-Leute, die auch gut gearbeitet haben ...

[volkard]

Saxo schrieb:

Ich halte Go für viel besser als C und zugleich viel schlechter als C++.

Okay, ich kann nicht folgen. Bin wie gesagt kein C/C++-Experte. Was meinst du mit "..und zugleich viel schlechter als C++"?

Als alter Smalltalker kennste doch die Wonnen der Objektorientierung.
*Gruppenkuscheln*!

[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