Reprise du message précédent :

Et s'ils cliquent sur des liens payants c'est pas plus mal

PQ

A voir.

https://mobile.twitter.com/rahsfan/ [...] 7321633792  

- le premier c'est une feature snippet, beaucoup de gens adorent ça parce que ça t'extrait l'info sans avoir à cliquer. Je reconnais que la pertinence est aléatoire, et c'est pas ma feature préférée
- le second c'est un site de merde avec un paywall : pour le coup je suis pas certain de où c'est la faute de google (en l'occurence on a justement sorti l'info pertinente pour que tu n'aies pas à te taper le paywall
- 3ème idem, c'est un bon site statista, mais effectivement ils ont aussi un paywall (je note ici l'aspect rigolo : faut pas que le site ait de publicité, mais les paywall c'est le mal aussi. Donc en gros faut juste que le site fille ses données sans rien demander, parce que c'est pas du tout une vision idéaliste où moins de 1% des gens vont payer pour le service)
 

+1000 : on est des vieux cons de l'internet ici, tout ce topic a connu Altavista et Yahoo, on sait tous coder (à des degrés divers j'en conviens ), je suis sur qu'on a tous tapé des chaines d'initialisation V92 de modem dans des champs abscons, et qu'on a fait du memmaker (voir compilé un kernel, monté une machine virtuelle, etc...)
C'est PAS DU TOUT le skillset de l'utilisateur lambda.
 

c'est juste le profit, pas le CA (on devait deja être à 150milliard de CA à cette époque)
 

oui j'étais surpris de voir aussi la shit storm. Toute la population LGBTQ+ + "allies" leur tombe dessus (y'a des points valables soulevés, genre une lesbienne qui parle de sa femme ouvertement, à quel moment ça devient de la politique ou pas, c'est une bonne question)
 

bon je suis un con de manager, mais j'ai jamais compris l'attrait pour Go :  
- y'a pas de syntactic sugar sympa comme dans Python ou TS, du coup ça fait jeune vieux langage
- c'est rapide, mais je pense que Java doit rester compétitif, et donc t'as plus rapide (C/C++/Rust), ou plus lent et plus expressif (Python, etc...)
- j'ai cru comprendre que c'était nativement plus simple de faire des app multithreadées safe, mais du  coup ça justifie tout un autre écosystème ?

au cours de mes googlings de go, j'ai trouvé un blogs qui disait qu'en fait les structures de concurrence de go sont trop lentes pour avoir une tonne de concurrence.
 
(sinon, j'ai pas bien compris la remarque, quelqu'un a mis une info derrière un paywall, google a été la chercher, et l'a affiché en même temps qu'un mur de pub qui va dans sa poche, et c'est moi qui cherche l'info qui suis hypocrite??? je cherche que des infos gratuites dans google, merci beaucoup, je trouve mes infos payantes autrement)

et allez pas me dire que je veux tout gratos, j'ai récemment payé 40€ pour 2 putains de PDF, et une tonne de fric en bouquins.

Moi, je dis qu'il faut faire un graph de Kano pour évaluer la valeur client Désolé, je viens de finir mon initiation au lean management  

Concurrence facile oui mais safe non: tu peux balourder des pointeurs (donc partager de l’état mutable) à travers les channels, et comme ils sont lents il est fréquent d’utiliser des primitives plus bad niveau, et genre tu peux segfault si tu protèges pas bien tes accès aux hashmaps.  
 
D’ailleurs c’est marrant, comme ils ont vendu de la concurrence massive mais que les primitives suivent pas t’as un mode spécial pour essayer de toper les erreurs de concurrence au runtime, style UBSan mais pour les race conditions (techniquement c’est basé sur tsan).  
 
A la base ca a été fait pour écrire des petits services réseaux et les rendre faciles a déployer: tu peux gérer une chiée de connection en mode « thread per connection » avec les goroutines, le cross-compile est facile et la stdlib est très fournie en services réseau reimplementés en go, donc tu peux facilement compiler ton artefact et le balancer sur ton serveur et zou.

Ok...du coup ça apparait pas supérieur

Sinon cadeau pour toi : https://vm.tiktok.com/ZMeCHFUBa/ (un indice : only in Australia)

- C'est pas délirant de livrer le langage avec peu de features syntaxiques et un format standard, je pense que ça a contribué à la popularité du langage.
- C'est le juste milieu qu'ils voulaient.
- Non. Il a su faire sa niche dans l'univers du networking, notamment pour la raison que tu cites et je suis pas sûr que ça soit pertinent de vouloir faire autre chose avec.
 
Je pense que si la gestion/l'intégration d'asyncio existait dans python quand Go est sorti, ça aurait très probablement changé la donne.

Tu oublies le modèle relationnel et tu réfléchis aux requêtes dont tu vas avoir le plus besoin, et tu modélises dans l'optique d'optimiser ces requêtes-là.

C'est pas plus rapide que le Java et il y a moins d'opportunité de tuning qu'avec la JVM, en tout cas.

Youtube ? Tu rigoles, il y a des milliers de chaînes passionnantes et dont les productions n'ont pas d'équivalent ailleurs. Perso je suis abo à environ 300 chaînes et j'ai pas le temps de regarder tout ce qui sort.

Youtube je regarde de temps en temps des concerts ou alors des trucs postés ici ou sur twitter, mais généralement j'ai pas la patience de regarder en entier.

Je travaille sur un proto et j'ai aucune idée du périmètre final du produit.
Ce qui veut dire qu'il y aura forcément des évolutions à prévoir dans le futur.
Peut-être que mon approche n'est pas adaptée, ou bien qu'au final, je me noie dans un verre d'eau.

le snippet n'est pas une pub.
 
