Préambule :
Ce journal a pour objet de partager ma petite expérience de développeur amateur ; et comme tout amateur qui se respecte, je ne maîtrise pas grand‑chose, aussi pardonnez moi d’avance l’utilisation de termes inappropriés ou autres…
Pour occuper mon temps libre, je m’amuse à développer des applications web principalement.
Ces sites sont hébergés soit chez un professionnel en tant qu’hébergement mutualisé soit dockerisés localement sur un serveur monté de toutes pièces (un vieil Athlon Phenom Ⅱ X4 Black edition, pour les nostalgiques).
J’ai choisi comme langage principal pour la partie back‑office le PHP (offre « offerte » fréquemment chez les hébergeurs). J’ai bien tenté le Python, mais je ne suis pas trop fan, sans doute par méconnaissance.
Pour la partie utilisateur, cela dépend de la cible (navigateur/application dédiée, mobile ou desktop), aussi cela va du HTML/JavaScript (hérésie d’associer les deux !) ou le Java. Je pense dans un avenir proche à varier mes plaisirs et tenter le Dart/Kotlin (est‑ce mal car créé par Google ?).
Toujours est‑il que j’ai à disposition comme environnement de développement, deux ordinateurs portables : une bête américaine suffisamment puissante pour faire tourner la suite Android studio et sa machine virtuelle, le tout linuxé avec une Ubuntu des plus classiques (ce choix pourrait faire l’objet d’un journal à lui tout seul) et un modeste Chinois propulsé par Windows 10 (je sais, c’est mal, mais moi j’aime bien et je n’ai pas encore trouvé un gestionnaire de fenêtres libre qui me convienne ; des idées ?) avec clavier QWERTY qui a le mérite de ne pas peser plus lourd qu’un MacBook Air pour un prix beaucoup plus léger et que j’utilise dans le RER (ah non ! on ne dit plus RER mais train !). Sur chacune de ces machines, j’ai installé NetBeans et VSCode et PHP, bien entendu. Jusque‑là, tout va bien.
Même si je ne fais pas partie d’une Force Development Task Team, j’ai quand même besoin de partager mon code entre mes machines, les clés USB c’est quand même pas la panacée, et je n’ai pas accès à mon réseau hors de mon domicile (je réinstallerai un VPN dans mon deuxième temps libre !), aussi je choisis l’option ultime utilisée par tous les professionnels de la profession à savoir Git (je vais m’attirer les foudres de ceux qui ne jurent que par Mercurial ou autres services décentralisés de gestion de versions mais, pour moi, Mercuriales ce sont deux tours jumelles à Bagnolet).
Sitôt dit, sitôt fait : sudo apt install git sur une machine et « cliquer icône Firefox, aller à qwant.com (pourquoi pas .fr ?), chercher git, cliquer lien git-scm.com, cliquer « Download 2.25.0 for Windows », enregistrer le fichier, ouvrir le fichier fraîchement téléchargé, autoriser l’application à modifier le système, accepter la licence GNU (ça, c’est bien !), installer.
Évidemment, cela ne suffit pas (ou peut‑être que si, mais je ne sais pas), je dois centraliser mes versions décentralisées sur GitHub, GitLab ou autres services à disposition (mais comme je code comme un goujat (aucun respect des normes PSR ni test‑unit sans parler de la documentation), je m’abstiens de polluer la sphère libre et j’opte pour un Gogs en Docker sur mon serveur. Et voilà le travail !
Ah, ben non, impossible de « pusher » quoi que ce soit depuis Netbeans (une « trop » rapide recherche me conduit à penser que je ne suis pas le seul et que ce dysfonctionnement serait connu des personnes compétentes), je ne pousse pas plus loin, surtout qu’avec VSCode ça marche.
Voilà tout est opérationnel, il existe moult possibilités sans doute plus optimales pour parvenir à ce résultat et que je serai ravi de tester à l’occasion.
Ce sera tout pour aujourd’hui, merci de m’avoir lu, vous pouvez retourner à vos occupations.
# Unixporn
Posté par Lutin . Évalué à 5.
Tu as essayé les gestionnaires de fenêtres pavant, comme i3, bspwm, herbsluft… C'est pas pour tous le monde, ni pour tous les usages, mais pour du développement c'est vraiment pratique.
Je ne connais pas d’équivalent à windows 10 (en même temps pour en avoir un au boulot, c'est extrêmement pénible à utiliser), mais si tu aimes windows XP et 7, XFCE, KDE et les clones du vieux gnome s'utilisent de la même manière (et tu peux même les maquiller en windows si tu trouves ça joli).
Gnome (le récent, pas le vieux) est un peu à part.
[^] # Re: Unixporn
Posté par mistiru . Évalué à 2. Dernière modification le 22 janvier 2020 à 00:58.
Je me permets aussi de rajouter Cinnamon dans la liste, qui ressemble pas mal à ce que propose Windows.
Certes, à proprement parler il s'agit d'un environnement de bureau et non pas d'un simple gestionnaire de fenêtres, mais vu que KDE et XFCE ont été cités, je me permets ^^.
Sinon, parmi les gestionnaires de fenêtre proposant un mode "tiling", pour moi c'est awesomeWM qui l'a emporté, mais comme dit juste au dessus : « C'est pas pour tout le monde ».
[^] # Re: Unixporn
Posté par franteck . Évalué à 2.
Merci pour vos suggestions.
Je me rend compte que ma phrase "je n’ai pas encore trouvé un gestionnaire de fenêtres libre qui me convienne" est tout à fait imprécise, en fait il manque "adapté aux écrans tactiles"…
J'ai essayé pas mal de gestionnaires y compris en mode tilling, autant sur mon écran 17" c'est très intéressant autant sur le 11" ça le fait beaucoup moins. Donc pour l'instant je jongle entre différents environnements en fonction de mes activités.
# Gitea plutôt que Gogs
Posté par 16aR . Évalué à 4.
Puis-je te conseiller d’utiliser gitea plutôt que Gogs.
Gitea est un fork communautaire de Gogs. En quelque sorte approuvé par le créateur de Gogs car il veut garder le contrôle de son bébé et s’en sert d’expérimentation pour son framework web (macaron). Du coup, il est frileux sur les pull requests et est plus motivé par des nouvelles fonctionnalités.
De l’autre côté, Gitea est géré par d’anciens contributeurs de Gogs qui ont été frustrés par le manque d’ouverture de Gogs. Depuis, ils ont apporté beaucoup (ce qui m’intéressait beaucoup était la code review de la 1.6 ) et ont corrigé d’innombrables bug.
Je viens de trouver ça : https://docs.gitea.io/en-us/comparison/
[^] # Re: Gitea plutôt que Gogs
Posté par franteck . Évalué à 1.
Pourquoi ai-je choisi Gogs ? Tout simplement parce que je me rappelle une présentation du produit ici-même dans un journal et qui m'avait paru à l'époque plus simple à installer en local que ses concurrents. Du coup je n'ai pas cherché plus loin surtout que mon besoin simple (des pull et des push avec moi-même) fonctionne parfaitement.
Mais comme je suis d'une nature curieuse je vais regarder Gitea de près ;)
# Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . Évalué à 2.
Kotlin n’est pas créé par Google, mais par JetBrains, les gens derrière Intellij IDEA, PHP Storm, Goland, etc.
Dart a bien été créé par Google, mais n’a pas rempli son rôle (remplacer le JS pour une version plus sécurisée). Depuis, il a été réutilisé par le projet Flutter qui a permis de le relancer.
J’ai eu quelques déboires avec Flutter et Dart, notamment des mises à jour automatique non demandée qui m’ont cassé mon appli simplissime développée 2 mois plus tôt. J’imagine pas sur un gros projet avec beaucoup de dépendances.
Quitte à prendre un nouveau langage, regarde du côté de Go. Les ressources en français manquent (je vais tâcher d’y remédier cette année), mais c’est un langage simpliste, mais puissant, et qui d’après moi a plus de portée que ce qu’on l’utilise actuellement (cloud, devops, etc). Le fait d’avoir empêcher l’héritage et préfère la composition est un vrai plus. Vu que de toute manière, tous les designs pattern du Gang of Four sont toujours là pour casser des liens d’héritage et remplacer par de la composition…
Du coup, étant déçu par l’expérience Flutter, je suis en train de me tourner vers Gio (pour le moment, encore très expérimental) et en plus complet, je vais tester aussi fyne.
Pour ce qui est du web, ce qui existe pour Go est déjà assez complet (buffalo, gorilla/mux, etc) et j’ai déjà mon backend, maintenant, je dois construire mon frontend (GopherJS, vugu, wasm, etc).
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par El Titi . Évalué à 2.
Beurk, ce langage est une hérésie et les quelques bonnes idées qu'il pouvait apporter sont maintentant reprises et il se trouve dépassé par les autres langages et notamment Rust.
Et ça ne trompe pas les devs:
https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-languages
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par barmic 🦦 . Évalué à 3.
Une hérésie ? Rien que ça ? Et on démontre les hérésies avec des sondages.
Rust et go n'ont rien à voir. Ils ne s'adressent pas aux même usages et proposent des solutions différentes.
Après dans les hérésies classiques on a lisp et javascript. Ça ne trompe pas ces langages sont mort-né.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par El Titi . Évalué à 2. Dernière modification le 22 janvier 2020 à 15:24.
Commençons gentiment, on n'est pas vendredi:
Capturer et propager les erreurs explicitement en 2020, c'est comment dire …
Ah oui, l'auteur du Go est un peu nostalgique du C.
Pas d'exception ?
Ok voyons comment Rust et la programmation fonctionnelle aborde la problématique:
http://tyoverby.com/posts/rust-vs-go.html
D'accord, on attend encore la généricité. Un minimum quand même pour des langages typés qui veulent encourager de la réutilsation en dehors du dev de microservices et de chtits utilitaires. Autant faire du python à ce niveau. Ca va quand même plus vite pour du quick and dirty même en asynchrone ou multi-process.
Ca en est où au fait ?
https://www.infoq.com/news/2019/08/go-contracts-generic-programming/
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par Anonyme . Évalué à 4.
Ken Thompson (un des créateur de Go), est surtout l’inventeur du C.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par El Titi . Évalué à 2.
D'où ma référence
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par jyes . Évalué à 3.
C’est amusant de lire ce commentaire juste après avoir lu un chouette texte sur la “contempt-culture”, glané au hasard de la toile en partant de la page « liens » de LinuxFr.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par kalimba . Évalué à 1.
J'ai bien remarqué cette contempt-culture mais pour moi ça a toujours été une blague, ou plutôt un troll comme on appelais ça dans le temps. J'utilise vim donc emacs c'est de la merde, et en face ils disent le contraire. Tout le monde est conscient que c'est stupide et donc 2e degré car ça reviens a la fin a une préférence personnelle, un peu comme quand on dit "c'est pas bon" au lieu de "j'aime pas". Tout le monde ? Peut-être pas, au vu de l'auteur de ce texte qui semble l'avoir pris au sérieux
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par barmic 🦦 . Évalué à 2.
Ça n'est clairement pas du second degré. Oui le troll ça existe mais là un gars comme El titi est persuadé savoir de manière objective et absolu ce qui est bien en méprisant les autres points de vue. Tu remarque que le mépris arrive dès le début et ne donne clairement pas envi de s'engager dans une véritable discussion car elle sera parasitée par cette prétention et ce mépris. J'y ai déjà eu affaire plus d'une fois sur divers sujets (impossible de parler objectivement de js sans qu'un gars vienne t'expliquer que le js c'est tout pourri, impossible de parler de mode sombre sans qu'une fille vienne t'expliquer que le mode sombre c'est tout pourri,…).
Quelque part cette culture du mépris me semble faire parti d'un tout qui est l'absence de bienveillance généralisée (et oui on pourra me dire que je fais parti du problème).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par El Titi . Évalué à 1.
J'imagine que par mépris tu faisais allusion à ce genre de phrases tirées du chapeau ?
Ah bin non en fait. Toi et moi faisons bien partiE du problème. Comment se nomme t'il déjà ?
Ah oui le prosélytisme.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . Évalué à 1.
Ou tu vois du mépris dans ces phrases ? Elles me semblent juste factuelles dans les deux cas ?
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . Évalué à 1.
Au lieu de tirer sur un sujet, tu pouvais ouvrir un autre sous-fil et proposer une alternative sans chercher de conflit ?
Après, je connais et apprécie LinuxFR, donc j’en prends pas ombrage personnellement ni pour le langage que j’apprécie, mais en effet, ça ne donne pas envie d’échanger, mais juste a se retrancher sur ses positions et se battre à coup de : "moi mon langage il a un garbage collector", "moi mon langage il gère le cycle de vie de mes allocations". Ça ne me semble pas très productif.
On peut échanger sur les faits, et présenter ses émotions et expériences sur le sujet sans à avoir à taper sur un autre et dire qu’il est nul et que son langage c’est de la m****.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . Évalué à 1.
Et après, on s’étonne des gens qui font des burn-out.
https://words.steveklabnik.com/a-sad-day-for-rust
Alors OK, Rust c’est safe, et que cet auteur jetait toute cette safety par la fenêtre, mais pas besoin de faire du harcèlement.
Mais bon, de toute manière, osef : https://twitter.com/golang/status/1154402973914505221
Y’a que les haters pour être énervés.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . Évalué à 1.
Ça montre quoi ces stats ? Que Go est #3 en langage le plus voulu alors que Rust n’est que #5 ?
Évidemment, je trolle et ces stats peuvent montrer n’importe quoi. Comme dit barmic, Rust et Go ne sont pas dans la même cour.
Personnellement, je vois que l’auteur est débutant et découvre de manière autodidacte la programmation. Je pense que Go est bien plus approchable pour un débutant que Rust.
Après, il peut être débutant et veut creuser des sujets ayant besoin de beaucoup de sécurité et performance en terme de programmation et pour cela, Rust est plus intéressant (plus que le C et le C++, même). Mais je n’ai pas l’impression que c’était son approche.
Après, tu payes cela en rapidité de développement (et apprentissage). Gérer de la mémoire, c’est toujours plus difficile quand tu n’as pas de garbage collector.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par franteck . Évalué à 0. Dernière modification le 22 janvier 2020 à 17:08.
Je pensais effectivement associer Flutter à Dart pour faire des applis Android surtout que la doc est riche en tuto, ça à l'air tout simple à mettre en œuvre. Ou bien Kotlin parce que je trouve le Java un poil verbeux.
N'étant pas une pointure en développement mobile, j'espérais me faciliter la tâche. Je suis un peu refroidi.
J'ai bien essayé en C++ et en python pour un résultat que je qualifierai de très moyen, alors pourquoi pas Go.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par El Titi . Évalué à 5.
Le Mr plus haut ne nous a pas dit ce qu'il reprochait à Kotlin à part le fait que Big Brother n'en soit pas le géniteur.
On voit facilement ce que Go n'apporte pas au 22 Janvier 2020: Pas de traitement d'erreur digne de ce nom, un support du fonctionnel basique, même même pas de gestion de modules avec un dépôt officiel et même pas de généricité. Mis à part les goroutines, réimplémnentation un peu plus intégrée d'un concept de l'aube de l'informatique, avec une meilleure gestion des appels natifs, y'a pas grand chose sous le capot.
Si on veut vraiment des perfs (puisque c'est leur argument) autant oublier le ramasse miette et se lancer dans le Rust qui est à peine plus compliqué et énormément plus productif une fois qu'on a pigé les concepts notamment pour son approche fonctionnelle et son support des génériques.
Si on veut de la simplicité, restons en à Python qui gère l'asynchrone et le mutliprocessing suffisamment bien avec multiprocess en standard, gevent ou async/await pour les coroutines.
Ah oui il faut faire un "pip install", c'est pas neuneu friendly.
Quant à ce qu'il apporte tout y est coté Kotlin. Mais avec lui au moins tu t'ouvres un vaste champ d'applications avec un écosytème immense qui vient avec la JVM, le dev Android natif, les frameworks Web du monde Java et ceux de Kotlin lui-même, la cross compilation vers du JS, les librairies graphiques Java et bientôt le natif via LLVM (même si on peut faire du portable pour pas cher avec la JVM aujourd'hui)
Tu as un support plutôt pas mal des 2 paradigmes de programmation mainstream OOP et FP.
Pour l'objet tu n'est pas limité, la généricité, l'héritage d'implémentation, la composition, les interfaces les traits, tout y est: https://blog.kotlin-academy.com/inheritance-composition-delegation-and-traits-b11c64f11b27
Coté fonctionnel c'est plutôt pas mal non plus: Je passe sur les basiques mais rien que l'immutabilité que tu ne retrouves pas en Go est déjà un sacré filet de sécurité pour la qualité du code. Hors FP tu as aussi le null safety.
Quand aux coroutines/channel c'est cadeau:
https://kotlinlang.org/docs/reference/coroutines-overview.html
Mais tu peux toujours rentrer dans la cour des grands avec le threading ou le multiprocessing, la programmation reactive, la programmation par acteurs puisque tu as la force de frappe de Java derrière.
Tu progresseras nettement plus avec un langage de ce niveau et tout ça sans rien sacrifier à la lisibilité et à l'expressivité.
En général, le Go n'est qu'un refuge pour les frustrés par python du temps où il ne gérait pas l'async, n'avait pas le typing et qui chouinent parce que faut configurer le packaging.
Maintenant on a Poetry.
Terminons par revenir sur Google qui nous a habitué à pas mal de revirements par le passé. Ceux qui ont misé sur GWT s'en mordent encore les doigts. Leur stratégie n'est pas clair quand à Dart, Go, Typescript avec Angular, … et Kotlin sur Android
Jetbrains ne mise que sur un cheval donc nul doute qu'il va porter son bébé.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . Évalué à 2.
Le Mr plus haut a un nom, pas besoin de rentrer dans ces jeux, et c’est plus facile de rechercher par la suite.
De 2, je ne reproche rien du tout à Kotlin. D’où tu imagines ça ? Tu penses que parce que j’aime Go, je suis Google fanboy ?
J’apprécie la Go Team, mais clairement, si ça dépendait que de Google, Go n’aurait jamais vu le jour. Le manager de Rob et Ken et Robert leur a permis d’expérimenter sur ce langage sans être affecté ailleurs. Si ça avait été un autre manager Google, sans l’expérience qu’avait ce manager vis à vis de Ken et Rob (ils bossaient ensemble aux Bell Labs), le projet Go aurait été mis aux oubliettes de Google.
Je m’auto héberge mes données sur nextcloud et évite au maximum Google et autre GAFAM.
Le monde n’est pas que noir et blanc, et le gris, c’est la majeur partie du monde.
Comme dit dans un autre message, je ne veux pas jouer au "mon langage est plus mieux que le tiens", mais je n’aime pas laisser des messages faux sans réponses.
Ok, c’est toujours rustique (haha), mais ça marche. Ils ont voulu améliorer avec le mot clé try (qui est, incroyablement proche du try rust dans ton post de comparaison Go VS Rust). Seulement, la communauté n’en voulait pas et a renvoyé la Go Team au tableau blanc pour réfléchir à une meilleure manière de faire voire trouver une solution communautaire
Oui, ça reste un langage impératif. On a quand même l’avantage de fonctions en tant que type de base et la syntaxe est plus agréable/lisible que sur une syntaxe C classique.
L’idée était de laisser la possibilité d’héberger là où on veut et de ne pas donner plus de travail à l’équipe Go. La gestion des dépendances n’est toujours pas complètement réglée, mais ça a bien avancé avec les modules, et grâce à ça, une sorte de centralisation de module existe maintenant avec le module proxy officiel dont une interface est disponible
Ian Lance Taylor et quelques autres s’y sont frotté. Ça doit être la 7ème ou 8ème implémentation des génériques qui a été testé. Mais les résultats n’ont jamais satisfait : soit c’était trop lent au runtime, soit trop lent à la compilation, soit la syntaxe était dégueu.
La communauté bloque beaucoup sur la syntaxe car on apprécie tous la simplicité de lire du Go. Rajouter une référence vers un type peut alourdir la lecture de code. Mais personnellement, la lib
mathavec des cast en float64 dans tous les sens, c’est pas un exemple de lisibilité si tu es enint. Du generics là dedans ferait le plus grand bien.Pour les prochaines estimations, on perdrait entre 10 et 30% de temps de compilation sur des libs en génériques.
Un moyen de tester ces futurs générique en cours de dev: https://ccbrown.github.io/wasm-go-playground/experimental/generics/
(et pour le try)
L’idée, ce n’est pas d’inclure les 8 itérations des generics, mais d’avoir une implémentation correcte sur laquelle on peut compter pendant plusieurs années, et pas une API qui casse au bout de 3 mois.
Qui pourtant n’avait jamais vraiment été implémenté sur un langage récent connu.
[^] # Re: Dart/Kotlin : Pourquoi pas Go ?
Posté par 16aR . Évalué à 1.
Comme dit, je pense que Flutter reste la meilleure option pour du natif sur mobile multiplateforme.
J’ai juste été déçu par le fait que rebuilder un projet qui fonctionnait avant est devenu complètement cassé par une mise à jour non voulue. C’est peut-être juste la faute à pas de chance (mise à jour de flutter + mise à jour de dart, dont une évolution (cassante) de l’API de dart)
Les options de Go sur mobiles sont encore expérimentales, et à part Zenly qui utilise gomobile en prod, je n’en ai pas vu beaucoup.
De toute manière, à partir du moment ou tu fais du mobile et tu t’interfaces au hardware, tu vas avoir des problèmes de compatibilité/interopérabilité et ce sera + complexe (en SDK natif, ou multiplateforme à la Flutter/Xamarin/Cordova/Ionic/Reacte Native, etc). Mais juste pour faire des requêtes réseau et un affichage sur le téléphone, les framework multiplateforme ça passe.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.