Le topic de la programmation: Et envoyez des sioux!

[Teocali]

Scala, le vrai gros problème quand j'avais touché du truc (et c'est également le discours de deux potes dev Scala avec qui j'ai discuté), c'était la toolchain complement aux fraises. C'est entre la raison du switch vers Kotlin pour les potes en question. Ca et le fait que le language évolue extrêmement vite (ce qui n'est pas le cas de Scala), et dans le bon sens.

[Shinosha]

Tu as eu quoi comme problèmes ? Je sais pas de quand date ces constats mais à part si toi et tes potes vous avez bossé avec des versions < 2.11 (aka les versions maintenant inexistantes), c'est juste pas possible. IntelliJ a un plugin Scala qui est très bon, et sauf si tu joues avec des trucs très très avancés de Scala 2 (en entreprise ça devrait pas), tu n'aurais dû avoir aucun problème. On attend encore une meilleure prise en charge de Scala 3 mais ça devrait arriver. L'écosystème a pas encore entièrement migré de toutes façons. Tu peux même bosser sur VSCode via Metals si tu veux un truc plus léger.

De plus si vous avez peur de SBT il y a maintenant des alternatives production ready, comme Mill.

Ben c'est un peu le cœur du sujet.
Les qualités intrinsèques d'un langage c'est bien, mais l'environnement tout autour (framework, IDE, plateforme de dev, etc) est encore plus important.

Voir au dessus

Ben ça dépend ce que tu fais.
Quand tu bosses sur de l'UI, avoir une compilation quasi instantanée est vraiment appréciable.

Qui choisi un langage JVM pour du front ? Ou plutôt qui fait encore du server side rendering de nos jours ? Cela étant c'est possible de faire ça avec un feeback décent, car Play Framework y arrive par exemple. Sûrement avec du hotswap JVM ou je ne sais quoi.

[Orhin]

Qui choisi un langage JVM pour du front ? Ou plutôt qui fait encore du server side rendering de nos jours ? Cela étant c'est possible de faire ça avec un feeback décent, car Play Framework y arrive par exemple. Sûrement avec du hotswap JVM ou je ne sais quoi.

Je ne pensais pas au web mais plutôt aux applis desktop et android.

[Foksadure]

Tu aurais un seul langage pour le backend et le frontend. Ca serait tellement mieux que cette horreur de NodeJS.

Oui, vive l'ASP 3.0.

[Teocali]

Tu as eu quoi comme problèmes ?

Plus les details en tête, j'avoue. Je veux bien croire que ça ait évolué dans le bon sens, vu que j'y avait touché avant la sortie de Kotlin de beta.

Qui choisi un langage JVM pour du front ? Ou plutôt qui fait encore du server side rendering de nos jours ? Cela étant c'est possible de faire ça avec un feeback décent, car Play Framework y arrive par exemple. Sûrement avec du hotswap JVM ou je ne sais quoi.

Concernant le SSR, tu serais surpris, c'est en phase de retour en grace, notamment avec des solutions comme HTMX. Je sais que de notre coté, vu les contraintes humaines et financière que l'on a, c'est une des solution qu'on explore pour la prochaine refonte de notre front end.

[gros_bidule]

Langage JVM pour du front -> je pense qu'il faut le voir comme un remplaçant de Typescript
KT qui transpile en JS ou TS qui transpile en JS, quelle différence ? Si tu préfères Kotlin, elle a son importance. Il manque juste un bon framework équivalent à Angular/React/Vue, et là, tu auras des devs Kotin qui vont se remettre à faire du frontend.

[Orhin]

Langage JVM pour du front -> je pense qu'il faut le voir comme un remplaçant de Typescript
KT qui transpile en JS ou TS qui transpile en JS, quelle différence ? Si tu préfères Kotlin, elle a son importance. Il manque juste un bon framework équivalent à Angular/React/Vue, et là, tu auras des devs Kotin qui vont se remettre à faire du frontend.