En gros : c'est pas parce que c'est pas un lien bleu standard que c'est forcément une pub :  
- toutes les zones de pubs ont une mention "Annonces / Ads" : si y'a pas la mention c'est du contenu organique, donc gratuit et sur lequel Google ne gagne pas d'argent
- les feature snippets ne sont pas des pubs
- c'est pas parce que ça permet d'acheter le produit que c'est forcément une pub (des fois on affiche juste des infos sur le produit, ou meme des offres si on pense qu'elles sont pertinentes)
 
 

En fait, Google ne peut pas le dire, mais c'est un échec massif, ce langage. Au départ, ils voulaient faire un "C plus pratique", puis rapidement, au vu des perfs qui n'étaient pas là et des restrictions, ça a changé d'objectif, c'est devenu une espèce de "Java plus sympa".
Les benchmarks que j'en ai vus montrent que c'est un chouilla plus lent que le Java, et il y a moins de possibilités d'optimisation.
 
Je ne juge pas du coté sympa de la prog en Go, je n'en ai jamais fait (et ne compte pas en faire). Mais même si c'est moins lourdingue que le Java, ses caractéristiques et ce que tu en écris ici me font penser que ça n'est pas adapté pour des gros projets. Je me demande si c'est réellement utilisé chez Google en dehors de quelques outils internes.
Après pour faire du prototypage rapide et se rendre compte des problèmes qu'on va devoir surmonter, pourquoi pas, mais franchement, qui fait ça ?
 
 

Nebula

Alors je ne prendrais pas le risque de partir sur du NoSQL, surtout sans expérience.

Jamais entendu parler.

Non.  

Ils voulaient faire un langage sur lequel il est trivial d’onboarder et d’être productif et facile à reviewer.  
 
Il y a des pièges dedans mais fondamentalement go t’en as fait le tour en une matinée et tu peux commencer à coder des services réseaux dans l’après midi. De ce point de vue, c’est loin d’être un échec.  
 
Le but n’a jamais été « un C plus pratique », en tout cas pas dans le sens ou le reste du monde l’entend (coder des quenelles ou des libs réutilisables arbitrairement), tous les choix faits vont à l’opposée de cette idée. À dessein.

Après c'est un projet perso, qui n'a aucun objectif propre sauf me former/remettre à niveau.
Mais c'est sûr que j'ai pas envie d'y passer 90% de mon temps dessus.

Oui niveau philosophie, go remplit ses objectifs. On y fait des trucs simples, explicites. Le langage est tout entier tourné vers son style.  
 
Pour répondre à la question de l'usage en interne, c'est un langage qui rencontre un franc succès et qui est largement plébiscité.

manque juste quelques trucs pour rendre le langage agréable, mais sinon c'est pas non plus une purge

 
Il y a encore des bonnes raisons d'utiliser du NoSQL maintenant que la hype est passé et qu'on s'est rendu compte que ce n'était pas plus perf que du RDMS

Mais c'est pas un peu du biais de sélection, vu votre politique quant aux langages autorisés?
 
Parce que plébiscité par rapport à devoir faire la même chose en C++, vs plébiscité dans l'absolu, c'est un peu différent.

 
Mais c'est génial votre astuce  

Où as-tu vu ça ?

 
Ça fait longtemps que j'avais vu passer des benchs entre MongoDB et PostgreSQL mais c'était peut-être un peu biaisé vu que ça venait de compte Twitter de consultants Postgre

 
C'est vrai. En même temps si je suis les discussions qui ont lieu ici, c'est comparé à C++, java et python, qui sont des langages autorisés. Mais effectivement, l'adoption en interne c'est une compétition un peu biaisée. On me demande, je réponds

L'intérêt du NoSQL est d'être très facilement scalable, ce qui est plus difficile avec un RDBMS

En dehors des perfs, c'est comme go, y'a des cas où ça a du sens d'utiliser ça plutôt qu'autre chose (à part mongo db)

 
alors oui, mais combien de projet ont réellement besoin de scaler hors de l'echelle d'un SGBDR ? Ou plutôt pour combien de projet cet avantage est supérieur à celui d'assurer une cohérence des données  
 
perso, le plus gros intérêt que je vois est pour de l'embarqué : synchroniser du NoSQL est beaucoup plus simple que du relationnel. A
u moins quand tu as un objet il est complet, alors qu'il y a souvent un ordre précis à avoir pour des données relationnelles no pété. Par contre, le volume de données est plus grand est la cohérence des données plus complexe à assurer

De mon expérience pro/perso, qui est plutôt limitée, j'ai pas vu beaucoup de cas où le NoSQL était utile sur la scalabilité (dans le sens où avant de mettre le RDBMS à genoux, il fallait y aller, c'était souvent l'application qui était mal branlée).
Quant à utiliser du NoSQL pour toute l'application, j'en ai jamais vu.

Tu sais que le NoSQL ne se limite pas à MongoDB, hein ?

 
no shit

Je ne vois pas bien ce que ça apporte par rapport à du Python, dans ce cas.

Non mais si le NoSQL n'apportait pas in fine les performances nécessaires dans les cas d'utilisation précis où c'est utilisé, ça n'aurait pas été inventé et ça ne serait pas l'outil de base des GAFA. C'est tout ce que je veux dire, rien de plus.

Objectivement, python est beaucoup plus gros et complexe, et créer des services réseaux qui gèrent la charge avec est pas trivial, asyncio est chiant et bordélique avec autant de footguns que go a lui tout seul, et n’existait pas quand go a été créé.

Wait, t'as déjà essayé de faire des services réseaux (pas du http) avec Python? Non-blocking Avec de l'asynchronisme qui plus est?

Et puis la praticité d'avoir le truc tout packagé dans un exécutable sans dépendances