JavaScript puis TypeScript. Et ensuite ?

[@devcrown]

C’est incroyable la série de vidéo que tu fait en ce moment continue super contenu, concernant le go ça m’intéresse énormément je sais que le bon coin utilise ça et ils sont ps mal de gain de performance

[@codeconcept]

Merci devcrown 😀 Go monte ces derniers temps. Mais comme pour Python, son adoption nécessitera de voir comment elle se ventile, car hors DevOps, je ne sais pas ce que va donner niveau opportunités pour les développeurs web. Tout comme Python est très utilisé par des experts en data et en IA, en web, Python est beaucoup moins porteur (peu de jobs sur Django et Flask). Alors ce sera peut-être pareil pour Go. Le gros plus, c'est qu'on peut compiler vers Web Assembly avec Go. Donc si WASM monte fort, il y a moyen d'être sur ce créneau via Go. La création de CLIs pour des outils notamment réseau est une utilisation courante. Le développement web : à voir. Mais il y a des frameworks déjà mûrs :) Une fois Go pris en main (et plus encore), en route vers Rust. Et comme theprimeagen, utiliser l'un ou l'autre selon les cas de figure 😎

[@devcrown]

@@codeconcept yep pour ma part j’attend d’être encore bien mûre sur ma stack technique avant de commencé d’autres a voir ce que ça va donner

[@codeconcept]

@@devcrown Oui, il n'y a pas d'urgence de toutes façons. La moitié de la veille techno, c'est déjà de savoir ce qui existe. On ne peut pas tout apprendre, sinon c'est le burn-out assuré 🤯😅

[@bayoudev]

En tant que développeur web back-end avec principalement NestJs depuis 3 ans, j'ai toujours eu du mal a voir les limites de performances du js même sur de grosses applications. Mais ce genre de benchmark me fait dire que "oui. il faudrait regarder un peu ce qui se fait ailleurs, dans d'autres langages aussi" Merci beaucoup pour ce genre de vidéo, huge fan !

[@codeconcept]

Merci Hugo 😀 👍 La montée en charge que peut encaisser Go est impressionnante. Je ne m'attendais pas à un tel écart avec TS. Bon, étant sur une techno qui monte (avec Angular en Front ?), tu n'as pas de pression. Je vois de plus en plus NestJS cité en "connaissances appréciées" dans les annonces. Tu pourras monter en compétence quand tu auras le temps🍹 , l'envie étant visiblement déjà là 😉

[@stephanegongmoga379]

​@@codeconcept ou être prêt avant 😅😅😅

[@mosdev1663]

Merci pour tes lumières, développeur avec 2 ans d'xp php Js Ts, je sais et m'invite à sortir de ma zone de confort, Go m'attire car ton discours je l'ai déjà entendu d'un ami et j'ai très envie maintenant d'y aller, merci pour ce rappel.. Hâte de voir tes prochains postes à ce sujet 😉.. Let's GO!!! Like + abo ? abo : déjà abo

[@codeconcept]

Après un an - parfois intensif - de Go, je confirme que c'est un langage très intéressant : simple et performant, avec en prime une standard library très fournies et une bonne communauté. Alors oui, let 's Go 😀

[@bd3670]

Moi je suis sur la chaine, et pourtant je fais de la vérification formelle. Quoique, tes vidéos n'intéressent pas seulement les développeurs web :)

[@codeconcept]

Merci de suivre mes vidéos alors 😀 J'ai dû chercher ce qu'était la vérification formelle. La page wikipedia aurait besoin d'un poil plus de détails 🙄😁 ://fr.wikipedia.org/wiki/V%C3%A9rification_formelle Quoique "méthode formelle" donne plus de détails : fr.wikipedia.org/wiki/M%C3%A9thode_formelle_(informatique)# J'ai l'impression que ma 3ème tentative aura été la bonne : herbrete.vvv.enseirb-matmeca.fr/AMF/index.html Ca donne l'impression que c'est un métier transverse entre l'archi, l'AMOA et le test. C'est la première fois que j'entends parler de ce métier pour tout dire. Probablement parce qu'on le trouve dans des secteurs bien plus pointus que l'informatique de gestion, où on peut se permettre de découvrir les bugs ... après avoir poussé en production 😁 (j'exagère hélas à peine).