Y'a quand même une différence dans l'intégration des librairies JS.

Aujourd'hui t'as quasi rien à faire pour utiliser une lib JS en Typescript.
Dans le pire des cas y'a pas de typage mais ça va marcher "de base" car TS reste juste un superset de JS.

Je demande à voir une intégration aussi simple en Kotlin.

[gros_bidule]

Kotlin permet déjà de transpiler en JS, donc de là à monter un framework dessus... y'a peut être un manque de volonté de certains acteurs ? Ou bien c'est en dev ou encore un poil trop tôt ? Aucune idée, mais y'a rien de bloquant.
Intégrer des libs JS tierces c'est une autre histoire, mais l'idée serait de s'en passer ou de passer par des wrappers pour les plus populaires d'entre elles.

- - - Updated - - -

Puis mince, ça serait dommage de faire du Kotlin pour devoir se taper la compatibilité avec des libs JS toutes pourries
De toutes façons l'avenir *tousse-tousse* c'est les webassemblies.

[Orhin]

Kotlin permet déjà de transpiler en JS, donc de là à monter un framework dessus... y'a peut être un manque de volonté de certains acteurs ? Ou bien c'est en dev ou encore un poil trop tôt ? Aucune idée, mais y'a rien de bloquant.

Ben c'est pas vraiment simple de créer un framework de l'envergure de React ou d'Angular.
Y'a énormément de boulot derrière.

Et d'ailleurs, ceux-ci utilisent pas mal de fonctionnalités avancées et "bas niveau" de JS pour fonctionner.
Pas sur que ce soit facile à faire avec une phase de transpilation.

Dans un premier temps, y'a surement moyen de faire plus simple en rendant compatible React avec Kotlin.

Intégrer des libs JS tierces c'est une autre histoire, mais l'idée serait de s'en passer ou de passer par des wrappers pour les plus populaires d'entre elles.

Ben du coup tu retombes dans le cas du Scala : un beau langage mais un environnement vide.

Et les wrappers, c'est rarement au top.
Je le vois bien dans l'autre sens (code natif Android/iOS => JS) dans le monde Ionic/Cordova.
Si t'as pas une boite qui finance le dev, à part quelques gros projets, ce n'est plus maintenu (ou pas suffisamment) au bout de quelques années.

[TwinBis]

Le Kotlin compilé en JS je vois ça surtout comme un moyen de partager une partie de la logique métier entre le front et le back (à des fins de validation des inputs utilisateur sans avoir à contacter le back par exemple).

Du front "UI" en Kotlin JS je n'y crois pas une seconde, l'écosystème ne suivra pas.

[Shinosha]

Ben du coup tu retombes dans le cas du Scala : un beau langage mais un environnement vide.

Mais mais... C'est pas bientôt fini Ça veut dire quoi avoir un environnement vide ? Pas avoir un support natif pour des libs JS ? À ce moment là beaucoup de langage ont un environnement vide. J'ai pas compris ton exemple. Ionic c'est pas dans l'autre sens ? React -> Natif mobile ?

[Orhin]

Mais mais... C'est pas bientôt fini Ça veut dire quoi avoir un environnement vide ? Pas avoir un support natif pour des libs JS ? À ce moment là beaucoup de langage ont un environnement vide.

Non mais c'était une petite pique.

Par "environnement vide", j'entend un faible nombre de librairies/framework disponible dans un cas d'utilisation donné.
Le support natif des libs JS, on s'en fout dans la majorité des cas sauf si tu veux utiliser ton langage pour faire du front web.

Que tu prennes le JS ou le PHP, y'a un très gros environnement avec plein d'outils/libs/framework matures et faisant le taf.
Que Kotlin puisse se transpiler en JS c'est bien, mais si faut tout réinventer à côté, ça nous fait une belle jambe.

Imagine si, au démarrage de Kotlin, il avait été impossible d'utiliser facilement les libs Java et qu'aucun gros framework ne l'avait supporté directement.
Personne n'aurait utilisé le langage.

