"Java vs C#: Welche Sprache eignet sich besser für Backend-Entwicklung?

[pr0gg3r]

vor 6 Minuten schrieb 0x00:

Witzig, dass du das sagst, mein Empfinden war immer genau anders herum. So scheiden sich die Geister...

Ich glaube sowohl ASP als auch JSP sind nicht so wirklich das Wahre  Wirklich anwendbar wird es dann erst mit eben JavaEE/Spring/Springboot (wobei ich ehrlich sagen muss, dass es erst mit Springboot "bequem" für den Entwickler wird). Bei C# kenn ich mich zu wenig aus, aber ich vermute, dass es erst mit ASP.NET Core richtig angenehm wird. Und dann sind die Unterschiede auch nicht mehr sooo groß.

(Was mich halt immer genervt hat war (zumindest früher!) dass dann immer gleich so ein schwerfälliger IIS benötigt wurde und C# (früher!) auch immer nur mit dem schwerfälligen Visual Studio angenehm war).

vor 10 Minuten schrieb 0x00:

In Java benötigt man oft relativ viel Code, C# ist da minimalistischer, eleganter. Minimalistischer nicht im Sinne der Features, aber man kann oft das selbe mit weniger Code ausdrücken. Wenn man C# gewohnt ist und Java schreiben muss fühlt man sich doch hier und da limitiert.

Dem muss ich zustimmen. C# wirkt dadurch deutlich moderner und weiter entwickelt, während Java einem "stehen geblieben" vorkommt. 

Im Java-Umfeld hat man dann ja zum Beispiel Kotlin mit den ganzen schönen Sprach-Features oder auch Scala, das eben genau das löst...:

Am 27.1.2023 um 07:34 schrieb Whiz-zarD:

wird C# sehr von F# beeinflusst, sodass sich C# zu einem Hybrid aus Objektorientierung und funktionaler Programmierung wird.

...bringt aber letztendlich in der Backend-Entwicklung eher wenig. (Android Apps in Kotlin habe ich gesehen, aber bisher noch keine andere Anwendung damit, auch wenn es theoretisch möglich ist. Einmal habe ich ein Backend in Scala geschrieben gesehen, und da hat es auch tatsächlich Sinn gemacht, war aber auch ein eher außergewöhnlicher Usecase).

vor 13 Minuten schrieb 0x00:

JavaScript/TypeScript ist oft im Stack, das stimmt. Jedoch nimmt die Relevanz stark ab je weiter man sich vom Web Bereich entfernt. Schaden kann es jedoch nie.

Ich weiß halt nicht, wie es außerhalb der Web-Welt ist ("Backends für Backends" oder für IoT etc., kenn ich mich nicht aus). In der Web-Welt kann ich nur sagen, dass die ganzen NodeJS-Lösungen / Stacks doch häufig gefragt sind. Sobald es dann Enterprise geht wiederum Java (und vermutlich auch C#).

Dann möchte ich noch einen anderen Punkt reinwerfen: in einer Zeit, wo man statt Monolithen Microservices oder Serverless verwendet, kann man rein theoretisch jeden Microservice bzw. Function in einer anderen Sprache/Framework/Technologie schreiben.

Ich kann mir auch vorstellen, dass C# auch im Azure-Umfeld relevant ist. Aber ich kenne mich hier zu wenig aus.

[Whiz-zarD]

vor einer Stunde schrieb pr0gg3r:

(Was mich halt immer genervt hat war (zumindest früher!) dass dann immer gleich so ein schwerfälliger IIS benötigt wurde und C# (früher!) auch immer nur mit dem schwerfälligen Visual Studio angenehm war).

IIS wurde inzwischen durch den leichtgewichtigen Kestrel Web Server ersetzt und durch die Minimal-API wird das Konfigurieren des Webservers noch schlanker, da das schwerfällige Konstrukt der Main-Methode wegfällt. (Die Main-Methode existiert zwar weiterhin, wird aber versteckt.)

vor einer Stunde schrieb pr0gg3r:

...bringt aber letztendlich in der Backend-Entwicklung eher wenig. (Android Apps in Kotlin habe ich gesehen, aber bisher noch keine andere Anwendung damit, auch wenn es theoretisch möglich ist. Einmal habe ich ein Backend in Scala geschrieben gesehen, und da hat es auch tatsächlich Sinn gemacht, war aber auch ein eher außergewöhnlicher Usecase).

Sorry aber das ist totaler Käse. Wieso sollte LINQ (was ja Konzepte der funktionalen Programmieren folgt) und Syntax-Erweiterungen, wie z.B. Pattern Matching, Tuples oder Records für die (Backend)-Entwicklung nichts bringen?

vor einer Stunde schrieb pr0gg3r:

Dann möchte ich noch einen anderen Punkt reinwerfen: in einer Zeit, wo man statt Monolithen Microservices oder Serverless verwendet, kann man rein theoretisch jeden Microservice bzw. Function in einer anderen Sprache/Framework/Technologie schreiben.

Man sollte Monolithen nicht unterschätzen. Nicht immer ist eine Mircoservice Architektur sinnvoll oder ratsam. Inzwischen sagt man sogar, dass Micrsoservices auf dem Weg zum Tal der Enttäuschung sind. Man sagt auch, wer es nicht schafft, einen modularen Monolithen zu entwickeln, der braucht es gar nicht mit Microservices versuchen.

Bearbeitet 28. Januar 2023 von Whiz-zarD

[0x00]

Funktional oder Objektorientiert hat doch nichts mit Backend oder Appentwicklung zu tun. In erster Linie sind das nur Werkzeuge, was du damit baust ist doch nicht von Relevanz. Und mehr Optionen in Form von mehr Werkzeugen ist per se erst einmal nichts schlechtes.

Zum Thema Microservicearchitektur: Das mit dem Tal der Enttäuschung würde ich so nicht unterschreiben aber grundsätzlich hast du schon Recht. Nur weil man es als Microservice bauen kann sollte man das noch lange nicht, es gibt jedoch auch Bereiche wo Microservices sehr sinnvoll sind. Natürlich könnte man theoretisch jeden Service in einer anderen Sprache bauen, oft ist man aber auch von den Entwicklern selbst abhängig. Wenn alle Java können bietet sich das halt eher an als die gesamte Mannschaft Go lernen zu lassen.

vor 3 Stunden schrieb pr0gg3r:

Ich weiß halt nicht, wie es außerhalb der Web-Welt ist ("Backends für Backends" oder für IoT etc., kenn ich mich nicht aus). In der Web-Welt kann ich nur sagen, dass die ganzen NodeJS-Lösungen / Stacks doch häufig gefragt sind. Sobald es dann Enterprise geht wiederum Java (und vermutlich auch C#).

Ich hab mit "Backends für Backends" angefangen und mache mittlerweile IoT. C#, Java, Scala und Python sind mir persönlich schon über den Weg gelaufen, Go ist auch im kommen. Serverseitiges JavaScript war jedoch nie ein Thema. Dennoch interagieren auch diese Backends meist an mindestens einer Ecke mit dem User, hier kommt man dann meist nicht um JavaScript herum. In den Backends selber wird man dies aber zumindest meiner Erfahrung nach eher nicht finden, es spielt also definitiv eine untergeordnete Rolle. Es zu können ist kein Muss, es schadet natürlich dennoch nicht.

vor 3 Stunden schrieb pr0gg3r:

Ich kann mir auch vorstellen, dass C# auch im Azure-Umfeld relevant ist. Aber ich kenne mich hier zu wenig aus.

Ich kann da auch nur begrenzt etwas zu sagen, da ich Azure immer nur mit C# gemacht habe. Der C# Support ist hervorragend, allerdings weiß ich nicht inwiefern die anderen gängigen Sprachen ebenso gut unterstützt werden. Kann also sein, dass man mit Java ebenso gut fährt, mit C# macht man hier auf alle Fälle aber nix falsch.

[pr0gg3r]

vor 4 Stunden schrieb Whiz-zarD:

Sorry aber das ist totaler Käse. Wieso sollte LINQ (was ja Konzepte der funktionalen Programmieren folgt) und Syntax-Erweiterungen, wie z.B. Pattern Matching, Tuples oder Records für die (Backend)-Entwicklung nichts bringen?

Ich bin vollkommen bei dir. Mein Gedankengang war eher: ob ich ein Springboot-Backend oder eine Android-App in Java oder Kotlin entwickle (also mit mehr oder weniger syntaktischem Zucker), ist erst mal trivial, da die "Magic" in erster Linie vom Framework kommt und nicht von den Sprachfeatures. Natürlich macht funktionale Programmierung Sinn.

vor 4 Stunden schrieb Whiz-zarD:

Man sollte Monolithen nicht unterschätzen. Nicht immer ist eine Mircoservice Architektur sinnvoll oder ratsam. Inzwischen sagt man sogar, dass Micrsoservices auf dem Weg zum Tal der Enttäuschung sind. Man sagt auch, wer es nicht schafft, einen modularen Monolithen zu entwickeln, der braucht es gar nicht mit Microservices versuchen.

Das Problem kommt denke ich daher, dass man versucht, "alles" und "blind" in Microservices zu packen. Dadurch hat man aber an anderen Stellen Komplexitäten, die man in den Griff bekommen muss. Oft macht es Sinn, dann zu skalieren wenn man merkt, dass man langsam skalieren sollte. Letztendlich kann man aber auch Monolithen skalieren.

vor 2 Stunden schrieb 0x00:

Ich hab mit "Backends für Backends" angefangen und mache mittlerweile IoT. C#, Java, Scala und Python sind mir persönlich schon über den Weg gelaufen, Go ist auch im kommen. Serverseitiges JavaScript war jedoch nie ein Thema

Das ist interessant. Ich bin eher an APIs für Apps oder Webapps dran, da ist JS/TypeScript sehr häufig anzutreffen, wobei ich hier in dem Bereich C# eher als exotisch betrachten würde. Von Go höre ich immer wieder, aber kenne niemanden persönlich der es produktiv einsetzt.

vor 2 Stunden schrieb 0x00:

Ich kann da auch nur begrenzt etwas zu sagen, da ich Azure immer nur mit C# gemacht habe. Der C# Support ist hervorragend, allerdings weiß ich nicht inwiefern die anderen gängigen Sprachen ebenso gut unterstützt werden. Kann also sein, dass man mit Java ebenso gut fährt, mit C# macht man hier auf alle Fälle aber nix falsch.

Ich tangiere Cloud wenn überhaupt dann eher im AWS-Umfeld und da wird so gut wie alles verwendet (ich denke vor allem Python, JS/TS und Java, aber C# und Go müssten genauso möglich sein).

[allesweg]

 

1. Ihr diskutiert akademisch die Vor- und Nachteile, dabei wollte der TE nur eine Empfehlung, welchen sprachgebundenen Crashkurs er machen soll
2. Der Account des TE ist nicht mehr aktiv 

[Whiz-zarD]

vor 3 Minuten schrieb allesweg:

Der Account des TE ist nicht mehr aktiv 

Das war schon am gleichen Tag der Threaderstellung.

vor 3 Minuten schrieb allesweg:

Ihr diskutiert akademisch die Vor- und Nachteile, dabei wollte der TE nur eine Empfehlung, welchen sprachgebundenen Crashkurs er machen soll

Wenn der Account eh schon gelöscht wurde und die Person sowieso hier nicht mehr reinschaut, kann man doch offtopic werden. 😄

[0x00]

vor 10 Stunden schrieb pr0gg3r:

Oft macht es Sinn, dann zu skalieren wenn man merkt, dass man langsam skalieren sollte. Letztendlich kann man aber auch Monolithen skalieren.

Ja, auf jeden Fall! Bei fast allen Projekten an denen ich gearbeitet habe war von vornherein klar, dass das skalierbar sein muss, deshalb wurde stets schon in der Konzeptionsphase viel Wert darauf gelegt potentielle Bottlenecks zu identifizieren und zu beseitigen. Das bringt mich dann auch zu den Monolithen: Natürlich kann man grundsätzlich auch Monolithen skalieren, wenn man jedoch sowohl relativ linear skalierende als auch in Laufzeit und Resourcen stark variierende Teilschritte hat bieten sich meiner Meinung nach Microservices an. Eigentlich wollte ich behaupten, dass Microservices auch bei asynchronem Processing das Werkzeug der Wahl sind, bei genauerem Nachdenken bin ich mir aber nicht so sicher ob man das nicht auch sinnvoll in einem Monolithen realisieren könnte. Wie steht ihr dazu?

Ich erlebe aber auch immer wieder, dass Sachen stärker als eigentlich notwendig heruntergebrochen werden, alles kleinstmöglich runterzubrechen macht auch wenig Sinn. Wie immer sollten Patterns halt nicht ohne Nachzudenken angewandt werden. Stattdessen sollte man hinterfragen, überlegen und einen goldenen Mittelweg finden. Alles hat seine Vor- und Nachteile.

vor 10 Stunden schrieb pr0gg3r:

Von Go höre ich immer wieder, aber kenne niemanden persönlich der es produktiv einsetzt.

Ich tangiere Cloud wenn überhaupt dann eher im AWS-Umfeld und da wird so gut wie alles verwendet (ich denke vor allem Python, JS/TS und Java, aber C# und Go müssten genauso möglich sein).

Ja, C# und Go sind in AWS problemlos möglich. Für alle diese Sprachen gibt es auch Azure SDKs, ich kann nur leider nichts dazu sagen weil ich sie selber noch nicht benutzt habe. Von Kollegen die Azure Projekte mit Java und Python machen gab es aber immer nur Kritik über Azure selbst, nie über die SDKs. So schlecht können die SDKs also nicht sein

vor einer Stunde schrieb Whiz-zarD:

Wenn der Account eh schon gelöscht wurde und die Person sowieso hier nicht mehr reinschaut, kann man doch offtopic werden. 

Sehe ich genauso

Ansonsten auch gerne abgetrennt als eigenen Thread.

[Gooose]

vor 16 Stunden schrieb Whiz-zarD:

Man sollte Monolithen nicht unterschätzen. Nicht immer ist eine Mircoservice Architektur sinnvoll oder ratsam. Inzwischen sagt man sogar, dass Micrsoservices auf dem Weg zum Tal der Enttäuschung sind. Man sagt auch, wer es nicht schafft, einen modularen Monolithen zu entwickeln, der braucht es gar nicht mit Microservices versuchen.

Auch wenn es ein wenig älter ist, finde ich es nach wie vor faszinierend wie sie Stack Overflow aufgebaut haben.

Aus organisatorischer Sicht kann es Sinn machen Microservices einzusetzen, um bei größeren Projekten mehrere autarke Teams an einzelnen Services arbeiten zu lassen.

[Chris-Info]

Am 29.1.2023 um 09:49 schrieb allesweg:

1. Ihr diskutiert akademisch die Vor- und Nachteile, dabei wollte der TE nur eine Empfehlung, welchen sprachgebundenen Crashkurs er machen soll

Das macht hier insofern sogar mal Sinn.
Auf WIFI macht TE ja keine Ausbildung, sondern auch nur einen Grundkurs für eine Programmiersprache. Und weil er/sie /divers sich an WIFI gebunden fühlt, denkt TE man müsse sich zwischen den zwei dort angebotenen Sprachen entscheiden.

Python ist übrigens auch super für die Backendprogrammierung und damit hat TE schon begonnen.
Da kann man sich bei Udemy auch einen günstigen Kurs für den Einstieg holen und dann vielleicht noch zwei gebrauchte Bücher für gezielte Backendentwicklung mit Django, Flask oder FastApi. Da ist am am Ende genau so kompetent oder nicht kompetent, wie bei dem WIFI Kurs wäre mein Eindruck.

Wenn man natürlich Wert auf ein Zertifikat legt (was hilfreich sein kann), dann gäbe es auch noch JavaScript (NodeJS) oder Golang. Gleiches Vorgehen wie bei Python, nur dass man am Ende bei Microsoft (die bieten Javascript Zertifikate) oder bei Google (Golang) eine Zertifizierung machen kann.