Reprise du message précédent :

Perdu ! https://france3-regions.francetvinf [...] 51264.html

 
Oui enfin, moi je ne parle pas de l'installation d'un de leur siège par rapport aux JO. Je demande à voir les prospectus distribués dans le 93 dans les boite aus lettre des habitants du coin.

   
 
c'est assez décevant l'evolution des langages non-GC
entre le C, le C++ et Rust, chacun a de gros inconvénients
le D est DCD
zig est encore assez experimental
swift était pas mal mais est utilisé uniquement en écosystème apple. même si en théorie ça pourrait ne pas être le cas.

inb4 le viol collectif de sligor par la Rust Evangelism Task Force

cppreference :  

 
https://godbolt.org/z/ocxMneYKz
 
ma foi... on apprend tous les jours.

 
Si on jette des donuts, tu crois que ça éloigne Masklinn ?

en langage pour gens qui n'ont plus fait de C++ depuis 7 ans ça donne quoi ?  

N'en rajoute pas stp, déjà que sa mère a lavé son body pillow le mois dernier et que le drama villebrequin a éclaté...
 

edit: j'ai compris    
 
bon après l'héritage en diamant ça a toujours été la merde avec le C++

 
Si tu fais de l'héritage multiple comme ceci :  

• Base
• Derived1 qui hérite de Base
• Derived2 qui hérite aussi de Base

Et enfin X qui hérite à la fois de Derived1 et Derived2, alors l'héritage multiple virtuel indique au compilateur qu'il ne doit y avoir qu'une seule copie de Base partagée entre Derived1 et Derived2. Ce qui est une bonne chose.
 
Ce paragraphe quant à lui dit en gros "si tu laisses les defaults pour tout ce qui est constructor/copy/move, je te préviens, tout aura lieu en double par contre, pour moi ya deux façons de remonter de X à Base"

