Aller au contenu

Le fil des geeks informatiques


Johnnieboy

Messages recommandés

Quelques boîtes utilisant notablement scala (front end / back office ou les deux) :

 

AppJet

Atlassian

Cisco Systems

Cloudify

Amazon.com

Autodesk Inc

Cake Solutions

Credit Suisse

Crossing-Tech SA

eBay Inc.

Elmar Reizen bv

CSC

EDF Trading

S&P Capital IQ

Febo Beheer bv

Foursquare

Gilt

GridGain

Eligotech bv

HSBC

Heluna

HolidayCheck

Klout

IBM

Intel

Juniper Networks

Marktplaats.nl

LinkedIn

LivingSocial Lucid Software

Metafor Software

Mind Candy

Micronautics Research

ITV

Meetup.com

Novell

OPower

NASA

Nature

New York Times

newBrandAnalytics

Plot

precog.com

Reaktor

Remember The Milk

Office Depot

Peerius.com

Quora

SAP AG

Secondmarket.com

Siemens AG

Reverb Technologies, Inc.

Rhinofly

Sears

Sony

Thatcham Motor

The Guardian

TicketFly

Twitter

StackMob

Stanford PPL

TomTom

UBS

Wattzon.com

Wordnik.com

Workday.com

Yahoo!

Walmart

Xebia

Xerox

Zeebox

 

Mais à part ça scala n'est pas très utilisé :mrgreen:

Lien vers le commentaire

Scala n'est pas grand public, ne s'adresse pas aux équipes de dev monstrueuses, et c'est le but :P

 

Twitter est un gros gros utilisateur, et EDF trading à un SI totalement refait en Scala, une petite beauté.

 

 

Lien vers le commentaire

 

Quelques boîtes utilisant notablement scala (front end / back office ou les deux) :
 
/snip
 
Mais à part ça scala n'est pas très utilisé :mrgreen:

 

Désolé, mais ta réponse est complètement à côté de la plaque: j'ai parlé d'applications en Scala, comme par exemple Grails qui repose sur Groovy. Et à part Lift, je n'en connais aucune. Et à mon avis c'est un symptôme qui ne trompe pas sur la vraie nature de Scala: c'est un joli joujou qui brille.

 

http://www.codinghorror.com/blog/2008/01/the-magpie-developer.html

 

Ceux qui sont assez vieux se rappelleront qu'on nous avait fait le même coup avec d'autres langages fonctionnels, et qu'ils ont tous finit oubliés (Haskell anyone ?). À la fin il n'y a jamais aucun truc concret qui en sort.

 

En ce moment il y a un genre de hype autour de Clojure, alors vous êtes ringards avec votre Scala :P

 

Et Clojure, c'est super original, c'est du LISP, un truc complètement nouveau.

 

Scala n'est pas grand public, ne s'adresse pas aux équipes de dev monstrueuses, et c'est le but :P

Voilà: il y a des centaines de boîtes de par le monde qui ont les moyens de payer des petites équipes de développeurs pour faire de l'expérimentation en Scala. Après il y a l'écrasante majorité des boîtes qui travaillent sur des projets normaux, et c'est pas en Scala.

 

Scala c'est un truc pour les 10% de développeurs pour qui la beauté du code compte avant tout, pas pour les mecs comme moi qui veulent juste pondre un truc qui marche et qui soit encore maintenable dans 2 ou 5 ans.

Lien vers le commentaire

Ceux qui sont assez vieux se rappelleront qu'on nous avait fait le même coup avec d'autres langages fonctionnels, et qu'ils ont tous finit oubliés (Haskell anyone ?). À la fin il n'y a jamais aucun truc concret qui en sort.

Comme la programmation orientée objet, en fait. :mrgreen:

En ce moment il y a un genre de hype autour de Clojure, alors vous êtes ringards avec votre Scala :P

 

Et Clojure, c'est super original, c'est du LISP, un truc complètement nouveau.

Clojure ? So 2010.

Scala c'est un truc pour les 10% de développeurs pour qui la beauté du code compte avant tout, pas pour les mecs comme moi qui veulent juste pondre un truc qui marche et qui soit encore maintenable dans 2 ou 5 ans.

