4. Wie seht ihr die Changen von Google Go?

Wie seht ihr die Changen von Google Go?

  • S

    Hallo,

    ich habe mich schon immer für C/C++ interessiert. Damals Semesterarbeiten und die Diplom-Arbeit damit gemacht, aber nie damit beruflich was gemacht. War immer in der Smalltalk/Java-Welt unterwegs. Jetzt ist es dafür zu spät. Ohne jahrelange Berufserfahrung in C/C++ kriege ich natürlich keine Stelle dafür. Die Zeiten sind heute anders.

    Jetzt habe ich Google Go entdeckt und finde es sogar ganz ansprechend. Es kann nicht C/C++ ersetzen. Es ist nicht general purpose wie C/C++, sondern halt für die Bedürfnisse für Systemprogrammierung von Googles Server-Farmen gemacht: direkte Unterstützung für Multi-Core Programmierung , Netzwerk-Programmierung, Sicherheit (keine Pointer-Arithmetik, GC), kurze Build-Zeiten.

    Ich frage mich jetzt, ob es für Go gewisse berufliche Chancen in den nächsten Jahren geben kann. Für Go ist das Feld noch unbestellt. Da könnte ich hineinkommen, wenn ich mich kräftig in Go einarbeite. Die C/C++-Entwickler haben hier natürlich einen Vorteil, aber die haben oft wenig Ahnung von Java und die Kombination Java+Go hat vielleicht auch seine Chancen. Was mir im Kopf herumgeht sind die langen Build-Zeiten für C/C++: hier setzt genau Go an, es wurde genau deswegen eine ganz neue Sprache geschaffen, um dies Problem von der Wurzel an zu lösen. Lange Build-Zeiten erhöhen die Projektkosten und das könnte bei manchen Projekt den Ausschlag für Go geben. Natürlich gibt es Tonnen von C/C++-Wartungsprojekten. Das sollte man deswegen nicht so blauäugig sehen. Ich habe mich nach Alternativen für Java umgeschaut: auf der JVM gibt es noch Groovy und Scala (Kotlin ist noch in Version 0.4). Für all diese Sachen gibt es absolut Null Stellen. Als Plus auf dem Lebenslauf für eine Java-Stelle vielleicht zu gebrauchen. Aber damit zu arbeiten sehe ich Null Chance. Deswegen lieber Go. Nach 20 Jahren Smalltalk/Java bin ich müde davon. Waren gute Jahre, aber Java ist sowas von Boilerplate Codierung geworden, das macht mir echt keinen Spaß mehr.

    Okay, und was will ich nun? Wollte mal wissen was die alten C/C++-Hasen von der Go-Sache halten und ob sie hier Chancen in 1-3 Jahren auf dem Arbeitsmarkt sehen. Ein bisschen gambeln muss man schon und selbst was riskieren. Aber ich würde mir mal gerne die Meinung von anderen anhören.

    Danke und Grüße, Saxo

    0
  • M

    Mich würds ehrlich gesagt überraschen. Ich kann mir nicht vorstellen, dass Go sich durchsetzen wird. Bei 2-3 exotischen Projekten vielleicht.

    0

  • Saxo schrieb:

    Okay, und was will ich nun? Wollte mal wissen was die alten C/C++-Hasen von der Go-Sache halten und ob sie hier Chancen in 1-3 Jahren auf dem Arbeitsmarkt sehen. Ein bisschen gambeln muss man schon und selbst was riskieren. Aber ich würde mir mal gerne die Meinung von anderen anhören.

    Habe mir aus Neugier mal ein Buch zu Go gekauft. Wenn Google eine Sprache macht, muss das interessant sein. Man sah Anzeichen eines beginnenden Hypes. Vielleicht ist ja was dran, also muss man mal gucken.

    Leider habe ich wenig Zeit, also habe ich noch nicht reingeguckt. Go verschwand schnell aus den Medien. Das müsste jetzt zwei Jahre her sein und das Buch steht im Regal... ich werde mal reingucken, wenn ich Zeit habe, mich interessieren Sprachen.

    Ob Go eine Zukunft hat? Hat es überhaupt eine Vergangenheit?

    Ist nur eine subjektive Wahrnehmung...

    0
  • V

    Saxo schrieb:

    Was mir im Kopf herumgeht sind die langen Build-Zeiten für C/C++: hier setzt genau Go an, es wurde genau deswegen eine ganz neue Sprache geschaffen, um dies Problem von der Wurzel an zu lösen.

    Glaube ich nicht wirklich.
    Damals, als C# recht neu war, ja, da hatte C++ echt ein *gewaltiges* Problem mit Compile-Zeiten. http://xkcd.com/303/

    C ninchtmal so arg. Aber C++ mit den ganzen Template-Dingen, verrückten lookups, das hat schon ordentlich gesaugt.

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

    Es war bei größeren Projekten zwingend notwendig, jede Nacht einen automatischen Compilerlauf zu machen, der denn auch gleich ein Stündchen oder ein paar mehr Stündchen brauchte. Jeder Entwickler hat am Abend sie neuen Sachen eingepflegt und wehe, er war dran schuld, wenn der Nachtlauf abbrach. Das gab Prügel! Oder 5€ in die Kaffekasse und den ganzen Tag Gewitzel.

    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.
    http://www.heise.de/newsticker/meldung/Pi-Berechnungsrekord-auf-handelsueblichem-PC-899930.html

    Ich habe vor ca 2 Jahren(?) einen Tausi ausgegeben für einen I7 und ich inkludiere sparsam. Für Windows noch eine SSD drunter. Ich freue mich jeden Tag, daß die Wartezeiten einfach weg sind. Total weg. Fast lautlos ist er auch noch, außer er muß echt mal mehrdutzend Sekunden auf volle Leistung mit 8 Threads und 105W gehen.

    Ich habe Go immer nur als google-internes Projekt gesehen. Hatte nie angenommen, daß sie außerhalb von google verwendet wird. Bewirb Dich bei google und sage, daß Du unglaublich viel Erfahrung in einigen Programmiersprachen hast, daß Du von Go begeistert bist soweit Du davon gelesen hast, würde ich sagen. Ich denke, die wissen selber, daß jemand, der gut programmieren kann, schnell sehr schnell Go beherrscht.

    0
  • M

    @Volkard: zumindest bei uns in der Firma ist das Problem mit den Compile Zeiten immer noch da (das soll natürlich kein Argument für Go sein). Ich hab in der Arbeit einen Dual Core und keine SSD. Und wir haben teilweise alten Code, den man fast komplett neu kompilieren muss, wenn man eine zentrale Headerdatei ändert. Macht seit zehn Jahren keiner mehr sowas, aber alten Sachen gibts immer noch genug, und keiner will die im Moment komplett umbauen. Das ganze Projekt durchzubauen dauert auf meinem Rechner locker einen ganzen Tag. Das mach ich aber zum Glück ganz selten. Aber auch einzelne Bibliotheken brauchen schon mal 20-30 Minuten zum Bauen, wenn jemand was größeres geändert hat, was im Endeffekt jeden Tag passiert. Sehr nervig das Ganze. Also, so ganz aus der Welt ist das Problem noch nicht 😉

    0
  • V

    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.

    0
  • S

    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

    0
  • V

    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.

    0
  • V

    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.

    0
  • S

    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 ...

    0
  • V

    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*!

    0
  • S

    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

    0
  • V

    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.

    0
  • S

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

    0
  • V

    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. 🙂

    0
  • M

    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.

    0
  • S

    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 ;-).

    0
  • S

    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

    0
  • Z

    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.

    0
  • S

    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?

    0
Anmelden zum Antworten