Scala est-il prêt pour les heures de grande écoute? [fermé]

Maintenant que j'ai fait quelques petites choses avec Scala (que j'aime pour «bonjour le monde» et les applications artificielles!), Je me pose des questions .. une partie sur la maturité des outils pour soutenir le développement et une partie sur l'applicabilité générale. Les ensembles d'outils sont-ils prêts? Scala est-il approprié pour une utilisation sur des applications d'entreprise / d'entreprise? Souhaitez-vous l'utiliser sur un projet non trivial?

Certaines de mes préoccupations (peut-être non fondées) seraient:

• l'IDE et les outils sont-ils aussi riches que ce que nous avons pour développer des applications .net et java (eclipse pour Scala semble limité par rapport à eclipse pour java)?
• les jeux d'outils build / CI / testing sont-ils capables de gérer efficacement Scala?
• Dans quelle mesure le code concis qui peut être (encouragé?) peut-il être maintenu dans la langue?
• est-il possible de trouver des développeurs ayant une expérience Scala?
• y a-t-il suffisamment de masse critique pour obtenir de l'aide par le biais de références en ligne et d'ouvrages qui sont plus qu'une «introduction» à la langue?

Donc, l'essentiel - l'écosystème est-il suffisamment mature pour être utilisé maintenant, ou mieux vaut attendre de voir comment il évolue?

EDIT: disons que "non trivial" est un projet de développement de 10 à 20 ans, multi-versions et multi-versions.

S'il est vrai que Scala a été utilisé dans la nature chez The Guardian et sur Twitter, il y a une préoccupation fondamentale.

Une grande partie de la popularité de Java vient du fait qu'il est relativement facile à lire et à entretenir. Scala a un problème ici car il peut être écrit dans de nombreux styles différents. Le style OO vs le style fonctionnel est la division évidente ici, mais cela devient plus compliqué lorsque vous parlez des 3 niveaux de Scala .

Vous devez vous assurer que votre équipe et toutes les nouvelles recrues potentielles peuvent toutes suivre le même style, et que le style est assez simple pour que vous puissiez réellement embaucher des développeurs qui peuvent être efficaces (tout le monde ne peut pas embaucher les 2% les plus performants) .

Le support d'outillage n'est pas encore tout à fait là encore, bien que je m'attende à ce que cet écart soit comblé assez rapidement. Vous pouvez également obtenir un support pour la pile Scala complète de la foule TypeSafe . Je pense que Scala va se tailler une niche, mais jusqu'à ce que les niveaux soient réellement intégrés dans le langage / compilateur / quoi que ce soit, je vois un mal de tête de maintenance sur les équipes après les 1-2 premières années de productivité excitée.

Voir cette réponse connexe pour plus de détails.

Scala est actuellement utilisé par Twitter et par The Gaurdian, il est donc certainement prêt pour des applications non triviales.

Les programmeurs Scala vont être très motivés et probablement très bons. Le choix d'une nouvelle langue est un excellent moyen d'attirer des talents.

Bien sûr, les programmeurs Scala n'ont souvent pas d'expérience professionnelle Scala, et il peut y avoir une certaine variété dans les idiomes qu'ils utilisent. Certains peuvent s'efforcer d'obtenir une pureté semblable à Haskell, tandis que d'autres peuvent la considérer comme Java avec des fermetures. Il faudra donc probablement un certain temps pour élaborer des normes et des conventions de codage cohérentes.

De nombreux outils Java fonctionneront bien, même si IntelliJ Idea vaudra probablement l'investissement sur Eclipse.