Pour les mecs qui veulent du maintenable, il y a le Cobol. Ca existera encore dans vingt ans, et les gens qui en font ne se masturbent pas la tête avec des histoires d'héritage polymorphique, de fermetures de monades ou de patterns de callback. :P
Lien vers le commentaire

http://www.playframework.com/

 

C'est celui utilisé par linkedin et the guardian, par exemple. Interopérable java/scala mais il est clairement orienté scala depuis qqs temps.

Ah oui je connais, j'avais déjà regardé avant la 1.0, c'était encore du 100% Java à l'époque, et ma conclusion: parfaitement inutile dans 90% des cas. C'est complètement stateless, et ce n'est pas J2EE standard (pas de servlets...) ce qui le rend totalement inintéressant en entreprise. Finalement ça ne m'étonne pas qu'ils soient de plus en plus en Scala: ils doivent s'adapter à la demande de leurs utilisateurs :)

 

Au passage ils ont planté dans le décor leur base d'utilisateurs 1.0 en cassant la compatibilité lors de la 2.0: c'est sympa, on a toujours de la place dans l'emploi du temps pour se taper des migrations techniques.

Comme la programmation orientée objet, en fait. :mrgreen:

Mouais, c'est pas un langage mais un ensemble de concepts et techniques, et y'a pas grand chose de neuf depuis 20 ans ;)

En fait héritage, polymorphisme, types. tout ça est plutôt secondaire et lié à l'implémentation objet (le langage en fait). Les vrais concepts fondamentaux, c'est l'encapsulation, le découplage et le passage de message. Mais si tu demandes à un programmeur Java il te répondra sans doute les classes et l'héritage. Ce qui est ironique c'est que l'héritage contredit souvent le principe d'encapsulation, et pourtant c'est utilisé à fond dans tous les projets que je vois passer... (en fait le seul héritage qui vaille c'est celui d'interface, mais ça n'a pas encore pércolé dans la communauté)

Donc théoriquement, ça doit être possible de faire de l'OO dans n'importe quel langage (genre en JavaScript) sauf que sans mécanisme pour garantir l'encapsulation, c'est laissé à la discrétion des développeur (et en général on sait comment ça finit). Mais dans une petite équipe disciplinée, c'est possible (comme c'est possible d'utiliser Scala sans que ça parte en sucette).

Clojure ? So 2010.

Je sais pas, je vois de plus en plus de news Clojure par-ci par-là, mais je ne suis pas vraiment à fond les ballons sur les nouvelles hypes.

Il y a quoi de plus hype encore ?

Lien vers le commentaire

Mouais, c'est pas un langage mais un ensemble de concepts et techniques, et y'a pas grand chose de neuf depuis 20 ans ;)

En fait héritage, polymorphisme, types. tout ça est plutôt secondaire et lié à l'implémentation objet (le langage en fait). Les vrais concepts fondamentaux, c'est l'encapsulation, le découplage et le passage de message. Mais si tu demandes à un programmeur Java il te répondra sans doute les classes et l'héritage. Ce qui est ironique c'est que l'héritage contredit souvent le principe d'encapsulation, et pourtant c'est utilisé à fond dans tous les projets que je vois passer... (en fait le seul héritage qui vaille c'est celui d'interface, mais ça n'a pas encore pércolé dans la communauté)

Donc théoriquement, ça doit être possible de faire de l'OO dans n'importe quel langage (genre en JavaScript) sauf que sans mécanisme pour garantir l'encapsulation, c'est laissé à la discrétion des développeur (et en général on sait comment ça finit). Mais dans une petite équipe disciplinée, c'est possible (comme c'est possible d'utiliser Scala sans que ça parte en sucette).

Un grand ancien d'ici disait même qu'on pouvait faire de l'assembleur orienté objet, même si ce n'était pas fait pour ça. Et on a en effet trop tendance à croire que le concept central de la programmation orientée objet, c'est celui de d'héritage ou de classes instanciées, alors que c'est celui de passage de message.

Je sais pas, je vois de plus en plus de news Clojure par-ci par-là, mais je ne suis pas vraiment à fond les ballons sur les nouvelles hypes.

Il y a quoi de plus hype encore ?

Aucune idée. Tu parle quand même à un mec qui programme sous écran vert, là, hein. ;) Ceci étant, j'ai l'impression d'un petit renouveau du hype autour de Ruby (RoR a même été porté sur IBM i, c'est dire).
Lien vers le commentaire

