Zum Beispiel stoße ich auf Entwickler und Architekten, die Angst vor dem Tod von Rails-Apps haben, aber die Idee lieben, neue Grails-Apps zu schreiben.
Nach dem, was ich gesehen habe, gibt es eine Menge Ressourcen-Overhead, der in die Verwendung der JVM zur Unterstützung von Sprachen wie Groovy, JRuby und Jython anstelle von reinem Ruby oder Python fließt.
Ruby und Python können beide auf fast jedem Betriebssystem interpretiert werden, daher sehe ich keinen "Einmal schreiben, nirgendwo rennen" Vorteil ... warum sollten Sie die riesige JVM mitnehmen?
Java ist eine viel, viel ausgereiftere Plattform, mit vielen vorhandenen Klassenbibliotheken, die "hineingelegt" und verwendet werden könnten, als beispielsweise Ruby oder Python (oder sogar Perl, für diese Angelegenheit). Für Leute, die gerne vorhandenen Code verwenden, anstatt alles selbst zu schreiben, ist Java ein großer Gewinn.
Zum Beispiel habe ich kürzlich nach etwas wie JAXB für Python oder Ruby gesucht. Am Ende habe ich JRuby verwendet, nur weil ich keine ausgereiften, weit verbreiteten XML-bindenden Bibliotheken gefunden habe.
Der große Vorteil des Schreibens von Code (in jeder Sprache) für die JVM ist, dass es in der Regel sehr einfach ist, die riesige Fülle von ausgereiften Java-Bibliotheken da draußen zu nutzen, falls nötig.
Und ich weiß nicht, woher Sie diese Idee einer "hulking" JVM mit einem riesigen Ressourcenaufwand bekommen haben. Der JIT tendiert dazu, Code zu produzieren, der ziemlich schnell ist, und die Kern-JVM ist nach heutigen Standards alles andere als riesig. Es hat tendenziell einen großen Speicherbedarf beim Laufen, aber das liegt daran, dass moderne Maschinen viel RAM haben und der GC am besten funktioniert, wenn er viel RAM zum Spielen hat. Wenn gewünscht, kann der GC auf die Hölle und zurück abgestimmt sein , um konservativer zu sein.
Wie jemand anders es ausdrückt: "Das Beste an Groovy ist, dass ich Java nicht benutzen muss. Das zweitbeste an Groovy ist, dass ich kann benutze Java ".
Eine Annahme, die in die Frage eingebaut scheint, ist, dass neue Projekte Greenfield-Projekte sind. Viele Organisationen haben in den letzten zehn Jahren eine riesige Investition in Java getätigt und verlangen, dass jedes neue Projekt innerhalb des bestehenden (internen) Code-Ökosystems funktioniert. Wie bereits erwähnt, gibt es einen großen Bonus in allen öffentlich verfügbaren Java-Bibliotheken (ob frei / OSS oder kommerziell), aber die Notwendigkeit, mit vorhandenem Code zu arbeiten und sogar als Komponente innerhalb eines bestehenden Systems, ist mindestens genauso wichtig (wenn nicht mehr) so) zu großen Organisationen.
Es hängt auch viel von der Reife und Leistungsfähigkeit der Plattform ab, also der JVM und allem, was dazu gehört (das gesamte Java-Ökosystem). Ein paar Beispiele aus dem Kopf:
Sie können einen entfernten Debugger an eine laufende JVM anschließen und alle Arten von Informationen über eine laufende Anwendung erhalten, die mit Python, Ruby usw. einfach unmöglich ist. Einen Schritt weiter geht es mit JMX , eine Standardmethode zum Schreiben von Code, damit Objekte in einer Live-Anwendung überwacht und sogar optimiert werden können. Sieh dir JConsole an und schau, ob du nicht ein bisschen sabberst (trotz der Hässlichkeit der Schnittstelle).
Um noch weiter in diese Richtung zu gehen, gibt es OSGi , einen Standard für das Schreiben von hochgradig modularem Code implementiert, gestartet, gestoppt und sogar in einer Live-Anwendung aktualisiert. Mit OSGi brechen Sie eine große Anwendung in viele kleinere "Bundles" auf, die dann separat verwaltet (bereitgestellt, gestartet / gestoppt, aktualisiert) werden können. Dies ist bei großen Anwendungen oder bei Anwendungen, die ständig ausgeführt werden müssen, eine große Sache.
Die Plattform hat sehr gute Unterstützung für asynchrones, zuverlässiges Messaging. Sie erhalten JMS als Grundlage und viele ausgezeichnete und leistungsfähige Bibliotheken, die darauf aufbauen, um komplizierte Dinge mit sehr wenig Code zu machen (vgl . Apache Camel , ServiceMix , Mule und viele andere). Dies ist ein weiteres Feature, das in größeren Anwendungen oder solchen, die innerhalb eines größeren Code-Universums ausgeführt werden müssen, äußerst nützlich ist.
Die JVM hat echtes (OS-level) Threading, während Python et al. sind in dieser Hinsicht sehr eingeschränkt (notorisch so). (Das heißt, Shared State Concurrency - Threading - ist der falsche Ansatz; vgl. Erlang , Alice , Mozart / Oz usw.)
Es gibt zahlreiche JVM-Optionen, die über die Standard-Sun-Implementierungen hinausgehen, wie JRockit . IBM JVM, etc. Dies ist ein Entwicklungsgebiet mit anderen Sprachen - Python hat Jython, Iron Python, sogar PyPy und Stackless; Ruby hat JRuby, Rubinius und andere - aber so gut wie diese sind sie kann die in den verschiedenen JVM-Angeboten gefundene Reife nicht erreichen.
Alles was gesagt wird, ich mag Java die Sprache wirklich nicht und meide es so gut wie möglich. In diesen Tagen mit all den ausgezeichneten alternativen Sprachen für die JVM muss ich nicht. Groovy bekommt meine Stimme für seine Zugänglichkeit und enge Integration mit der Plattform (und sogar der Sprache), und wegen Grails, die ich manchmal "Rails für Erwachsene" nenne. Ich mag andere JVM-Sprachen besser, besonders Clojure und Scala , aber diese sind für den durchschnittlichen Programmierer nicht so zugänglich. Scala taucht jedoch in letzter Zeit sehr häufig auf, vor allem dank seiner Verwendung bei Twitter < Es gibt Hoffnung auf interessante und wirklich ausgezeichnete Sprachen, die es in größeren Umgebungen schaffen. Aber das ist ein anderes Thema.
Warum bringst du JVM mit dir zusammen?
JVM ist nicht aufgebläht, noch ist es langsam. im Gegenteil, es ist eine schlanke, schnelle, zutiefst optimierte VM. Leider ist es für statische OOP-Sprachen optimiert.
Dennoch erstellen gute Compiler, die auf JVM abzielen, Programme mit guter Leistung. Ich weiß nichts über JRuby; aber Jython's Ziel ist es, viel schneller zu sein als reguläres C Python, und sie nähern sich (es ist schon schneller bei mehreren wichtigen Anwendungsfällen).
Denken Sie daran, dass ein guter JIT (wie der für JVM) einige Optimierungen anwenden kann, die auf statischen C-Compilern nicht verfügbar sind, schnellerer Code von ihnen zu erhalten, ist kein Wunschtraum. Natürlich sollte eine für Ihre Sprache optimierte VM schneller sein als eine nicht-wirklich-generische VM wie JVM; Aber da ist das Reifeproblem: JVM hat eine Menge Arbeit dort, während JITs für Ruby und Python nicht in der Nähe sind.
Leider scheint es keine bessere generische Bytecode-VM zu geben. Microsofts CLI leidet unter ähnlichen Einschränkungen wie JVM (IronPython ist viel langsamer und schwerer als JPython). Der beste Kandidat scheint LLVM zu sein. Weiß jemand, warum gibt es keine dynamischeren Sprachen über LLVM? Ich habe ein paar Scheme-Compiler gesehen, aber sie scheinen einige Probleme zu haben.
Groovy ist keine interpretierte Sprache, es ist eine dynamische Sprache. Der Groovy-Compiler erzeugt JVM-Bytecode, der wie jede andere Java-Klasse innerhalb der JVM läuft. In diesem Sinne ist groovy genau wie Java und fügt der Java-Sprache einfach eine Syntax hinzu, die nur für Entwickler und nicht für die JVM von Bedeutung ist.
Entwicklerproduktivität, Einfachheit und Flexibilität der Syntax machen groovy attraktiv für das Java-Ökosystem - Ruby oder Python wäre genauso attraktiv, wenn sie zu Java-Bytecode führen würden (siehe jython).
Java-Entwickler haben keine Angst vor Ruby; in der Tat viele schnell umarmen groovy oder jython sowohl in der Nähe von Rubin und Python. Was sie nicht interessiert, ist so eine erstaunliche Plattform (Java) für eine weniger performante, weniger skalierbare, noch weniger benutzte Sprache wie Ruby (für all ihre Verdienste) zu verlassen.
Der große Nachteil von RoR ist, dass es nicht skalierbar und schwer zu implementieren ist. Mit der Java-Plattform können Sie Ihre vorhandene Infrastruktur nutzen.
%Vor%Erzeugt eine WAR-Datei, die leicht auf Glassfish, Jboss, etc. bereitgestellt werden kann.
Ruby und Python können beides sein auf fast jedem Betriebssystem interpretiert, also ich sehe keinen "Schreibe einmal laufen überall "Vorteil ... warum bringen die große JVM mit Ihnen zusammen?
Vor allem, weil Sie das riesige bestehende Ökosystem von Java-Bibliotheken, APIs und Produkten nutzen möchten, das alles, was für Ruby oder Python verfügbar ist, insbesondere in der Unternehmensdomäne, in den Schatten stellt.
Denken Sie auch daran, dass JRuby und Jython in vielen Benchmarks schneller sind als die regulären (C-Implementierungen) der Sprachen, insbesondere Ruby (sogar Ruby 1.9).
Mehrere Sprachen, die auf dieselbe virtuelle Maschine abzielen, bieten viele Vorteile, wie die Nutzung einer gemeinsamen Infrastruktur, Wiederverwendung von Code, gemeinsame APIs, die Möglichkeit, die für Sie oder eine bestimmte Problemdomäne am besten geeignete Sprache zu verwenden .
Die gleichen Dinge passieren im .NET-Raum mit mehreren Sprachen , die auf die CLR abzielen. Das VM-Projekt Parrot (vaporware) zielt ebenfalls auf dasselbe ab, und es ist ein erklärtes Ziel des LLVM Projekt auch.
Ich bin auf dieses Problem gestoßen und habe auch darüber verblüfft, und hier ist meine Theorie.
Enterprise-Software ist voll von Java-Programmierern. Wie Programmierer aller Couleur sind auch viele Java-Programmierer davon überzeugt, dass ihre Sprache die schnellste, flexibelste und am einfachsten zu bedienende Sprache ist - sie sind nicht sehr vertraut mit anderen Sprachen, sind aber davon überzeugt, dass es sich bei Barbaren um Wilde und Barbaren handeln muss , denn jede erleuchtete Person würde natürlich Java benutzen.
Diese Leute haben riesige, komplizierte Java-Infrastrukturen aufgebaut: rube-goldberg-Maschinen von Frameworks und automatisch generiertem Code voller byzantinischer Vererbungsstrukturen und sehr, sehr großer XML-Dateien.
Also, wenn jemand vorbeikommt und sagt: "Hey! Lass uns eine C-interpretierte Sprache benutzen! Sie ist schnell und hat ordentliche Bibliotheken und ist viel schneller für Scripting und Prototyping!" Der Java-Typ ist zuerst wie "Ich muss eine make-Datei ausführen, um dies zu konfigurieren? QUEL HORREUR!" Dann beginnt die Implementierung und das Hosten dieses Servers auf Servern, auf denen veraltete Betriebssysteme und veraltete Versionen von Tomcat ausgeführt werden, und nichts anderes mehr.
"Hey, ich weiß! Es gibt eine Java-Version dieser interpretierten Sprache! Sie kann in der Hauptverkehrszeit auf der Überholspur auf der Brücke zusammenbrechen, und sie fängt manchmal an zu brennen, aber ich kann Tomcat dazu bringen, sie zu führen. Ich muss mir nicht die Hände schmutzig machen, wenn ich Nicht-Java-Zeug lerne, und ich kann es in die vorhandene Infrastruktur schleudern! Gewinne! "
Also, ist das der "richtige" Grund dafür, eine Java-Implementierung einer Skriptsprache zu wählen? Wahrscheinlich nicht. Kommt auf Ihre Definition von "richtig" an. Aber ich vermute, dass das der Grund ist, warum sie häufiger ausgewählt werden als Snobs, wie ich es gerne glauben würde.