J'ai pas compris ton exemple. Ionic c'est pas dans l'autre sens ? React -> Natif mobile ?

Oui c'est dans l'autre sens, appel de code natif par le JS.
Ça se présente sous forme de plugins qui contiennent le code natif + un wrapper JS.

[Teocali]

Non mais c'était une petite pique.

Par "environnement vide", j'entend un faible nombre de librairies/framework disponible dans un cas d'utilisation donné.

Alors, ça, c'est faux. Scala compilant pour la JVM, t'as acès a la librairie standard Java. Si tu considères seulement les librairies codées en Scala, ben, t'as le même souci en Kotlin.

[Orhin]

Alors, ça, c'est faux. Scala compilant pour la JVM, t'as acès a la librairie standard Java. Si tu considères seulement les librairies codées en Scala, ben, t'as le même souci en Kotlin.

Non mais je sais (cf le reste de mon post), c'était un petit troll (réussi).

Surtout que la situation est similaire pour Typescript / Javascript.

[Shinosha]

Non mais c'était une petite pique.
Par "environnement vide", j'entend un faible nombre de librairies/framework disponible dans un cas d'utilisation donné.
Le support natif des libs JS, on s'en fout dans la majorité des cas sauf si tu veux utiliser ton langage pour faire du front web.

Que tu prennes le JS ou le PHP, y'a un très gros environnement avec plein d'outils/libs/framework matures et faisant le taf.
Que Kotlin puisse se transpiler en JS c'est bien, mais si faut tout réinventer à côté, ça nous fait une belle jambe.

