Bock auf Go-Entwicklung?

      ca. 3 Minuten Lesezeit           ·

Gopher Go ist in aller Munde. Und damit mein ich nicht das alte japanische Spiel, sondern die Programmiersprache. Ich persönlich arbeite jetzt seit 2013 mit dieser Sprache und will derzeit gar nichts anderes mehr machen.

Viele Arbeitgeber verwehren sich ja dieser Sprache – sie kennen sie oft nicht oder sind so eingefahren, dass sie glauben, man könne die bisherige Komplexität niemals in endlicher Zeit nachbauen. Und genau das sehe ich anders. Oft kann man sich, wenn man mal von vorn anfängt, ekliger Altlasten entledigen und Komplexität entfernen, die nie jemand gebraucht hat. Genausogut bringt man ein Projekt mal in die Neuzeit hieven und veraltete Designpatterns durch aktuelle ersetzen.

Wie sieht es bei dir aus? Hast du Bock Go zu lernen oder kannst es sogar schon und hast Bock auf was Neues? Mein aktueller Arbeitgeber Contentflow ist grad auf der Suche nach Entwicklern.

Was wir eigentlich machen?

Simple Antwort: Irgendwas mit Livestreaming.
Umfangreichere Antwort (das ist keine Werbeverkaufsveranstaltung, deshalb hier die Entwicklerbeschreibung): Wenn du z.B. ein Event live zu Facebook oder Youtube streamen möchtest, kann man das heute recht einfach per App machen. Möchtest du zu beiden gleichzeitig streamen, wird es schon schwieriger. Möchtest du zu vielen Plattformen und deiner Website streamen, brauchst du ein kompliziertes Setup und viel Bandbreite. Contentflow löst dieses Problem. Du streamst zu uns und wir kümmern uns um den Rest.
(Wir bieten auch Full-Service an, aber das ist für Devs jetzt eher unrelevant)

Hier mal ein paar persönliche Eindrücke, was ich so für Vorteile sehe:

Was ein Bewerber mitbringen sollte (ja doch, ein paar Ansprüche haben wir auch):

Melde dich einfach unter jobs@contentflow.org

PS. Hast du deine Jobbeschreibungsbingo-Karte voll bekommen?
PPS. Du wunderst dich, warum das die flapsigste Jobbeschreibung ever ist? Weil dies hier mein Blog ist und ich Dinge schreibe, die mir gefallen. Das ist kein Jobportal hier, allerdings suchen wir Kollegen und deshalb habe ich aus meinem Blickwinkel beschrieben, was wir brauchen und auch meinen persönlichen Eindruck davon.


Warum ich das Error-Handling in Go mag

      ca. 3 Minuten Lesezeit           · · ·

Immer wieder lese oder höre ich, dass Go-Anfängern dieses ständige

if err != nil

nicht gefällt. Selbst auf dem sehr lustigen Vergleich If programming languages were weapons kam dieser Punkt auf:

Ich bin da eher der Meinung, dass man falsch an die ganze Sache ran geht, wenn man das so sieht. Fangen wir doch mal an, mit anderen Lösungsansätzen zu vergleichen.

try-catch-Blöcke

Seit es PHP5 gibt, sind try-catch-Blöcke in PHP möglich und erfreuen sich großer Beliebtheit. In Java gibt es das natürlich schon länger und selbst Python hat Exceptions.
Leider gibt es grad in der Scriptsprachen-Welt sehr viele Hohlbirnen, die der Meinung sind, es sei total knuffig, einfach um alles in der main()-Methode ein try mit entsprechend generischem Catcher zu setzen.
Einfach alles abzufangen und in den eigentlichen aufrufenden Methoden immer davon auszugehen, dass sich schon der äußere Catch drum kümmern wird, dass zumindest eine Fehlermeldung ausgegeben wird, kann man schon so machen, ist aber leider sehr kurz gedacht und führt z.B. bei Web-Applikationen dazu, dass man nicht eine spezifische Meldung sieht, was grad gegen die Wand gefahren ist, sondern ein Error 500 oder ein “An error occurred” - das führt dann gerne dazu, dass Menschen Bescheid sagen, dass die Webseite nicht funktioniert.

$ok-Variablen

Es geht natürlich noch besser. Ganz ohne spezielle Fehlerbehandlung. Man schleift einfach durch die gesamte Software ein $ok (mit oder ohne Dollarzeichen hängt jetzt einfach mal von der Sprache ab). Sobald ein Fehler auftritt, setzt man diese dann auf false und schon weiss der Rest des Programms, dass er so nicht weiterarbeiten darf. Warum genau nicht und was vielleicht noch zu tun ist (DB-Connection schließen, Schreibvorgänge finalisieren), hat dann den Rest auch nicht zu interessieren.

if err != nil

Ich muss gestehen: Als ich mit Go anfing, fand ich das ziemlich komisch. Die Methoden hatten multiple Rückgabewerte und oft war der zweite vom Typ error.
Go beschwert sich selbstverständlich auch, wenn man multiple Rückgaben hat, aber nur eine Variable zuweist.

Nehmen wir also folgende Beispielmethode:

func Foo() (string, error) {
    return "bar", errors.New("My Error")
}

Was also nicht geht:

func main() {
    bla := Foo()
}

Es muss lauten:

func main() {
    baz, err := Foo()
    if err != nil {
        // Error Handling
    }
    fmt.Print(baz)
}

Oder man entscheidet sich wirklich explizit dafür, den zurückgegebenen Error zu ignorieren:

func main() {
    baz, _ := Foo()
    fmt.Print(baz)
}

Aber genau das ist der Punkt: Man muss sich explizit dafür entscheiden, genau diesen Fehler zu ignorieren oder ihn eben weiter zu verarbeiten, zurückzugeben oder was auch immer. Das zwingt den Entwickler dazu, sich aktiv damit auseinanderzusetzen, was als nächstes passiert oder was passieren könnte.

Ich mag das.