Ah oui je connais, j'avais déjà regardé avant la 1.0, c'était encore du 100% Java à l'époque, et ma conclusion: parfaitement inutile dans 90% des cas. C'est complètement stateless, et ce n'est pas J2EE standard (pas de servlets...) ce qui le rend totalement inintéressant en entreprise pme. Finalement ça ne m'étonne pas qu'ils soient de plus en plus en Scala: ils doivent s'adapter à la demande de leurs utilisateurs :)

Corrigé

 

Au passage ils ont planté dans le décor leur base d'utilisateurs 1.0 en cassant la compatibilité lors de la 2.0: c'est sympa, on a toujours de la place dans l'emploi du temps pour se taper des migrations techniques.

 

C'est parce qu'il y avait une demande pour un FW full scala très performant que la 2.0 a dû casser la compatibilité, c'était pas juste une lubie des devs.

 

En fait héritage, polymorphisme, types. tout ça est plutôt secondaire et lié à l'implémentation objet (le langage en fait). Les vrais concepts fondamentaux, c'est l'encapsulation, le découplage et le passage de message. Mais si tu demandes à un programmeur Java il te répondra sans doute les classes et l'héritage. Ce qui est ironique c'est que l'héritage contredit souvent le principe d'encapsulation, et pourtant c'est utilisé à fond dans tous les projets que je vois passer... (en fait le seul héritage qui vaille c'est celui d'interface, mais ça n'a pas encore pércolé dans la communauté)

C'est clair qu'au niveau des implémentations OO il y a à boire et à manger. Mon avis perso sur le sujet est que c'est surtout la relative incompatibilité 'philosophique' avec SQL qui a foutu le bordel. Autant donner de la choucroute à un nigérian, en quelque sorte.

Lien vers le commentaire

Aucune idée. Tu parle quand même à un mec qui programme sous écran vert, là, hein.  ;) Ceci étant, j'ai l'impression d'un petit renouveau du hype autour de Ruby (RoR a même été porté sur IBM i, c'est dire).

Ah je sais, mais ça aurait pu être ton hobby :)

 

À mon avis Ruby à passé le stade du hype: c'est un retour en grâce mérité pour un langage que j'ai toujours considéré très élégant. D'ailleurs pour Discourse, ils ont choisit RoR: http://www.codinghorror.com/blog/2013/03/why-ruby.html

 

J'avais fait une tentative d'introduire Ruby au travail vers 2006 (pour du scripting), mais on m'avait expliqué que c'était bien beau mais personne ne voudrait y toucher :(  Et puis le côté faiblement typé et dynamique, c'est un no-go pour beaucoup de développeurs Java, c'est fou comme certains sont bornés... Je vais regarder un peu RoR 4, ça a du bien maturer avec le temps.

 

En ce moment je pousse pour utiliser Grails 2 dans un projet au travail: j'ai déjà utilisé Grails 1.2, et ça s'est bien amélioré depuis. C'est une des retombées positives de RoR: ça a forcé l'écosystème Java à réagir.

Lien vers le commentaire

Corrigé

En effet. Quoique dans mes clients du moment il y a du - big - gouvernemental, et même topo: si c'est pas compatible J2E, même pas la peine d'y penser. 

 

C'est clair qu'au niveau des implémentations OO il y a à boire et à manger. Mon avis perso sur le sujet est que c'est surtout la relative incompatibilité 'philosophique' avec SQL qui a foutu le bordel. Autant donner de la choucroute à un nigérian, en quelque sorte.

:)

En ce moment il y a un outil qui gagne en popularité: JOOQ http://www.jooq.org/

Pas encore testé en conditions réelles, mais j'aime beaucoup le concept. Ça réconcilie un peu Java et SQL.

Lien vers le commentaire

En effet. Quoique dans mes clients du moment il y a du - big - gouvernemental, et même topo: si c'est pas compatible J2E, même pas la peine d'y penser. 

 

C'est pas trop ça le problème. Twitter utilisait RoR au début, et ils sont passés à scala pour une raison bien précise. Hint : RoR est extrêmement vulnérable au DDoS pour la même raison.