La police de l'internet viendra vous voir pour manquement à l'utilisation d'un emoji. En tout cas oui en Scala on a tout ce qu'il faut, et à part pour des besoins spécifiques genre crypto, on a tout en natif. Y compris un transpiler Scala to JS et les façades aux libs JS connus (dont les framework même si perso j'ai jamais utilisé). Ces façades ne réinventent pas tout comme leur nom l'indique, elles sont similaires aux définitions TS. Pas mal de libs Scala sont aussi cross compiled pour Scala.js. Je sais pas comment c'est en Kotlin par contre, j'imagine que c'est similaire.

Sinon vous avez entendu parler de Unison ? Je sais je sais c'est un dialecte de Haskell, ça fait un peu peur niveau syntaxe, mais si je vous dis :
- Plus besoin de build votre programme si quelqu'un l'a déjà fait avant, hormis les parties que vous avez changé
- Quand on lance les tests ça lance seulement ceux dont le code a changé
- Plus de conflit de dépendance
- Programmation distribuée native
- Refactoring puissant et assisté
- Gestion des dépendance plus fine (je veux juste cette fonction de la lib)

Alors ? Stylé ou pas ? En gros c'est Git ou Nix mais appliqué à un langage. Chaque fonction est lié à un hash de l'AST du code de la dite fonction. Ça constitue littéralement une base de code durable, immuable, partageable et explorable facilement. Bon ok ça cible pas la JVM et c'est pas prod ready, mais c'est très intéressant. Avec Graal et Truffle cela dit la JVM est peut-être pas hors de portée un jour.

[vectra]

J'ai pas encore eu trop de réussite sur le topic des expats, alors je viens vous emmerder un peu

75K GBP à Londres, c'est correct ou pas pour un poste de dev C++ scientifique?

[deathdigger]

La question c'est : est-ce que t'as envie de vivre à Londres ?
Si oui, pourquoi pas, si non, tu peux trouver un salaire correct en France en te bougeant le fion.

[gros_bidule]

Ou bien bosser en télétravail ?
C'est facile de dire de se bouger le f***, mais c'est peut être plus compliqué dans certaines spécialités de l'informatique

[Awake]

J'ai trouvé une solution non-mathématique à mon soucis, je supprime du coup.

[FB74]

[acdctabs]

C'est impressionnant le niveau qu'il faut pour être capable de faire ça.

[gros_bidule]

On a aussi aujourd'hui des outils qui n'existaient pas à l'époque (matos, et logiciels de dev qui ont énormément évolué, de bons profilers...). Et plus de temps, le mec n'avait probablement pas une deadline serrée pour faire ce qu'il a fait.
Ca ne diminue en rien le mérite, ça reste super chouette. Mais ce n'est pas si étonnant non plus. Y'a 20 ans, c'était encore la préhistoire côté dev, et pourtant ça a déjà permis de créer des pépites. Je pense que ces devs méritent un respect infini.

[deathdigger]

Bon, vraiment, VS2022 m'épate.
Alors il est un poil gourmand et je ne me suis pas encore habitué à l'espèce de lissage des polices, mais alors, sur l'autocomplétion...
Si tu tapes :

string inputKeys = "";
foreach (KeyValuePair<string, string> kvp2 in kvp)
     {
          inputKeys += kvp2.Value + ";";
     }

Dans la foulée, il va te proposer de taper

inputKeys = inputKeys.TrimEnd(';');

[Orhin]

C'est propre en effet.

Ce qui l'est moins, c'est de ne pas avoir utilisé un "String.Join".

[deathdigger]

C'est propre en effet.

Ce qui l'est moins, c'est de ne pas avoir utilisé un "String.Join".

Il aurait fallu que je sache que ça existe

[FB74]

Tu mets pas un string en été ?

[deathdigger]

Tu mets pas un string en été ?

non, je mets un String?

[Ladioss]

Qui choisi un langage JVM pour du front ? Ou plutôt qui fait encore du server side rendering de nos jours ? Cela étant c'est possible de faire ça avec un feeback décent, car Play Framework y arrive par exemple. Sûrement avec du hotswap JVM ou je ne sais quoi.

Concernant le SSR, tu serais surpris, c'est en phase de retour en grace, notamment avec des solutions comme HTMX. Je sais que de notre coté, vu les contraintes humaines et financière que l'on a, c'est une des solution qu'on explore pour la prochaine refonte de notre front end.

Tombé sur ça il y a quelque temps, j'ai beaucoup rit :
https://www.thoughtworks.com/radar/t...ipid=202203029
J'aime bien ce côté de la tech d'être à la fois un éternel recommencement, mais d'une façon inédite à chaque coup.

Langage JVM pour du front -> je pense qu'il faut le voir comme un remplaçant de Typescript
KT qui transpile en JS ou TS qui transpile en JS, quelle différence ? Si tu préfères Kotlin, elle a son importance. Il manque juste un bon framework équivalent à Angular/React/Vue, et là, tu auras des devs Kotin qui vont se remettre à faire du frontend.

L'histoire et GWT, nodejs, etc nous enseigne que si un jour le marché a un trop-plein de devs Kotlin, et pas assez de devs web, alors inévitablement quelqu'un viendra très vite nous pondre un tel framework. En attendant je vois pas trop la demande pour ça (à un niveau business s'entends - en tant que petit projet tech pour des esprits joueurs et curieux, je suis sûr que quelqu'un bosse déjà sur ça dans son coin).

(après passer direct à la case webassembly... ça oui ça aurait du sens, pourquoi pas)

[Teocali]

Tombé sur ça il y a quelque temps, j'ai beaucoup rit :
https://www.thoughtworks.com/radar/t...ipid=202203029
J'aime bien ce côté de la tech d'être à la fois un éternel recommencement, mais d'une façon inédite à chaque coup.

Eh, j'avais pas pensé a ça comme solution pour le mobile, mais c'est vrai que ça a un certain sens, si ton objectif c'est de passer la merde sous le radar des apps store :D

[Robix66]

C'est propre en effet.

Ce qui l'est moins, c'est de ne pas avoir utilisé un "String.Join StringBuilder".

Fixed.