Go für Web Anwendungen im Backend

Ich vermute, dass die Projektverwaltungs-Tools drumherum viel spannender 
sind. Ich bin gewohnt, Projekte aus wiederverwendbaren Modulen* zusammen 
zu setzen. Also haben wir Repositories für die Quelltexte, für die 
Binaries und Tools die das alles per Konfiguration zusammensetzen.

*) Was unsere Projektleiter "Modul" nennen, sind technisch gesehen ganze 
Projekte, Programme, Bibliotheken, oder gar einzelne Dateien (z.B. XSD).

Nun habe ich gelesen, dass man bei Go absichtlich auf Makefiles 
verzichtet hat. Das geht wohl exakt in die entgegengesetzte Richtung, 
oder irre ich mich?

Stefan ⛄ F. schrieb:
> Ich komme aus der Java EE Welt, und schiele gerade mit einem
> halben Auge
> auf die Programmiersprache Go. meint ihr, man kann Go vernünftig für
> kommerzielle Backend Anwendungen mit Web-Schnittstellen einsetzen?

Der go-hype ist vorbei, auch und vor allem im Backend. Heute schmeisst 
man eh alles in Container, ob da jetzt ne fette runtime drinnliegt oder 
ein fettes goprämmchen, who cares?. In die Cloud geht man mit GraalVM, 
solltest du als JEE-Entwickler eigentlich kennen und die Frage 
eigentlich überflüssig sein.

Bruce Lees Friseur schrieb:
> In die Cloud geht man mit GraalVM,
> solltest du als JEE-Entwickler eigentlich kennen

Kenne ich noch nicht, weil die Cloud für uns noch Neuland ist. Unser 
Chef will in die Cloud gehen und zugleich womöglich unsere etablierte 
Codebasis (von ca 4 Millionen eigenen Zeilen) auf Basis von Java EE und 
SOAP durch Go und REST/JSON ersetzen.

Ich weiß noch nicht was ich davon halten soll.

Stefan ⛄ F. schrieb:
> Ich weiß noch nicht was ich davon halten soll.
Zum googlen:
graalvm, cloud-native,  evt. noch quarkus

Go braucht ihr nicht mehr anzufassen.

Unsere Chefs haben beschlossen, Go in einem neuen Projekt zu versuchen. 
Deswegen arbeite ich seit ein paar Tagen Tutorials und ein Lehrbuch 
durch.

Mein bisheriger Eindruck ist, dass die Sprache wahrscheinlich alles 
kann, was ich brauchen werde, obwohl sie (verglichen mit Java und C++) 
erheblich vereinfacht wurde. Angenehm ist, dass die Sprache mit einer 
sehr umfangreichen Sammlung an Standard Bibliotheken daher kommt.

Schwächen sehe ich ganz klar im Umfeld der Desktop GUI Anwendungen. Da 
würde ich eher bei C++ bleiben. Das ist aber nicht das Umfeld, in dem 
ich beruflich tätig bin.

Je mehr ich über Go lerne, umso mehr Lust bekomme ich, es zu versuchen. 
Insofern bin ich guter Dinge.

Ist im Devopsumfeld, Backend recht populär, das fette Javazeug (das 
ganze Spring-.Gerümpel das dort heute Standard ist, obwohl es gibt auch 
Quarkus) braucht man dann nicht mehr, zudem ist die Sprache einfacher. 
Java mit seinem kaputten Typsystem nervte schon immer, graalvm ist auch 
mehr ein Hack. go spielt ausserhalb des devops/backendbereichs keine 
Rolle, Desktopanwendungen sind damit aufggrund fehlender/schlecht 
gepflegter gui lib-anbindungen eher nicht sinnvoll obwohl man auch C++ 
dazulinken kann, ist ein bischen ein krampf als ich das mal vor einiger 
Zeit probierte aber es geht.

Anderthalb Jahre später kann ich berichten, dass wir mit Go (fürs 
Backend) erfolgreich ins Cloud Geschäft eingestiegen sind. Wir haben 
genug Projekte in Produktion, um das Personal durch zu füttern. Während 
dessen investiert die Firma in eine Cloud basierte E-Commerce Plattform 
die als Service vermietet wird. Zwei Kunden nutzen sie schon, weitere 
warten darauf dass wir fertig werden.

Kurz gesagt: läuft

Java setzen wir noch als Zweit-Sprache ein, zur Zeit für Bezahlvorgänge. 
Ich finde keine der beiden Sprachen bedeutend besser oder schlechter. 
Beide sind OK ohne mich wunschlos Glücklich zu machen.

Bruce Lees Friseur schrieb:
> Zum googlen:
> graalvm, cloud-native,  evt. noch quarkus
>
> Go braucht ihr nicht mehr anzufassen.

Lol. Diese Java-Fanbois. Suchen immernoch Probleme für ihren 
Vorschlaghammer.

Bitte scheißt das endlich in den Müll, diesen Java Schrott braucht doch 
heute echt keine Sau mehr. Da gibt es tausend bessere Alternativen (js, 
ts, go, rust, etc.), die nicht von einer Horde Arschlöchern (meist 90er 
Jahre Umschulprogrammierer) begleitet wird. Wenn man nicht alles in 40 
Klassen abstrahieren kann, ist es nicht "enterprise". Wenn es nich 
mindestens 4000 dependencies hat auch nicht. Vom Memory-Footprint und 
dessen einfluß auf die Umwelt fange ich garnicht erst an.

Oli Schulz schrieb:
> Wenn man nicht alles in 40
> Klassen abstrahieren kann, ist es nicht "enterprise". Wenn es nich
> mindestens 4000 dependencies hat auch nicht

Dafür hat man aber die Gewissheit, dass alles machbar ist. Geht nicht, 
gibt nicht bei Java.

Das sieht bei Go schon anders aus. Klein, schlank, einfach. Aber es gibt 
halt nicht für alles die passende Bibliothek. Insbesondere wegen 
Kryptografie bin ich doch froh, dass mir Java noch als Zweit-Sprache 
erhalten geblieben ist.