D et Swift ont un GC, par défaut pour D (mais aux dernières nouvelles en nogc tu perd 90% de l'écosystème) et `class` est refcounté en swift. Ils sont en train d'ajouter un système d'ownership/borrowing ad-hoc pour qu'il fonctionne mieux à plus bas niveau (et vont probablement continuer à pas fournir de support hors macos donc dans tous les cas osef).
 
Et faut bien reconnaitre que le GC c'est pratique, à partir du moment où tu dois gérer tous les cycles de toutes tes structures tu vas y perdre.
 
Tu peux essayer de regarder du côté de Vale et Hylo (anciennement Val). Les deux sont super jeunes mais IIRC ils essaient de limiter la difficulté sans perdre sur la sécurité (trop, je sais pas ce qu'ils font côté concurrence). Après vu qu'ils sont super jeunes tu peux vraiment t'impliquer si t'es le second contributeur

Tu les jettes pas assez loin donc c'est plus l'inverse
 

Des donuts gratuits c'est pas un brise coeur

De loin, Swift me semble quand même super mal positionné pour avoir un quelconque impact dans ce domaine.
Rust n'est pas parfait mais gagne sans conteste dans à peu près toutes les dimensions, à part évidemment le dev iOS/macOS.
 
Je trouve d'ailleurs bizarre qu'Apple ait engagé plusieurs contributeurs venant de Netty, Akka et compagnie, pour bosser sur le côté serveur avec SwiftNIO et les acteurs par exemple.
Alors qu'il y a zéro stratégie évidente ou même un quelconque effort marketing, et de ce que je sais même pas tellement de dogfooding.

En même temps le devrel ça a jamais été le truc d'apple, le seul moment où ils en font c'est pendant WWDC, si t'es sur place, et encore.

Ça continue à monter petit à petit: https://blog.timac.org/2021/1219-st [...] tui-ios15/
 
Après ils vont clairement pas aller réécrire des applications pour le plaisir, et swift est pas vraiment adapté pour les core libraries ou l'OS.

Je parlais côté serveur. Car typiquement les acteurs ça va intéresser qui d'autre?
 
Les gens que je connais qui bossent sur des services chez Apple font du Java, Kotlin, Scala, Go.

OK tu parles d'un truc qui existe plus ou moins pas et dont clairement Apple a pas grand chose à foutre.
 

Les devs d'applications
 
Le moindre smartphone a 4 coeurs et ça fait qu'empirer, les dispatch queues restent touchy (sans parler des trucs plus bas niveau), et debugger des problèmes de concurrence on-device c'est encore plus la merde que sur un serveur ou tu peux mettre toute la télémétrie que tu veux. Les acteurs c'est un super bon package pour de la concurrence, et si swiftui (ou autre) commence à intégrer les acteurs directement ça augmente le niveau de concurrence tout en la rendant beaucoup plus claire.

Ça me semble peu surprenant. Apple a plus ou moins jamais fait de l'objc sur le serveur non plus. Et il y a pas grand rapport ou commonalité entre les gens qui bossent sur des services et les gens qui bossent sur les apps.

More trouble for Boeing: Tests of its troubled 777X paused after it found structural problems

C'est "Jeter des donuts", pas "te jeter des donuts"    
Et oui on est tous persuadé que ton budget bouffe doit être super contraint

Tant que c’est à portée

Waste not want not

Oui oui c'est cela

Ils paient quand même des gens qui développent un semblant d'écosystème.
https://github.com/swift-server/
https://github.com/apple/swift-openapi-generator
etc.

Donc je trouve le message un peu bizarre.

Alors je parle pas trop à cette communauté, mais lorsque la décision a été prise, si Apple avait proposé :
- Async await + acteurs
- Fibres sur une runtime à la Go / Java Loom

Permet moi de douter très fortement que le dev iOS moyen préfère l'ergonomie de la première solution.

Swift c'est justement pas Rust, donc les contraintes qui ont fait que Rust a abandonné les green threads me semblent pas forcément très pertinentes ici.

C'est peu surprenant mais ça reste marrant qu'on entende parler de Swift côté serveur chez d'autres boîtes (je vais pas compter IBM mais y a Amazon Prime Video et Paramount+ il me semble) et très peu du dogfooding interne (alors qu'il y en a, apparemment).

À deux doigts de réaliser qu’historiquement Apple s’en fout du monde serveur et que c’est la priorité 453

Au fait, y'a une date arrêtée pour la ki ?

C'était ce WE, on a bien rigolé.

Je pense que tu veux parler des langages à typage statique (compilés). Le typage statique a toujours été et sera probablement toujours plus contraignant que le typage dynamique, c'est une raison importante qui fait qu'ils sont "safe".
 
Rust est celui qui a le plus le vent en poupe en ce moment, mais il atteint maintenant un niveau de complexité syntaxique comparable aux templates du C++, si on combine les lifetimes, async et les macros (il n'a pas toutes les undefined behaviours et autres mauvaises surprises du C++, quand même). Et apparemment, si on utilise unsafe, c'est rapidement assez pourri.
 
Le D est toujours bien cool et a un bon équilibre entre expressivité, complexité et sûreté. Mais comme tu dis, il n'a jamais réussi à attirer les faveurs de la populace à cause de son GC (pourtant débrayable dans une certaine mesure).
 
Swift, je ne connais pas du tout, mais j'en ai entendu de bons échos. Le langage a bien évolué, dans le bon sens, mais la perception est qu'il est cantonné au monde Apple (je ne sais pas dans quelle mesure c'est exact ou non).
 
zig est encore jeune et vert, mais c'est le successeur du C qui me paraît le plus mature ou qui a le plus d'avenir. Tel quel, pour peu que le compilateur existe sur la puce cible, je ne vois à peu près aucune raison d'utiliser le C à la place de zig, du moins pour un nouveau projet. C'est un langage qui est aussi proche du métal que le C, qui génère des binaires aussi légers, est aussi économe en mémoire, tout en apportant une pléthore de facilités syntaxiques très bienvenues, mais qui n'ajoutent pas de surcoût au runtime. Les perfs sont au coude à coude avec le Rust. Ce dernier permet plus d'abstractions que zig, zig étant extrêmement limité coté abstraction (il n'y a même pas d'interface). Cela veut dire que pour un projet un peu conséquent, l'architecture devra être pensée sérieusement si on ne veut pas très vite tomber dans un gros tas de bouse indémerdable. Mais il permet plus de libertés que Rust, et la courbe d'apprentissage, si on a déjà fait un peu de C, est très accessible.
 
Il y a une petite poignée d'autres prétendants au titre de successeur du C, en particulier Odin qui a une syntaxe plus inspirée de Python, et C3 qui du peu que j'en ai vu n'apporte rien que zig ne fait déjà.

Tu as oublié Gleam (niveau hype).

J'en entendu parler de ce langage dans cette vidéo.https://www.youtube.com/watch?v=-MbTj8DGOP0
Puis je ne m'y suis pas intéressé plus que ça.

Il y a aussi Elixir et Mojo.

Non c’est bien l’absence de GC qui fait la différence: à partir du moment où tu dois traiter la mémoire comme une resource, dans le programme moyen ça multiplie le nombre de resources par 10 ou par 100, et chaque resource est un objet dont tu dois gérer le cycle de vie.

Elixir c’est sans rapport avec la discussion, c’est une syntaxe à la Ruby par dessus Erlang (ça tourne exclusivement sur beam).

La gestion de la mémoire manuelle n'est pas un problème aussi intractable que ce que l'on veut bien faire croire. Il faut juste être un peu rigoureux, mais c'est loin d'être ce qu'il y a de plus difficile à mon avis. Arriver à faire des abstractions complexes avec des langages statiques, je trouve ça bien plus prise de tête.

Ben Gleam c'est pareil, c'est sur une VM Erlang.

Comme la mécanique quantique il suffit juste de poser les équations de façon rigoureuse et faire des maths, c’est pas bien compliqué

En C++, les destructeurs et le RAII ont aidé quand même pas mal, même si on sait bien que ça ne résoud pas tout.
 
En C, si tu n'utilises pas valgrind, c'est simple, t'es mort. Tu passes tes tests, tout fonctionne impec, puis tu les repasses avec valgrind, et là il te détecte douze écrasements mémoire, et 2 fuites.

Le dev a l'air sympa mais je vois pas trop ce que le langage apporte par rapport à OCaml ou F# par exemple.
Beam me semble pas vraiment être un argument-massue.

Dans les langages récents finalement y en a pas tant que ça qui explorent des approches vraiment nouvelles: Unison est vraiment à part, Koka et Roc dans une moindre mesure, Flix sur la JVM.

Le weekend du 7 septembre chez moi
Il y a de la place pour des tentes, sinon j'ai des matelas gonflables et canapés

 
Il y a des moustiques, la nuit ? Parce que je dormirais bien dehors.

ça reste la campagne. En ce moment il n'y en a pas trop, mais je ne peux pas savoir dans 3 semaines. Note que je n'a pas de tente. Mais on peut aussi mettre les matelas sous la pergolas

Ah mais si je peux dormir avec muchacho je ne prend pas de résa  

Dites, ça vous dit quelque chose un fichier "windows_dump.xml" stocké à la racine des répertoires d'une smartphone Samsung ?
Y'a aussi un répertoire ".face". Mon père me demande ce que c'est. Merci.

https://chatgpt.com/share/de672303- [...] 807db01fa8