Dans l'ensemble, cela pourrait être un bon choix si vous contrôlez le projet. Si cela fait partie d'une grande compagnie d'assurance, vous pouvez rencontrer des problèmes s'il existe des directives architecturales telles que: «Tous les projets doivent être construits par Maven et déployés dans WebSphere». (Je n'ai aucune raison de penser que cette règle particulière serait un problème, mais une prolifération de ces règles pourrait vous faire trébucher à un moment donné.)

J'ai l'impression qu'une grande partie de l'écosystème qui accompagne les langages "conventionnels" (comme Java) est destiné à compenser leur maladresse.

La question n'est pas de savoir combien d'outils il y a pour une langue donnée (Scala), mais si les outils existants pour cette langue sont meilleurs que les outils existants pour la langue de référence (Java). Parce que 100 outils médiocres ne vous donneront pas, ce qu'un bon outil peut vous donner. Et une chose que vous ne devez pas oublier, c'est que la langue elle-même fait partie de ces outils.

Le caractère déclaratif d'une langue

• est inversement proportionnelle à la quantité et à la gravité des bogues que vous produisez avec, c'est pourquoi Java est si bon pour produire des bogues et vous avez besoin de beaucoup d'outils pour les éviter et les suivre
• est proportionnelle à votre productivité, c'est pourquoi Java est extrêmement verbeux et vous avez besoin de beaucoup de générateurs de code et d'outils similaires

Par exemple, j'ai lu une fois un article de blog horrible par un gars de Ruby, qui a fait valoir que la saisie statique est inutile, car vos tests couvriront la sécurité des types. Cela venait clairement de quelqu'un qui n'avait pas encore travaillé avec un système de type statique expressif. En supposant que je puisse représenter toutes les relations de type dans une sémantique de langue et que ce n'est pas beaucoup de travail à faire (et ce n'est pas le cas, puisque la plupart des langues modernes prennent en charge l'inférence de type), j'obtiens tout cela gratuitement.

Pour pousser une pensée un peu plus en avant: les tests unitaires garantissent qu'une unité agit comme spécifié, ou pour la reformuler, les tests unitaires sont des spécifications exécutables. Cependant, grâce à la programmation déclarative, les unités elles-mêmes sont des spécifications exécutables. Encore une fois, vous obtenez quelque chose gratuitement.

Ce que j'essaie de dire, c'est que vous ne devriez pas sous-estimer ce que les fonctionnalités du langage peuvent faire pour vous. Et à moins de vraiment les essayer sur le terrain, vous ne comprendrez jamais.

Revenons donc à la question initiale: les outils existants pour Scala sont-ils meilleurs que pour Java? Dur à dire. Cela dépend de ce que vous voulez faire. Je pense que nous serions tous d'accord pour dire que le langage est nettement meilleur, maintenant la question est de savoir à quel point un écosystème est bon dans votre secteur d'activité.
Pour le Web, Lift est vraiment une option solide. Je ne connais pas le bureau ou le mobile.

disons que "non trivial" est un projet de développement de 10 à 20 ans sur plusieurs versions.

Ça fait beaucoup de risques. Les récompenses devraient en valoir la peine. Dans le monde des applications d'entreprise et des projets de taille moyenne à grande, la prise de risque est généralement limitée. Ou plutôt il y a déjà suffisamment de risques à gérer ... La prévisibilité est plus importante.

Je doute que l'adoption fonctionnera de cette façon.

Il est plus probable qu'il commence par une poignée de personnes travaillant sur une partie où le risque est contenu, comme le POC, les composants non critiques, les tests ou les pièces où le problème semble être traité bien mieux par Scala que les alternatives (peut-être si quelque chose implique (acteur par exemple)

En tirant parti du runtime Java, Scala est certainement prêt pour les heures de grande écoute. Si vous pouvez déployer une application Scala, une fois le bytecode généré, il doit toujours fonctionner avec cette version particulière du runtime Java. La bibliothèque basée sur Scala fonctionnera comme n'importe quelle autre bibliothèque tierce Java que vous connaissez.

En termes d'IDE, d'outils de construction et de tout le reste, Scala n'a pas le même niveau de prolifération que Java. Vous n'avez donc pas beaucoup de frameworks ou d'outils basés sur Scala. Cela a plus à dire avec la popularité de Java qu'avec la popularité croissante de Scala. Scala possède des outils fonctionnels, dont Scala IDE et sbt, outil de construction. Mais ils ne sont pas aussi sophistiqués que certains des autres outils d'assistance Java purs.

Points de sélection de cerises de @huynhjl et @FarmBoy:

• Trouver un nombre suffisant de programmeurs Scala expérimentés pourrait être difficile.

• Le dogme des «meilleures pratiques» pour Scala évolue toujours (*).

• Les guides de style, les conventions, etc. évoluent toujours (*).

• La prise en charge des outils évolue toujours (*).

En les rassemblant, une meilleure question à vous poser (vous-même / vous-même) est peut-être de savoir si votre organisation est prête à utiliser Scala sur un projet "non trivial"? Avez-vous les gens qui peuvent faire face à un grand projet avec tant de choses "en constante évolution"? Inversement, serait-il préférable de commencer par un projet plus petit?

(* En fait, la plupart des langues évoluent toujours dans un ou plusieurs de ces aspects. Le problème ici est le taux de changement / flux ... et si votre équipe peut y faire face.)

David Pollak chez Good Stuff a un excellent article de blog intitulé Functional Languages ​​will Rule (mais pas cette année) qui va dans le vif du sujet des langages fonctionnels en général, et Scala en détail que je recommande fortement de lire pour mieux comprendre si Scala est prêt pour les heures de grande écoute.

Je n'ai jamais compris la distinction entre enterpriseet les non enterpriseprogrammes.

J'utilise les mêmes programmes au travail qu'à la maison. Je n'utiliserais pas un programme médiocre pendant mon temps libre - pourquoi devrais-je?

Qu'est-ce qu'un programme non professionnel? J'ai vu de mauvaises applications utilisées, car l'utilisateur ne savait pas mieux, à cause de problèmes de compatibilité, ou l'utilisateur a refusé de trouver quelque chose de nouveau.

Mais c'est un problème de logiciel obsolète et d'objectifs, le développeur avait à l'esprit - pas la langue, le programme était écrit. Si vous commencez à penser, dans quelle langue un programme est écrit, c'est déjà fini: échec.

Enterprise-application est un terme marekting, qui n'est pas utile pour une discussion sérieuse.

Et quel client sait dans quelle langue vous avez fait votre travail? Parfois, ils s'en soucient, parfois non.

Vous pouvez avoir des questions liées à la maturité d'une langue - mais vous ne pouvez pas répondre à la question pour tous les types d'entreprises et toutes les applications.