[@picatchumm64]

Bonjour, Plus de video en ce moment sur la chaine, c'est vraiment top ... gofiber à l'air vraiment bien en terme de req/s et de possibilitées. Perso en terme de méthode chat GPT m'aide beaucoup a passer le cap de l'apprentissage pour le golang (génération de code et compréhension)

[@codeconcept]

Merci (picatchumm * 2) + 5217 😀 Je vais demander à KZbin un badge de pseudo le plus long 😎 (tu l'as doublonné récemment ou je réalise que maintenant ?) Fiber a l'air d'être un des plus frameworks web les plus populaires dans le monde de Go en effet. Avoir utilisé la DX d'Express est malin. Etant adepte de Qwik, j'irai aussi voir Gin, car c'est Manu Almeida ... le créateur de Qwik qui l'a créé. J'ai arrêté de jouer avec Chat GPT ces temps-ci, mais je vais peut être m'y remettre avec Go. Leur doc est ceci dit bien faite et il y a beaucoup de blog posts et de réponses sur Stack Overflow. Ca m'a débloqué jusqu'ici. Mais si Chat GPT peut me donner un coup de main supplémentaire, c'est bon à prendre 😉

[@picatchumm64]

@@codeconcept :-) KZbin demande un Nom + Prénom (il faut que je regarde pour faire mieux comme pseudo 😎 (pas trop cherché en fait ) 😀😀😀 ----> (edit) modification du pseudo effecté 🙂 (ce qui m'a attiré vers Fiber c'est son routeur -> valyala_fasthttp (Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http ) pour une API REST. Gin à l'air très bien aussi ; je ne savais pas que le créateur de Qwik était aussi sur ce projet.

[@codeconcept]

Bon bah, j'annule la commande de badge "looooongest" nickname 😅 Les 3 frameworks Go pour le web que j'ai maintenant dans le collimateur sont : Go Gin pour la popularité et le fait que c'est le dev de Qwik qui est derrière, donc gage de qualité gin-gonic.com/ Go Fiber pour la vitesse en effet et l'excellente documentation (ça compte quand même 🔍) gofiber.io/ Go Chi pour sa compatibilité avec le le package natif net/http go-chi.io/#/README pkg.go.dev/net/http Même si dans le cas de chi, c'est surtout parce que je suis en phase de montée en compétences. Donc je sens que ça va se jouer entre Gin et Fiber 🏁😀

[@oumar_kone]

Je commence a adoré le langage Rust

[@codeconcept]

Il ne reste plus qu'à attendre qu'il monte en popularité dans les entreprises 😀

[@jfrancai]

Je viens de lancer la creation d'un portfolio la semaine derniere, pas tres motive a l'idee de refaire un back-end node je me suis dis pourquoi pas Go. Auncun regret la transition est super smooth le language est incroyable. Ca reste haut niveau et on profite des gains de performance. J'ai pas encore plonger dans les Go routines mais ca ne saurait tarder :)

[@codeconcept]

C'est clair 😀 On peut dire que c'est aussi simple à apprendre que JavaScript, avec les performances de C++ 😅 Bon, d'accord, il y deux trois choses moins simples que JS, et c'est peut-être un peu moins performant que C++, mais on est dans le même ordre de grandeur. Bon courage avec les goroutines. Ce sera étonnamment plus simple qu'anticipé. Surtout avec le package sync 😎

[@jfrancai]

@@codeconcept Merci ! Bon courage pour la suite, les vidéos sont super ! 😁

[@codeconcept]

Merci 😀 L'inspector Columbo qui est en moi remarque que tu as supprimé le s de ton pseudo pour ne pas dépasser la limite des 8 caractères. Une habitude d'admin réseau d'il y a longtemps ? 😁

[@jfrancai]

@@codeconcept Haha c'est presque ça 😂 Si quelqu'un passe par là et qu'il a la ref qu'il se montre 👀 Je n'en dirai pas plus 🤗

[@otmanm4095]

Perso, j'ai fais ma reconversion avec l'écosystème JS/TS, mais à côté j'm'interesse pas mal au C++ en général et c'est l'enfer comme ecosysème, au moins ça permet de relativiser les soucis de Node et son ecosystème. Je découvre aussi Ziglang, c'est top aussi, mieux que C++ (moins bloated) par contre ça manque vachement de tooling, d'ici quelques années ce sera mon langage de side project j'imagine. :') Golang ça doit être le feu pour les startups. Super vidéo, merci!

[@codeconcept]

Merci otmanm4095 😀 Ca prend bien dans le monde des start-ups vu que ça permet de réduire les factures en infra du fait des perfs et de la faible consommation en RAM et CPU. Mais aussi dans pas mal de grands comptes. L'écosystème de Go est très carré : - des packages accessibles via pkg.go.dev/ - un standard library riche (bon, tout le monde se vante d'avoir la sienne riche) - des conventions claires - la composition plus que l'héritage (pas de classes si j'ai bien suivi) Par rapport à JS, rien que le choix du bundler peut donner lieu à hésitation 😁 Mais bon, en creusant, je vais bien finir par trouver des choses qui me plaisent moins. Rien n'est parfait en ce bas monde 🗺️ J'ai entendu par le même theprimeagen beaucoup de bien de Zig. Mais bon, 24 heures dans une journée, donc je te laisse ouvrir la voie tel Indiana Jones 🤠. Je reste sur Go puis Rust quand (ou bien si) j'aurais le temps de me pencher dessus de nouveau 😉

