C# vs Java



  • gfdgfdgfdgd schrieb:

    eben, Microsoft Produkte sind von Profis für Profis.
    Das sieht man auch schon bei den entsprechenden Konferenzen, alle schön in Anzug und mit Krawatte. Kein Vergleich mit den Linuxbastlern die mit T Shirt und kurzer Hose, vielleicht sogar mit Hawaii Hemd rumsitzen.

    Auf wie vielen MS-Konferenzen warst du schon? Also ich habe bisher ein relativ gemischtes Publikum gesehen, Anzüge waren zwar auch vertreten aber ebenso auch lockere Kleidung (okay, kurze Hosen habe ich bislang noch nicht gesehen).

    gfdgfdgfdgd schrieb:

    Mal im Ernst: C# mag zwar eine schöne Sprache sein, aber dies oder jenes tolles Sprachfeature* kann den größten Nachteil niemals wettmachen: C# ist ein Microsoft Produkt, und ist in der Microsoft Welt daheim. Solange man nur für Windows OS programmiert, ist man damit sicher gut bedient.

    Mit C# in Kombination mit Xamarin kommt man schon recht weit (Windows, MacOS, iOS, Android, Windows Phone und WinRT und natürlich auch Web [ASP.Net]).

    gfdgfdgfdgd schrieb:

    noch ein Nachsatz zu den Sprach Features: diese mögen zwar nett sein, aber ich sehe den großen Vorteil irgendwie nicht.

    Ich habe bereits mit beiden Sprachen gearbeitet, ich weiß nicht wo Java aktuell steht (meine kürzlichen Experimente in Zusammenhang mit Minecraft Mods haben mich aber nicht unbedingt begeistert), aber ich sehe schon einige Vorteile von C# - auch in Zusammenhang mit der Produktivität.

    Richtig ist aber durchaus das Erfahrungen in einer Sprache häufig wichtiger sind, wenn man sich in eine davon nicht Einlernen muss, ist das durchaus ein Argument.



  • C# kann nur die falsche Wahl sein.

    Begründung:

    Vor einiger Zeit wurde hier in diesem Forum von D mit der Begründung abgeraten, dass bei D zwischen D 1.0 und D 2.0 ein Bruch besteht und man nicht seine Entwicklung auf eine Sprache bauen könnte, die keine langfristige dauerhafte Konsistenz gewährleistet.
    Wenn man das so betrachtet, dann muss man aber auch den gleichen Maßstab bei C# anlegen, denn C# Programme, die für .Net 1.0 oder .Net 2.0 geschrieben wurden, laufen unter Umständen, je nach den Features die man verwendet hat, z.b. Generics, nicht mehr auf .Net 3.0 und .Net 4.0.

    C# hat durch mehrere Änderungen in der Sprache, die eine Änderung der Runtime bedingten bewiesen, dass es keine Langzeitsicherheit gewährleisten kann.
    Das zeigt auch diese Tabelle mit der Zeile "Migration compatibility":
    http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#Generics

    Daraus folgt, nur Java gewährleistet Langzeitsicherheit.
    Was früher für Java 1.2 geschrieben und compiliert wurde, läuft heutzutage immer noch auf einer aktuellen JVM.
    Bei C# ist das nicht so, weswegen Microsoft auch x .Net Versionen auf Windows installiert um alle Varianten abdecken zu können.



  • Totschlagargument schrieb:

    Vor einiger Zeit wurde hier in diesem Forum von D mit der Begründung abgeraten, dass bei D zwischen D 1.0 und D 2.0 ein Bruch besteht und man nicht seine Entwicklung auf eine Sprache bauen könnte, die keine langfristige dauerhafte Konsistenz gewährleistet.

    Nach diesem Argument müsste man von den meisten Sprachen abraten.

    Totschlagargument schrieb:

    Wenn man das so betrachtet, dann muss man aber auch den gleichen Maßstab bei C# anlegen, denn C# Programme, die für .Net 1.0 oder .Net 2.0 geschrieben wurden, laufen unter Umständen, je nach den Features die man verwendet hat, z.b. Generics, nicht mehr auf .Net 3.0 und .Net 4.0.

    Aber sie laufen noch immer in der entsprechenden Runtime, die 1.0-1.1, 2.0-3.5 und 4.0-4.5.1 können parallel zueinander installiert werden.

    Totschlagargument schrieb:

    Daraus folgt, nur Java gewährleistet Langzeitsicherheit.
    Was früher für Java 1.2 geschrieben und compiliert wurde, läuft heutzutage immer noch auf einer aktuellen JVM.

    Merkwürdig nur das ich in meiner aktiven Java-Zeit (um 1.4 rum) regelmäßig von Java-Versionsinkompatibilitäten gehört habe (Und zwar von Projektleitern in Java-Projekten). Und heute (aber bin außer kurzen Ausflügen nicht mit Java beschäftigt) höre ich noch immer von Zeit zu Zeit ähnliches. Kann sein das sich dies aber auf vergangene Probleme bezieht.

    Totschlagargument schrieb:

    Bei C# ist das nicht so, weswegen Microsoft auch x .Net Versionen auf Windows installiert um alle Varianten abdecken zu können.

    1. Installiert MS in der Regel eine Version, auch wenn man die anderen zusätzlich installieren kann.
    2. Es gibt aktuell 3 Verschiedene Runtimezweige, in diesem ersetzt die Neueste Version immer die Vorherigen.
    3. Manchmal ist das Entrümpeln einer Sprache kein Nachteil. Problematisch ist nur wenn man dies ständig tut.



  • Wir schreiben das Jahr 2014 und GC Sprachen sind immer noch am Leben. Witzig.
    Sogar die Objective-C Leute haben erkannt, dass das alles Mist ist.



  • Kellerautomat schrieb:

    Wir schreiben das Jahr 2014 und GC Sprachen sind immer noch am Leben. Witzig.

    Und die ganzen neuen Sprachen haben auch nen GC. Heute nimrod angeschaut. Echt genial bis auf den GC.



  • IBV schrieb:

    Schau dir mal die Features von Java 8 an. Das hat C# schon lange und noch einiges mehr und bis Java 8 mal in Unternehmen angekommen ist, vergehen mind. (!) 5 Jahre!

    Wir verwenden Java 8 in Produktivcode. Ist ein großes Projekt.

    Java ist einfach eine optimale Wahl für cross Platform + high Performance.



  • Ethon schrieb:

    cross Platform + high Performance

    selten so gelacht 😃



  • Kellerautomat schrieb:

    Ethon schrieb:

    cross Platform + high Performance

    selten so gelacht 😃

    Was ist besser?
    Jetzt kommt sicher C++ oder etwas ähnliches. 🙄


  • Mod

    Ethon schrieb:

    Kellerautomat schrieb:

    Ethon schrieb:

    cross Platform + high Performance

    selten so gelacht 😃

    Was ist besser?

    Besser? Java erfüllt doch gerade diese Punkte nicht. Man ist an eine Plattform gebunden und der erste Gedanke den die meisten Leute zu Java haben ist "langsam". Letzteres mag zwar nicht mehr ganz so schlimm sein wie vor 15 Jahren, aber wenn man von High Performance redet, dann meint man normalerweise etwas, wo die Unterschiede zwischen Fortran und C(++) relevant sind, um mal ein Beispiel aus einem kürzlich vorgekommenen Thread zu zitieren. Java spielt da in einer ganz anderen Liga.

    Jetzt kommt sicher C++ oder etwas ähnliches.

    Im Prinzip ja. Ebenso die anderen großen compilierten Sprachen wie C und Fortran. Plattformvoraussetzung ist eben nicht das Vorhandensein einer fetten JVM, sondern bloß die Möglichkeit, einen Compiler auf der Plattform zu bootstrappen. Letzteres hat man immer, denn sonst wäre die Plattform nutzlos*. Und wie schon gesagt, auch wenn Java mächtig aufgeholt hat, kann es designbedingt niemals diese Sprachen von der Performance einholen.

    *: Es gibt ja sogar C-Compiler für die JVM 🙂



  • SeppJ schrieb:

    Und wie schon gesagt, auch wenn Java mächtig aufgeholt hat, kann es designbedingt niemals diese Sprachen von der Performance einholen.

    Das ist uebrigens ein guter Punkt. Ich koennte mir durchaus vorstellen, dass eine C++ VM statisch kompiliertes C++ outperformen kann durch Optimierungen zur Laufzeit. Das collapsen von Laufzeit-Konstanten koennte beispielsweise sehr interessant sein.
    Ich vermute mal, dass das einfach nur deshalb nicht gemacht wird, weil die C++ Programmierer eine VM direkt mit langsam verbinden. Ich bin davon ueberzeugt, dass das nicht so sein muss.



  • Die VM sehe ich weniger als das Problem - zumindest nicht grundsätzlich. LLVM erzeugt auch erstmal VM Code, und dass der daraus erzeugte Maschinencode recht schnell läuft ist ja nix neues.

    Ich schätze die grösseren Bremsen bei Java sind eher "keine value types", das Memory-Model, der GC, "alles virtual" und "alles safe" (Bounds-Checks, nur checked Casts etc.). Und vielleicht dass das Ding als Stack-Machine statt als Unlimited-Register-Machine ausgelegt ist.
    Die Effekte können durch die VM und die verzögerte JIT Kompilierung zwar deutlich gelindert werden, aber so richtig flott wird die Sache dadurch halt nicht.

    Allerdings werden die Startup-Zeiten dadurch *furchtbar*.
    OK, für Server oder lang laufende Programme ist das natürlich egal.



  • hustbaer schrieb:

    Allerdings werden die Startup-Zeiten dadurch *furchtbar*.
    OK, für Server oder lang laufende Programme ist das natürlich egal.

    Ich denke, das Problem koennte man mit einem Hybrid-Ansatz umgehen. Man kompiliert erstmal ohne Optimierungen und optimiert dann spaeter in einem seperaten Thread. Bzw, man koennte natuerlich genauso bereits einen statischen kompilierten Code zusaetzlich mitliefern und dann zur Laufzeit neu kompilieren.



  • Ja, klar, man könnte viel.
    Dein erster Vorschlag verbessert die Performance vermutlich von "furchtbar" zu "sehr sehr schlimm".
    Dein zweiter Vorschlag ist besser, aber ich kenne keine Plattform wo das umgesetzt wäre.

    Die Android Entwickler arbeiten derzeit an einer VM die ähnlich wie die CLR alles vorkompiliert und dann nur mehr die fertigen native Images lädt. Allerdings soweit ich weiss ohne "nochmal dahinter nach compilieren".

    ps: Vergiss auch nicht dass im native compilierten Code normalerweise keine Profiler Traces mehr erfasst werden. D.h. ich bin gar nicht so sicher wie viel schneller das mit der nötigen Instrumentation laufen würde, nur weil es native compiliert ist.

    ps2: "Man könnte ja" Argumente bei einer Sprache die seit fast 20 Jahren existiert sind auch immer lustig. Wieso hat man nicht schon lange wenn man könnte?


  • Mod

    hustbaer schrieb:

    Ich schätze die grösseren Bremsen bei Java sind eher "keine value types", das Memory-Model, der GC, "alles virtual" und "alles safe" (Bounds-Checks, nur checked Casts etc.). Und vielleicht dass das Ding als Stack-Machine statt als Unlimited-Register-Machine ausgelegt ist.

    +1. Das war es, was ich mit "designbedingt" langsam meinte.

    Kellerautomat schrieb:

    Das ist uebrigens ein guter Punkt. Ich koennte mir durchaus vorstellen, dass eine C++ VM statisch kompiliertes C++ outperformen kann durch Optimierungen zur Laufzeit. Das collapsen von Laufzeit-Konstanten koennte beispielsweise sehr interessant sein.

    Stimme nicht zu. Denn das ist schon ziemlich genau das, was sowieso schon passiert. Zumindest bei mir ist eine profile-guided Optimierung meistens der Ansatz, der am meisten bringt. Ist zwar bei den meisten Compilern recht aufwändig durchzuführen (daher mache ich es nur bei Programmen, bei denen es sich wirklich lohnt), aber wenn man es einmal hat, dann hat man's.
    Letztlich bringt das aber auch nur wenige Prozente gegenüber "normaler" Optimierung, sofern man es nicht mit Absicht drauf anlegt ein Programm zu schreiben, dass die Vorteile dieser Technik demonstriert.



  • Hat jemand von euch schon mal die Unterschiede gebenchmarkt? Bei realistischen, großen Applikationen mit komplexen Datenstrukturen und nicht gerade komplett auf Durchsatz ausgelegter primitiver Datenverarbeitung?

    Meines Wissens nach wird der Unterschied sehr schnell vernachlässigbar.
    Habe auch das Gefühl dass Hotspot hier unterschätzt wird. Nur weil die Sprache prinzipiell vorsieht alle Arrayzugriffe zu prüfen bedeutet das nicht dass diese Prüfungen nicht wegoptimiert werden wenn der Compiler die Richtigkeit beweisen kann - und das kann er oft.

    Für Java spricht weiterhin die super Toolunterstütztung sowie die ganzen Bibliotheken und Frameworks.

    Soll auf keinen Fall hier eine Java vs. C++ Diskussion werden.
    C++ hat durchaus eine Sparte in der es glänzt. Aber garantiert nicht überall.

    Und Java ist (mittlerweile) eine tolle Sache. JavaFX ist super. Mit der Streaming-API und Lambdas lässt es sich richtig schön arbeiten.


  • Mod

    Ethon schrieb:

    Hat jemand von euch schon mal die Unterschiede gebenchmarkt? Bei realistischen, großen Applikationen mit komplexen Datenstrukturen und nicht gerade komplett auf Durchsatz ausgelegter primitiver Datenverarbeitung?

    Der Trick bei solchen Messungen ist halt, dass man sich top auskennen muss mit allen Tricks in allen getesteten Sprachen. Das können nur die wenigsten Einzelpersonen, daher kann das kaum jemand persönlich messen. Also braucht man das Wissen vieler Experten. Es gibt im Netz irgendwo eine Seite, wo jeder Nutzer Programme in einer ihm bekannten Sprache für Benchmarks hinterlegen kann (für vorgegebene Probleme). Die besten C und C++ Programme waren, wenn ich mich recht erinnere, immer so Faktor 2-3 vor Java. Leider finde ich die Seite gerade nicht wieder.
    Einen ganz ähnlichen Test, nicht mit dem Schwarmwissen, sondern mit dem Wissen seiner vielen Entwickler, hat vor einer Weile Google durchgeführt:
    https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
    Erst Vergleich dogmatischer Programme, bei denen Java wieder so um Faktor 4 langsamer ist als C++. Nachdem der Javaexperte das Programm optimiert hatte, war es so schnell wie die C++-Version. Aber nachdem die C++-Experten das C++ Programm optimiert hatten, war dieses aber auch wieder um einen Faktor 3-5 schneller als die ursprüngliche C++-Version. Irgendwie scheint 2-4 so der Faktor zu sein, der bei allen Vergleichen am Ende stehen bleibt.



  • Ethon schrieb:

    Hat jemand von euch schon mal die Unterschiede gebenchmarkt? Bei realistischen, großen Applikationen mit komplexen Datenstrukturen und nicht gerade komplett auf Durchsatz ausgelegter primitiver Datenverarbeitung?

    Ich habe eher den gegenteiligen Eindruck. Bei komplexen Verarbeitungen wird viel Speicher freigegeben und deswegen laeuft oft der Garbagecollector durch, waehrend einfache Sachen komplett ohne auskommen. Ausserdem machen sich nach meiner Einschaetzung die Nachteile durch Type-Erasure und die ganzen virtual-calls, type-casts und geringe Cache-locality so richtig bemerkbar. Natuerlich nur, wenn man C++ nicht selber im Java-Style programmiert.

    Ethon schrieb:

    Soll auf keinen Fall hier eine Java vs. C++ Diskussion werden.
    C++ hat durchaus eine Sparte in der es glänzt. Aber garantiert nicht überall.

    Ich sehe das eher anders herum. Java wurde als Programmiersprache fuer fast alle Anwendungsfelder designed oder zumindest von vielen als das angesehen. Aber das ist Java nicht.
    C und C++ hingegen sind als hardwarenahe, schnelle Sprachen entwickelt worden und haben als Einsatzzwecke Betriebssystemskomponenten und performancehungrige Anwendungen. Wer kleine GUI-Anwendungen in C++ schreibt ist selbst Schuld ueber die verlorene Zeit und plattformabhaengigkeit.



  • Marthog schrieb:

    Ich sehe das eher anders herum. Java wurde als Programmiersprache fuer fast alle Anwendungsfelder designed oder zumindest von vielen als das angesehen. Aber das ist Java nicht.

    Sorry.
    google "OAK language"! Und folge ein paar Links. Java ist für Waschmaschinen und Toaster designed worden und passt da perfekt. Genau da sind die Vorteile:
    - dümmstmögliche Programmierer einstellbar (GC etc…)
    - VM (Prozessorhersteller liefert die VM, Waschmaschinenhersteller baut neuen billigeren besseren Prozessor ein ohne eine Sekunde Anpassung)
    google noch ein wenig mehr.



  • @Ethon
    Ich will Java auch nicht seine Daseinsberechtigung absprechen.
    Schon alleine auf Grund der mächtigen Libraries und Tools ist Java für viele Anwendungsbereiche eine Tolle Sachen (tm).

    Wenn's aber um rohe Performance geht, dann hat C++ momentan noch in vielen Bereichen die Nase vorne.



  • SeppJ schrieb:

    Einen ganz ähnlichen Test, nicht mit dem Schwarmwissen, sondern mit dem Wissen seiner vielen Entwickler, hat vor einer Weile Google durchgeführt:
    https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
    Erst Vergleich dogmatischer Programme, bei denen Java wieder so um Faktor 4 langsamer ist als C++. Nachdem der Javaexperte das Programm optimiert hatte, war es so schnell wie die C++-Version. Aber nachdem die C++-Experten das C++ Programm optimiert hatten, war dieses aber auch wieder um einen Faktor 3-5 schneller als die ursprüngliche C++-Version.

    Und das war bei einem Programm, dass so einfach war, das ein Mann es einfach mal vier mal schneller machen kann. Das zeigt doch eigentlich nur, dass der Entwickler einen viel größeren Einfluss auf die Performance hat, als die Sprache. Und die meisten Java-Entwickler verwenden Java, weil es einfacher als C++ war, als sie eine Sprache lernen mussen, was wieder einen Rückschluss auf die Qualität der Entwickler zulässt. Außerdem habe ich den Eindruck, dass fast alle größeren Java-Programme ein Haufen zusammengeklebter Frameworks ist, der mit etwas spezial Logik versehen wird und fast kein Java-Entwickler im Detail weiß, was sein Maven-Apache-Database-Hibernate-EJB-Spring generiertes Programm so macht, weder auf Laufzeitkomplexitätsebene und noch viel weniger auf der Ebene was die Ausführungsgeschwindigkeit von bestimmtem Code angeht.


Anmelden zum Antworten