Wie seht ihr die Changen von Google Go?

volkard

Mechanics schrieb:

zentrale Headerdatei ändert

Ja, in den 90-ern üblich.

Mechanics schrieb:

Macht seit zehn Jahren keiner mehr sowas, aber alten Sachen gibts immer noch genug,

Ach, ich hatte mal ein Projekt mit weit mehr als 1000 Dateileichen.

Mechanics schrieb:

Das ganze Projekt durchzubauen dauert auf meinem Rechner locker einen ganzen Tag.

Das ist sportlich.

Mechanics schrieb:

Sehr nervig das Ganze.

Könnte man nicht einen Bot bauen, der erstmal die fetten drei "alles1.hpp" "alles2.hpp" "alles3.hpp" ersetzt durch die #include-Orgie, die in alles?.hpp steh und dann immer eine zufällige #include-Zeile aus einer Datei rausnimmt und neu erstellt? Sollte doch nach ein paar Wochen schneller werden und sich rapide beschleunigen.

Mechanics schrieb:

Also, so ganz aus der Welt ist das Problem noch nicht

Ja, ich weiß. Trotzdem ist das kein Argument für Go in neuen Projekten. Statt Go zu riskieren, kann man wohl besser seine Mitarbeiter schulen.

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