[@Learnbynet]

6:14 Un des principaux problèmes de performance est que la plupart des gens se contentent du "high level" en js/ts et n'ont aucune notion du "low level" et des façons d'optimiser les accès à la mémoire, les optimisations mono et polymorphiques qui peuvent impacter le moteur V8 lorsqu'il effectue une passe d'optimisation... En bref, ce n'est pas parce que js/ts permet certains patterns qu'ils doivent être utilisés. J'aurais bien aimé vous fournir quelques articles et liens sur le sujet, mais je ne peux pas (yt).... - Évitez les opérations coûteuses comme les boucles imbriquées. - Utiliser des Iterators Set/Map - Eviter les pattern FB ou tous dois être immutable, (l'immutabilité est un outil et ne devrai pas être un design pattern.) - l'ordre d'access des index durant une loop est très TRES importante également ! (ECS démontre tres bien ce problème) - .. j'en pas bcp....

[@codeconcept]

C'est vrai que Map et Set (sans oublier les WeakMap et WeakSet) existent depuis bientôt 10 ans mais sont moins populaires que d'autres nouveautés d'ES 6 (comme for of, const, class etc). Il y a eu trop de nouveautés d'un coup dans cette version d'ES 😅 Ceci dit, dans un QCM technique, c'est une solution souvent proposée d'utiliser Set quand on doit dédoublonner un array. En revanche, dès qu'on regarde le code source de libs ou frameworks, il ne se passe pas longtemps avant qu'un Map ou un Set fassent leur apparition (sans oublier un proxy). C'est probablement plutôt les développeurs plus avancés, ou ceux qui créent des fonctionnalités plus avancées, qui en ont davantage l'usage 😉

[@petit-hommeben-jacques5606]

Mercii!

[@codeconcept]

Merci Ben-Jacques 😀

[@mielderuche8027]

Je passe de JS à TS c’est vraiment bien le typeScript lourd au début mais on si retrouve vite en qualité de code. L’ESN où je suis la stack est react/Java sur tout les projets très peu de back en nodeJS (vite fait des back pour s’authentifier…) Avant d’arriver là je cherchais un poste full stack JS j’ai rien trouvé…. Je confirme Samir c’est assez rare, bien que dans mon ancien poste j’étais sur react/express

