Aller au contenu Aller au menu
  • DĂ©pĂȘches
  • Journaux
  • Liens
  • Forums
  • RĂ©daction
  • đŸŽ™ïž Projets Libres

LinuxFr.org

Se connecter

Proposer un contenu

  • Pas de compte ? S’inscrire...

Re: DĂ©veloppeur Python en production ici 😉

Retourner au contenu associé (lien : Difficile de recommander Python en production )

  • [^] # Re: DĂ©veloppeur Python en production ici 😉

    PostĂ© par Gil Cot ✔ (site web personnel, Mastodon) le 09 mars 2025 Ă  16:39. En rĂ©ponse au lien Difficile de recommander Python en production . ÉvaluĂ© Ă  3.

    On peut aussi parler du temps de démarrage, une des raisons qui font que Mercurial a été refait en rust. Mercurial qui n'est pas juste un bench hello world, et qui n'a pas été écrit par des gens qui ne savent pas coder.

    Tout Ă  fait : Mercurial (<3) et Trac furent parmi les plus gros projets libres avec une certaine popularitĂ© et qui sont (en fait Ă©taient dans le cas de Mercurial) Ă©crits entiĂšrement et fiĂšrement en Python (d’abord 2... vu leur anciennetĂ©...)

    c'est pas bon pour les hyperscalers, ou pour les gens prĂȘts de leur sous. Je suis content de voir qu'Element a finalement corrigĂ© la conso mĂ©moire/cpu de synapse

    Aujourd’hui, comme vitrine, qui ne sont pas des sites web en Django (et mĂȘme lĂ , comme ce sont des plateformes fermĂ©es, on se contente des annonces faites en fanfare et de ce que ces entreprises veulent bien communiquer —par exemple que le cadriciel atteigne ses limites chez Disqus qui a progressivement remplacĂ© des parties critiques par du Go... mĂȘme s’ils continuent de contribuer— quand on cherche —on apprend par exemple que les gens de Meta n’utilisent pas l’ORM, et ont remplacĂ© plein d’autres briques du truc Ă  dĂ©faut de pouvoir remplacer toute la pile d’un coup, et je soupçonne Alphabet de suivre aussi ce chemin pour sa plateforme de vidĂ©os.) on a des turcs comme Element qui semblent peiner sur certains points. Bref, ça ne semble pas si simple...

    (git est en C, et la vitesse de git m'a souvent été mise en avant comme avantage).

    J’allais Ă©crire que bien moins de la moitiĂ© de Git est Ă©crit en C, mais je suis allĂ© vĂ©rifier avant, et, ça a progressĂ© depuis (on est maintenant Ă  50.2%, et je vois qu’il y a maintenant 0.8% de Python qui a fait son chemin, mais pour l’instant l’installation complĂšte pour une plateforme non-Unix embarque Bash+Perl+Tcl en plus des binaires principaux.)
    hg a pris un chemin similaire : écrire les parties critiques initialement en C puis finalement en Rust. Synapse aussi a choisi le chemin de la rouille. Pas de compromis à la performance...

    "It is seldom that liberty of any kind is lost all at once." ― David Hume

Revenir en haut de page

Derniers commentaires

  • Devenir Adulte
  • Re: Don't feed the troll
  • Re: IANAL
  • Re: Dans linuxfr il y a ...
  • Re: Des donnĂ©es structurĂ©es, en remplacement d’un fichier tableur absurde
  • Re: Non informaticiens
  • Dans linuxfr il y a ...
  • Re: DĂ©jĂ -lu (Ă  lire avec l'accent anglais)
  • Re: Non informaticiens
  • Re: IANAL
  • Re: Le sens des prioritĂ©s
  • Re: IANAL

Étiquettes (tags) populaires

  • intelligence_artificielle
  • merdification
  • grands_modĂšles_de_langage
  • rĂ©chauffement_climatique
  • administration_française
  • canicule
  • cybersĂ©curitĂ©
  • startup_nation
  • capitalisme
  • linux
  • dĂ©ni_de_rĂ©alitĂ©
  • vie_privĂ©e

Sites amis

  • Agenda du Libre
  • April
  • Éditions D-BookeR
  • Éditions Diamond
  • Éditions Eyrolles
  • Éditions ENI
  • En Vente Libre
  • Framasoft
  • La Quadrature du Net
  • Lea-Linux
  • Open Source Initiative
  • Imprimerie Grafik Plus

À propos de LinuxFr.org

  • Mentions lĂ©gales
  • Faire un don
  • L’équipe de LinuxFr.org
  • Informations sur le site
  • Aide / Foire aux questions
  • Suivi des suggestions et bogues
  • Wiki du site
  • RĂšgles de modĂ©ration
  • Statistiques
  • API pour le dĂ©veloppement
  • Code source du site
  • Plan du site

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /