Ist Scala bereit für die Hauptsendezeit? [geschlossen]

Jetzt, wo ich ein paar Kleinigkeiten mit Scala gemacht habe (die ich für "Hallo Welt" und erfundene Anwendungen liebe!), Frage ich mich .. zum Teil über die Reife der Tools zur Unterstützung der Entwicklung und zum Teil über die allgemeine Anwendbarkeit. Sind die Toolsets fertig? Ist Scala für den Einsatz in Unternehmensanwendungen geeignet? Würden Sie es für ein nicht triviales Projekt verwenden?

Einige meiner (möglicherweise unbegründeten) Bedenken wären:

• Sind die IDE und die Toolsets so umfangreich wie das, was wir für die Entwicklung von .NET- und Java-Anwendungen benötigen? (Eclipse für Scala scheint im Vergleich zu Eclipse für Java begrenzt zu sein.)
• Können die Build / CI / Testing-Toolsets effektiv mit Scala umgehen?
• wie wartbar ist die kurze Code, kann sein (ermutigt?) in der Sprache geschrieben?
• ist es möglich, Entwickler mit Scala-Erfahrung zu finden?
• Gibt es genug kritische Masse, um Hilfe durch Online-Nachschlagewerke und Bücher zu erhalten, die mehr als nur ein "Intro" für die Sprache sind?

Unterm Strich ist das Ökosystem also ausgereift genug, um es jetzt zu nutzen, oder besser noch abzuwarten, wie es sich entwickelt?

BEARBEITEN: Nehmen wir an, "non-trivial" ist ein mehrjähriges 10-20 Entwickler-Projekt mit mehreren Releases.

Während es stimmt, dass Scala im Guardian und bei Twitter in freier Wildbahn eingesetzt wurde, gibt es ein grundlegendes Anliegen.

Ein großer Teil der Popularität von Java beruht auf der Tatsache, dass es relativ einfach zu lesen und zu warten ist. Scala hat hier ein Problem, da es in vielen verschiedenen Stilen geschrieben werden kann. OO-Stil versus funktionaler Stil ist hier die offensichtliche Trennung, aber es wird komplizierter, wenn man über die drei Stufen von Scala spricht .

Sie müssen sicherstellen, dass Ihr Team und alle potenziellen Neueinstellungen dem gleichen Stil folgen können und dass der Stil so einfach ist, dass Sie tatsächlich Entwickler einstellen können, die effektiv sein können (nicht jeder kann die besten 2% einstellen). .

Die Werkzeugunterstützung ist auch noch nicht ganz da, obwohl ich davon ausgehe, dass diese Lücke ziemlich schnell geschlossen wird. Sie können auch Unterstützung für den gesamten Scala-Stapel von der TypeSafe- Crowd erhalten. Ich denke, Scala wird seine Nische herausarbeiten, aber bis die Level tatsächlich in die Sprache / den Compiler / was auch immer eingebaut sind, sehe ich Wartungsprobleme bei den Teams nach den ersten 1-2 Jahren aufgeregter Produktivität.

Weitere Informationen finden Sie in dieser Antwort .

Scala wird derzeit von Twitter und The Gaurdian verwendet, sodass es auf jeden Fall für nicht-triviale Anwendungen geeignet ist.

Scala-Programmierer werden sehr motiviert sein und wahrscheinlich sehr gut. Die Wahl einer neuen Sprache ist eine großartige Möglichkeit, Talente anzuziehen.

Natürlich verfügen Scala-Programmierer häufig nicht über professionelle Scala-Erfahrung, und die verwendeten Redewendungen können etwas unterschiedlich sein. Einige streben möglicherweise nach Haskell-ähnlicher Reinheit, während andere Java mit Closures betrachten. Es wird also wahrscheinlich einige Zeit dauern, um einheitliche Codierungsstandards und -konventionen zu entwickeln.

Viele Java-Tools werden gut funktionieren, obwohl IntelliJ Idea die Investition über Eclipse wahrscheinlich wert sein wird.

Insgesamt könnte es eine gute Wahl sein, wenn Sie die Kontrolle über das Projekt haben. Wenn dies Teil eines großen Versicherungsunternehmens ist, kann es zu Problemen kommen, wenn Architekturrichtlinien vorliegen wie: "Alle Projekte müssen von Maven erstellt und in WebSphere implementiert werden." (Ich habe keinen Grund zu der Annahme, dass diese spezielle Regel ein Problem darstellt, aber eine Verbreitung solcher Regeln könnte Sie irgendwann stören.)

Mein Eindruck ist, dass ein Großteil des Ökosystems, das mit "konventionellen" Sprachen (wie Java) geliefert wird, ihre Ungeschicklichkeit ausgleichen soll.

Die Frage ist nicht, wie viele Tools es für eine bestimmte Sprache gibt (Scala), sondern ob die vorhandenen Tools für diese Sprache besser sind als die vorhandenen Tools für die Referenzsprache (Java). Weil 100 mittelmäßige Werkzeuge Ihnen nicht geben werden, was ein gutes Werkzeug Ihnen geben kann. Und eine Sache, die Sie nicht vergessen sollten, ist, dass die Sprache selbst Teil dieser Werkzeuge ist.

Die Deklarativität einer Sprache

• ist umgekehrt proportional zur Menge und Schwere der Fehler, die Sie damit verursachen. Deshalb ist Java so gut darin, Fehler zu erzeugen, und Sie benötigen eine Menge Werkzeuge, um diese zu vermeiden und zu verfolgen
• ist proportional zu Ihrer Produktivität, weshalb Java so ausführlich ist und Sie viele Codegeneratoren und ähnliche Tools benötigen

Zum Beispiel habe ich einmal einen schrecklichen Blog-Beitrag von einem Ruby-Typen gelesen, der argumentierte, statische Typisierung sei sinnlos, weil Ihre Tests die Typensicherheit abdecken. Dies kam eindeutig von jemandem, der noch nicht mit einem expressiven statischen Typensystem gearbeitet hatte. Vorausgesetzt, ich kann alle Typbeziehungen in einer Sprachsemantik darstellen und es ist nicht viel Arbeit zu tun (und das ist es auch nicht, da die meisten modernen Sprachen die Typinferenz unterstützen), bekomme ich das alles kostenlos.

Um einen Gedanken etwas voranzutreiben: Unit-Tests stellen sicher, dass eine Unit wie angegeben funktioniert, oder, um es anders auszudrücken, Unit-Tests sind ausführbare Spezifikationen. Durch deklarative Programmierung sind die Einheiten selbst jedoch ausführbare Spezifikationen. Auch hier bekommen Sie etwas umsonst.

Ich versuche zu sagen, dass Sie nicht unterschätzen sollten, was Sprachfunktionen für Sie tun können. Und wenn Sie sie nicht wirklich im Feld ausprobieren, werden Sie es nie verstehen.

Um auf die ursprüngliche Frage zurückzukommen: Sind die vorhandenen Tools für Scala besser als für Java? Schwer zu sagen. Kommt darauf an, was du machen willst. Ich denke, wir sind uns alle einig, dass die Sprache deutlich besser ist. Jetzt stellt sich die Frage, wie gut ein Ökosystem in Ihrem Geschäftsbereich ist.
Für das Web ist Lift wirklich eine gute Option. Keine Ahnung von Desktop oder Mobile.

Nehmen wir an, "non-trivial" ist ein mehrjähriges 10-20-Entwickler-Projekt mit mehreren Releases.

Das ist eine Menge Risiken. Die Belohnungen müssten es wert sein. In der Welt der Unternehmensanwendungen für Unternehmen und der mittleren bis großen Projekte ist das Eingehen von Risiken normalerweise begrenzt. Besser gesagt, es gibt bereits genug Risiken, um damit umzugehen ... Vorhersehbarkeit ist wichtiger.

Ich bezweifle, dass die Adoption so funktionieren wird.

Es ist wahrscheinlicher, als eine Handvoll Leute an einem Teil zu arbeiten, in dem das Risiko enthalten ist, wie z. B. POC, nicht kritische Komponenten, Tests oder Teile, bei denen das Problem von Scala anscheinend viel besser als Alternativen angegangen wird (wenn etwas involviert ist) Schauspieler zum Beispiel) ... Wenn Werkzeuge ausgereift sind, wächst die Community, das Know-how im Unternehmen wächst und es könnte sich erweitern.

Durch die Nutzung der Java-Laufzeit ist Scala auf jeden Fall bereit für die Hauptsendezeit. Wenn Sie eine Scala-Anwendung bereitstellen können, sollte sie nach dem Generieren des Bytecodes immer mit dieser bestimmten Version der Java-Laufzeitumgebung funktionieren. Die auf Scala basierende Bibliothek funktioniert wie jede andere Java-Bibliothek von Drittanbietern, mit der Sie vertraut sind.

In Bezug auf IDEs, Build-Tools und alles andere verfügt Scala nicht über den gleichen Grad an Verbreitung wie Java. Sie haben also nicht viele Scala-basierte Frameworks oder Scala-basierte Tools. Das hat mehr mit Javas Popularität zu tun als mit Scalas wachsender Beliebtheit. Zu den funktionalen Tools von Scala gehören die Scala-IDE und das Build-Tool sbt. Aber sie sind nicht annähernd so hoch entwickelt wie einige der anderen reinen Java-Hilfsprogramme.

Cherry-Picking-Punkte von @huynhjl und @FarmBoy:

• Es könnte schwierig sein, eine ausreichende Anzahl erfahrener Scala-Programmierer zu finden.

• Das "Best Practice" -Dogma für Scala entwickelt sich noch weiter (*).

• Styleguides, Konventionen usw. sind noch in der Entwicklung (*).

• Die Werkzeugunterstützung wird noch weiterentwickelt (*).

Wenn Sie diese zusammenfassen, ist es vielleicht eine bessere Frage für Sie (sich selbst), ob Ihre Organisation bereit ist, Scala für ein "nicht-triviales" Projekt einzusetzen? Haben Sie die Leute, die mit einem großen Projekt fertig werden, bei dem sich so viele Dinge "noch weiterentwickeln"? Wäre es umgekehrt besser, zuerst ein kleineres Projekt durchzuführen?

(* In der Tat sind die meisten Sprachen noch in einer oder mehrere dieser Hinsicht weiterentwickelt. Die Frage ist hier die Rate der Änderung / Fluss ... und ob Ihr Team damit umgehen kann.)

David Pollak von Good Stuff hat einen ausgezeichneten Blog-Beitrag mit dem Titel Functional Languages ​​will Rule (aber nicht in diesem Jahr) , der sich mit funktionalen Sprachen im Allgemeinen befasst, und Scala im Detail zur Hauptsendezeit.

Ich habe den Unterschied zwischen enterpriseund non enterpriseProgrammen nie verstanden .

Ich verwende auf der Arbeit die gleichen Programme wie zu Hause. In meiner Freizeit würde ich kein mittelmäßiges Programm verwenden - warum sollte ich?

Was ist ein nicht professionelles Programm? Ich habe gesehen, dass schlechte Anwendungen verwendet wurden, weil der Benutzer es aufgrund von Kompatibilitätsproblemen nicht besser wusste oder sich weigerte, etwas Neues zu lernen.

Aber es ist ein Problem mit veralteter Software und mit den Zielen, die der Entwickler im Auge hatte - nicht mit der Sprache, in der das Programm geschrieben wurde.

Enterprise-application ist ein Begriff, der für ernsthafte Diskussionen nicht nützlich ist.

Und welcher Kunde weiß, in welcher Sprache Sie Ihre Arbeit geleistet haben? Manchmal interessiert es sie, manchmal nicht.

Möglicherweise haben Sie Fragen, die sich auf die Reife einer Sprache beziehen, aber Sie können die Frage nicht für alle Arten von Unternehmen und Anwendungen beantworten.