[@codeconcept]

C'est vrai qu'on développe moins vite au départ. Jusqu'au moment où on finit par connaître par coeur les types les plus souvent utilisés. La mémoire des doigts😁 Le premier qui frustre étant que le type de "children" est "ReactNode" (grrrr 😅), qu'une ref sur un champ texte est un useRef< HTMLInputElement >(null) (encore là, c'était plus intuitif),pour un textarea c'est un useRef(null) : bon là on commence à voir le pattern pour les autres. Et de là, on créé des types customs pour chaque props passée et on recommence à trouver sa vitesse de croisière d'avant TypeScript 🏄🏻‍♂️ Je viens de trouver cette cheat sheet sympa ceci dit : react-typescript-cheatsheet.netlify.app/ Oui, le JavaScript partout, "un seul langage pour le Front et le Back", est la plaquette publicitaire du développement web : dans les faits, c'est peut-être 10% des projets (non-perso) 😅 Les "vieux" langages côté back trustent le podium : Java, PHP, C#. Même si j'ai vu passer cette semaine une annonce Angular / NestJS 🎉

[@mielderuche8027]

@@codeconcept merci super cheat sheet 👍

[@moneyfr]

pourquoi on ne migre pas tous simplement de node à deno ? J'ai l'impression que c'est plus compliqué que ça ?

[@codeconcept]

Deno, malheureusement, ne prend pas encore en entreprise (je ne vois pas passer d'annonces en tous cas). Et ce qui est dommage - j'ai vu passer ça dans une newsletter il y a quelques mois - c'est que Deno supporte désormais les packages npm. C'est dommage que l''équipe n'ait pas tenu bon et coupé avec un des points qui a rendu Node trop lourd et moins sûr (il y des packages avec de sacrées vulnérabilités).

[@MrNiuxe]

zend a été renommé Laminas. Il me semble que c'est la fondation apache qui ait repris le flambeau. Il y a de temps en temps du back nodejs : Nest ou Express. Par contre, du next, c'est souvent le cas. Go est pour moi un langage immature. Quand j'ai vu ce que c'est, j'ai fui (exception, tu, objet, etc.). Il existe des framwork c++ pour faire du web. Faire du devops en c++, ça doit être possible. C++, je ne connais pas vraiment le sujet. Mais ça reste un langage tellement abouti que je ne vois pas l'intérêt de go. Je confirme qu'il y a de temps en temps du go et comme vous dites, avec des profils front. Cependant, il ne faut pas oublier qu'en ce moment (ça va un peu mieux tout de même), il y a une crise dans le secteur. Les boites ne cherchent plus le mouton à 5 pattes, mais à 20 pattes pour un salaire minable.

[@codeconcept]

Les créateurs de Go sont des experts C++ ... qui ont choisi de créer un langage bien plus simple que leur langage de prédilection. Ils ont finalement ajouté les generics l'an passé. Ne manque plus que de vrais enum et il aura tout d'un grand. Mais l'objectif (réussi !) était de créer un langage facile à apprendre dont les app seront faciles à maintenir. Le paradoxe est que les développeurs qui ont durement appris C++ n'utiliseront probablement jamais un langage créé par leurs pairs, car ils en ont déjà bavé pour devenir bons en C++. C'est quand même un poil injuste de considérer que Go est immature. Les créateurs de Go ont choisi que Go ne soit pas orienté objet. Mais comme on s'est fait formaté l'esprit par la POO, on a du mal à tourner la page. En JavaScript aussi d'ailleurs, on voit la composition de plus en plus privilégiée au détriment de l'héritage. On peut ceci-dit créer des "méthodes" en Go en les associant à des types customs. Au quotidien, la gestion des exceptions atypique fait qu'on se trouve très (trop?) souvent à tester si "err" n'est pas "nil" après chaque opération risquée. Mais on s'y fait. Ce qui est pénible par contre, c'est que les variables et packages non utilisés empêchent de compiler. En début de dev d'un POC, on se retrouve souvent à essayer plusieurs pistes, on commente alors un type ou une fonction importée et boum, le package correspondant se retrouve importé pour rien : résultat ça compile plus grrr. En revanche, l'énorme plus qui compense largement, c'est la vitesse de compilation. Pour avoir bossé sur une appli qui compilait en plusieurs minutes, c'était un calvaire. C'était facilement 1h00 à 2h00 perdues chaque jour à attendre. Et quand ça urge, c'est pénible. Donc, là, la vitesse de compilation de Go est vraiment appréciable. Pour le reste, je trouve mon bonheur dans de nombreux domaines : création de CLIs, de backend web et API REST. Et même capture vidéo : github.com/vladimirvivien/go4vl et détection de visages : github.com/esimov/pigo Le gros plus étant apparemment que la communauté de Go a créé beaucoup de wrapers de libs C qui permettent d'utiliser plus facilement les libs en question. Sans oublier la de création d'outils réseaux. Il y a moult packages natifs ou créés par la communauté qui permettent de (facilement !) créer des port scanners, autre packet sniffers et même des load balancers : pkg.go.dev/github.com/google/gopacket/pcap pkg.go.dev/github.com/google/gopacket/pcapgo pkg.go.dev/github.com/google/gopacket/layers Je retrouve le plaisir du développement en mode buffet à volonté 😅

[@didier..n..1567]

Hello Ca vas trop vites je ne suis plus. Une I.A finira t'elle pas par prendre le crtl un de c'est jours..??? Je reviens donc à mon PYTHONAGE le langage de ma favorite passions du CODE 💻 PS ; le GOLAND sympa j'ai tester pour le client sur le back pas testé PS 2 : ça serait cool Samir, si tu pouvais donner une formation sur GO bien sur payante dans code concepts..

[@codeconcept]

Pour l'instant les IA ne font pas le poids 😅 Ou plutôt, elles sont de bonnes assistantes, pas encore des terminators qui vont nous faire un "I'll be Back" 😎 🦾 Pour ce qui est de la vitesse de sortie des techno, Il n'y a pas d'obligation à apprendre tous les langages : savoir ce qui existe d'autre est déjà un gros plus en matière de veille techno. Je vais sortir un tuto sur YT pour montrer comment un(e) dev JS/TS peut prendre en main Go rapidement et avec le minimum de soucis. Ensuite, si le tuto plait et donne envie d'en savoir plus, je pourrais sortir un "Go par la pratique", mais pour ça, il faut que je termine les POCs que j'ai sur le feu. Sinon, ce serait mettre la charrue avant les boeufs 🐂😀

[@guillaumefortin4837]

Pour me former à un nouveau language, je prends tout simplement une formation payante et j'apprends 10 fois plus vite.

[@codeconcept]

Avec comme avantage que quand on paie, on a tendance à s'impliquer davantage sans quoi on aura jeté l'argent par la fenêtre 💸 Pendant la canicule de 2022, pour ne plus allumer d'ordi aux heures les plus chaudes (et donc ajouter une source de chaleur), j'ai redécouvert les joies ... du livre technique papier. Une autre source de connaissances remplacée par les vidéos, mais qui permet de creuser des sujets sur une semaine de lecture. Une échelle de temps plus longue que ce à quoi les vidéos nous ont habitués.

[@bossgd100]

Tu as appris go en combien de temps ?

[@codeconcept]

En une dizaine d'heures, je comprenais le code que je trouvais d'autres dev Go. Y compris lorsqu'il était question de goroutines pour le multi-threading vue que Go rends ça très simple d'utilisation. J'ai dû résister à la tentation de tout envoyer valser car je n'aimais pas la syntaxe. Vingt heures de plus pour prendre des exemples d'autrui et les tordre pour leur faire faire autre chose 😅 Une dizaine d'heures de plus pour revoir certains concepts vus un peu à l'arrache au début par empressement. Notamment comment articuler les structs et les interfaces. Ou encore les channels pour faire communiquer les goroutines ou encore éviter que l'appli s'arrête alors que toutes les goroutines n'ont pas terminé. Maintenant, je suis en train de voir ce qu'on peut faire côté développement web. Il y beaucoup de frameworks web, dont un créé ... par le créateur de Qwik : Gin (framework HTTP écrit en Go). Même si je pense me servir davantage de Go pour faire des petits outils en CLIs, des web scrapers multi-threadés, des trucs comme ça. Donc à la louche, en une trentaine / une quarantaine d'heures, on commence à créer un projet perso. Là où avec Rust, il faut le double ou le triple de temps. Ceci dit, je retournerai à Rust dès que j'aurais plus de temps (et de temps de cerveau), car je reste bien pris par Qwik. J'ai choisi Go pour des progrès rapides. Et PAS parce que je le trouve mieux que Rust. Chaque outil pour sa tâche et sa contrainte spécifique 😉

[@bossgd100]

@@codeconcept donc une bonne semaine à temps plein , merci pour ta réponse :) . J'étais en train d'hésiter entre le rust et le go là justement ... Oui il faut utiliser le bon outil à l'instant T , quitte à réécrire le code plus tard dans un autre langage

[@dev-rachid]

Concernant nodejs, je trouve que c'est une aberration de l'utiliser du côté backend car il est nodejs est asynchrone, c'est juste rajouter de la complexité. On ne peut pas se permettre d'attendre une réponse à une requête sur une db côté backend, on pert également en performance. Par contre côté frontend, je trouve que c'est normal d'attendre une réponse de requête car le navigateur, client n'a pas d'autres choix, il doit attendre.Son utilisation est donc normal côté client. Python est meilleur côté backend, car plus performant. Go je ne connais pas encore, je vais tester. Merci pour ces infos 👍

[@codeconcept]

Merci Rachid 😀 Python par rapport à Node côté backend, je ne sais pas ce qu'il donne niveau perf. Mais c'est certain que Go sera plus performant. En backend Python, j'avais beaucoup aimé Django, notamment le fait qu'on a d'emblée une interface d'admin. Il y avait en revanche le fait que leur pattern MVC était différent de tous les autres. Leur View était en fait le Controller ou quelque chose du genre très perturbant 🙃 Mais c'est le faible nombre d'offres d'emploi qui m'avait fait abandonner Python en tant que développeur web.

[@olygood]

Quand tu dis un server typescript c'est bien un server node écris avec typescript ou alors j'ai raté un épisode back-end. Et les Server php que l'on a réecris en node js pour aller plus vite c'est déjà fini😅 maintenant voilà node js plus lent que php go rust Java c#. Une Ferrari qui passe 2cv😢

[@codeconcept]

Hello olygood, ça faisait un bail 🍺 Oui, on peut effectivement utiliser TypeScript avec Node. Bah en fait, avec Go et tous les autres langages compilés et multi-threadés, ils partent avec un avantage natif. Mais dans le cas de serveurs classiques, il y déjà beaucoup de choses qui peuvent permettre de booster les perfs : le cache, la compression, des bonnes configurations etc. Ni Node et encore moins PHP ne vont partir à la retraite de sitôt 😀 C'est ceci dit toujours intéressant de voir ce qui se passe dans d'autres technos complémentaires 😉

[@moneyfr]

Je connais un développeur gauche chez Hubert il touche 8500 dollars et il travaille en télétravail la belle vie

[@codeconcept]

Un exemple à suivre 😎

[@Bz9119]

À cause de WordPress PHP va perdurer. La majorité des sites en ligne sont conçus à partir de WordPress. Et qui dit WordPress parle de PHP.

[@codeconcept]

Il ne faut pas oublier Laravel et Symfony, qui apparaissent sans cesse dans les annonces tant de poste en CDI que de missions freelances 😉

[@MarcChouteau]

Et ensuite ? Blazor !

[@codeconcept]

Ca me rappelle mon époque C# : ce qui pourrait m'inciter à jeter un oeil à Blazor 😀

[@benoitl.858]

FIRST :)

[@codeconcept]

🏁😅