Lien vers le commentaire

C'est pas trop ça le problème. Twitter utilisait RoR au début, et ils sont passés à scala pour une raison bien précise. Hint : RoR est extrêmement vulnérable au DDoS pour la même raison.

 

Hein ? Pour quelle même raison que quoi ?

 

Je sais que RoR est lent hein, mais des fois ça suffit pour le job.

 

Nan dans mon cas le soucis c'est que le site il ne vient pas tout seul, il s'insère dans un existant. Exemple concret: le client à un Active Directory avec 1.5K users dedans, et pour authentifier les utilisateurs du site intranet, on doit utiliser une librairie proprio qui fournit une servletFilter. Avec PLay! c'est déjà cuit. Aussi simple que ça.

Lien vers le commentaire

C'est clair qu'au niveau des implémentations OO il y a à boire et à manger. Mon avis perso sur le sujet est que c'est surtout la relative incompatibilité 'philosophique' avec SQL qui a foutu le bordel. Autant donner de la choucroute à un nigérian, en quelque sorte.

C'est très bon la choucroute le SQL, mangez-en !
Lien vers le commentaire

Mon alpha geek de pote me parle souvent du D : http://dlang.org/

 

Pour la petite histoire, cet ami s'est fait repérer par un recruteur de facebook sur http://stackoverflow.com/

Il est en Californie maintenant.

 

D'ailleurs pour Discourse, ils ont choisit RoR: http://www.codinghorror.com/blog/2013/03/why-ruby.html

 

D'ailleurs, quand est-ce qu'on y passe lib.org ?

Lien vers le commentaire

Mon alpha geek de pote me parle souvent du D : http://dlang.org/

Je peux me tromper, mais Dlang est là depuis super longtemps déjà et je n'ai pas encore vu de gens sérieusement l'adopter. Peut-être qu'il a sa propre niche, mais elle est loin loin sous mon radar.

C'est pas trop ça le problème. Twitter utilisait RoR au début, et ils sont passés à scala pour une raison bien précise. Hint : RoR est extrêmement vulnérable au DDoS pour la même raison.

Second hint, c'est le nom Scala.

Lien vers le commentaire

Je peux me tromper, mais Dlang est là depuis super longtemps déjà et je n'ai pas encore vu de gens sérieusement l'adopter. Peut-être qu'il a sa propre niche, mais elle est loin loin sous mon radar.

 

Tout ce que je sais, c'est que la 1ère édition de la Dconf a eu lieu l'année dernière, financée par kickstarter : http://dconf.org/2014/index.html

 

Ah oui et que les ténors du langage sont chez facebook.

Lien vers le commentaire

Ok, j'avais déjà entendu parlé du langage en 2007 je pense et le site officiel faisait vachement web 0.1 à l'époque.

Ensuite peut-être évidemment que s'il est bien supporté par Facebook ça pourra enfin donner quelque chose de sympa, à voir.

 

 

Lien vers le commentaire

Mon alpha geek de pote me parle souvent du D : http://dlang.org/

 

Pour la petite histoire, cet ami s'est fait repérer par un recruteur de facebook sur http://stackoverflow.com/

Il est en Californie maintenant.

D c'est du C, avec un ramasse-miettes, des features en plus... La question est : en quoi il est mieux que Java ? Java, ça tourne partout. Mal, mais partout.

D'ailleurs, quand est-ce qu'on y passe lib.org ?

Sous Discourse, ou directement sous RoR ?
Lien vers le commentaire

Ok, j'avais déjà entendu parlé du langage en 2007 je pense et le site officiel faisait vachement web 0.1 à l'époque.

Ensuite peut-être évidemment que s'il est bien supporté par Facebook ça pourra enfin donner quelque chose de sympa, à voir.

 

A priori, Facebook étudie le langage pour leur futur. Comme avec des dizaines d'autres technos j'imagine.

 

Sous Discourse, ou directement sous RoR ?

Discourse évidemment. (même si pas conseillé en prod pour l'instant)

Lien vers le commentaire

A priori, Facebook étudie le langage pour leur futur. Comme avec des dizaines d'autres technos j'imagine.

Ils utilisent en effet aussi Scala. Intéressant en tous cas de voir ce qu'ils vont faire avec D.

 

Le D, sur le papier, ça a l'air super, maintenant je suis curieux de voir concrètement combien de features leur compilateur supporte sans qu'on tombe sur des bugs bloquants. Sachant que le compilateur n'est pas open source et qu'il est l'œuvre d'une seule compagnie (Digital Mars).

 

 D je ne vois pas ça comme un concurrent de Java mais plutôt de C/C++/Go: c'est un langage système pour les gens qui ont besoin de s'interfacer avec du C/C++ et/ou d'embarquer de l'assembleur dans leur code.

Lien vers le commentaire

D je ne vois pas ça comme un concurrent de Java mais plutôt de C/C++/Go: c'est un langage système pour les gens qui ont besoin de s'interfacer avec du C/C++ et/ou d'embarquer de l'assembleur dans leur code.

Et encore, les gens de cloudius n'ont pas de problemes particuliers pour faire tourner la JVM, ou Ruby, ou LUA, dans le kernel.

En fait, maintenant que j'y pense, vu les perfs de LUAJit et de V8 avec les patchs ASM.js, on peut tout à fait écrire un OS en javascript ou en LUA avec un petit bout du kernel en C++, c'est pas juste théoriquement possible, c'est tout à fait envisagable dans l'année qui viens, ça m'étonnerai qu'ils ne fassent pas une version OSv de node.js comme ils l'ont fait de la JVM.

Et pour ce qui est de la jvm, utiliser le page tagging du MMU du processeur au lieu de le faire en couche 'haute' dans le Garbage collector devrait rendre l'allocation mémoire aussi rapide qu'avec un malloc custom, et ce avec un véribable garbage collector, et ça doit etre faisable assez facilement pour V8 ou LUAJit également.

L'arrivée des hyperviseurs crée une situation inédite coté serveur, au final, il faut un driver pour virtnet et un driver pour virtio, et du code qui tourne sur x86, c'est tout, ça simplifie vachement le développement systeme coté serveur de ne pas avoir à gerer des montagnes de hardware.

Je recommande à tout le monde de regarder OSv, il n'est pas encore prod ready, mais il n'en est pas franchement loin !

 

 

Lien vers le commentaire

Et encore, les gens de cloudius n'ont pas de problemes particuliers pour faire tourner la JVM, ou Ruby, ou LUA, dans le kernel.

En fait, maintenant que j'y pense, vu les perfs de LUAJit et de V8 avec les patchs ASM.js, on peut tout à fait écrire un OS en javascript ou en LUA avec un petit bout du kernel en C++, c'est pas juste théoriquement possible, c'est tout à fait envisagable dans l'année qui viens, ça m'étonnerai qu'ils ne fassent pas une version OSv de node.js comme ils l'ont fait de la JVM.

Et pour ce qui est de la jvm, utiliser le page tagging du MMU du processeur au lieu de le faire en couche 'haute' dans le Garbage collector devrait rendre l'allocation mémoire aussi rapide qu'avec un malloc custom, et ce avec un véribable garbage collector, et ça doit etre faisable assez facilement pour V8 ou LUAJit également.

L'arrivée des hyperviseurs crée une situation inédite coté serveur, au final, il faut un driver pour virtnet et un driver pour virtio, et du code qui tourne sur x86, c'est tout, ça simplifie vachement le développement systeme coté serveur de ne pas avoir à gerer des montagnes de hardware.

Je recommande à tout le monde de regarder OSv, il n'est pas encore prod ready, mais il n'en est pas franchement loin !

 

Ca doit être le post le plus incompréhensible de toute l'histoire de liberaux.org. Putain j'aurais mieux fait de me taire...

Lien vers le commentaire

D c'est du C, avec un ramasse-miettes, des features en plus... La question est : en quoi il est mieux que Java ? Java, ça tourne partout. Mal, mais partout.

Sous Discourse, ou directement sous RoR ?

D est sortit à l’époque où l’idée de sucre syntaxique du genre itérateurs/lambda/... dans Java était de la pure science fiction.

Aujourd’hui, ça n’a plus aucun intérêt.

Lien vers le commentaire

Ca doit être le post le plus incompréhensible de toute l'histoire de liberaux.org. Putain j'aurais mieux fait de me taire...

Oh non, tu ne lis pas tout le forum. Il y a eu des trucs encore plus incompréhensible, où même moi je perds pied complètement. Là, j'arrive à comprendre une ligne sur deux, et à deviner le sens des autres (bon, il a fallu que j'aille chercher la définition exacte d'un hyperviseur sur SuperUser quand même).
Lien vers le commentaire

D est sortit à l’époque où l’idée de sucre syntaxique du genre itérateurs/lambda/... dans Java était de la pure science fiction.

Aujourd’hui, ça n’a plus aucun intérêt.

 

Vrai. C'était aussi avant qu'on prouve avec LMAX Disruptor que Java (et maintenant .NET) peut gérer le multi-core avec du lock free. Mais en théorie D garde l'avantage pour la gestion du false sharing, vu qu'en Java il n'y a rien dans le langage pour gérer ça.

 

Et encore, les gens de cloudius n'ont pas de problemes particuliers pour faire tourner la JVM, ou Ruby, ou LUA, dans le kernel.

En fait, maintenant que j'y pense, vu les perfs de LUAJit et de V8 avec les patchs ASM.js, on peut tout à fait écrire un OS en javascript ou en LUA avec un petit bout du kernel en C++, c'est pas juste théoriquement possible, c'est tout à fait envisagable dans l'année qui viens, ça m'étonnerai qu'ils ne fassent pas une version OSv de node.js comme ils l'ont fait de la JVM.

Et pour ce qui est de la jvm, utiliser le page tagging du MMU du processeur au lieu de le faire en couche 'haute' dans le Garbage collector devrait rendre l'allocation mémoire aussi rapide qu'avec un malloc custom, et ce avec un véribable garbage collector, et ça doit etre faisable assez facilement pour V8 ou LUAJit également.

L'arrivée des hyperviseurs crée une situation inédite coté serveur, au final, il faut un driver pour virtnet et un driver pour virtio, et du code qui tourne sur x86, c'est tout, ça simplifie vachement le développement systeme coté serveur de ne pas avoir à gerer des montagnes de hardware.

Je recommande à tout le monde de regarder OSv, il n'est pas encore prod ready, mais il n'en est pas franchement loin !

 

Intéressant, je ne connaissais pas. Ça tombe bien j'ai installé une vbox Fedora 20 pour tester la distro, je vais installer les packages.

 

Mais bon, c'est aussi possible d'écrire un OS en Java. ça avait été fait il y a 10 ans, et apparemment le projet reprend: http://www.jnode.org/

Il y avait juste un petit bout d'assembleur pour booter :)

Lien vers le commentaire
The goal is to create an easy to use and install Java operating system for personal use. Any java application should run on it, fast & secure!

 

j'espère qu'ils n'imagine as que cela remplacerais windows/linux...

 

par contre, un OS en ligne de commande qui prendrais peu de puissance afin de faire tourner une seule application java sur un serveur pourrait être utile.

Lien vers le commentaire

j'espère qu'ils n'imagine as que cela remplacerais windows/linux...

Au début c'était le but, aujourd'hui je ne sais pas ce qu'il(s) veu(len)t en faire.

 

par contre, un OS en ligne de commande qui prendrais peu de puissance afin de faire tourner une seule application java sur un serveur pourrait être utile.

Ça existe déjà et ça s'appelle Linux ou BSD :)
Lien vers le commentaire

En fait héritage, polymorphisme, types. tout ça est plutôt secondaire et lié à l'implémentation objet (le langage en fait). Les vrais concepts fondamentaux, c'est l'encapsulation, le découplage et le passage de message. Mais si tu demandes à un programmeur Java il te répondra sans doute les classes et l'héritage. Ce qui est ironique c'est que l'héritage contredit souvent le principe d'encapsulation, et pourtant c'est utilisé à fond dans tous les projets que je vois passer... (en fait le seul héritage qui vaille c'est celui d'interface, mais ça n'a pas encore pércolé dans la communauté)

C'est exactement ça.

L'héritage est presque un mauvais concept à éviter.

Le mécanisme des interfaces/implémentations est en revanche au cœur de la POO, il facilite "l'encapsulation, le découplage et le passage de message".

Lien vers le commentaire

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...