❌

Vue normale

Reçu — 2 novembre 2026 ⏭ Communaute francophone

Découverte du langage Elixir

2 novembre 2026 à 09:41

Beaucoup de Rust par-ci… Un peu de Go par-là… Saupoudrez de LLM selon vos goûts et vous aurez une bonne photographie des sujets qui préoccupent les développeurs sur l'Internet d'aujourd'hui.
Alors, n'est-ce pas le meilleur moment pour se rafraîchir l'esprit avec des langages plus discrets ?
Je vous propose ici une présentation accélérée d'Elixir.

Sommaire

Un langage de programmation fonctionnelle

Ceux qui ont déjà fait de la programmation orientée objet organisent principalement leur code autour d'objets et d'instances. Cette approche a ses avantages, mais cela nécessite d'encapsuler la donnée et la gestion des changements d'état peut parfois devenir complexe.
De son côté, la programmation fonctionnelle privilégie les fonctions qui, au lieu de masquer les données, transforment simplement des entrées en sorties.
Elixir s'appuie essentiellement sur ce paradigme.

Correspondance de motifs (ou Pattern matching)

En Elixir, le signe égal n'est pas une affectation mais plutôt une assertion.
Ainsi, on n'affecte ou ne modifie la valeur que de la variable située à gauche du signe égal. À droite, la variable est remplacée par sa valeur. Exemple avec iex, la console interactive :

iex> a = 2
2
iex> 2 = a
2
iex> 1 = a
** (MatchError) no match of right hand side value: 2

Cette ligne de code échoue car elle équivaut à 1 = 2, ce qui provoque une erreur.
À noter que le caractère _ sert à ignorer une valeur, ainsi :

iex> [1, _, _] = [1, 2, 3]
[1, 2, 3]

La correspondance de motifs en Elixir est similaire à celle d'Erlang (ces deux langages utilisent la même VM).
Joe Armstrong, le créateur d'Erlang, compare ce signe égal à celui utilisé en algèbre : lorsque vous écrivez l'équation x = a + 1, vous n'attribuez pas la valeur de a + 1 à x.
Cette correspondance sert essentiellement à vérifier la forme d'une valeur, à en extraire des éléments et à traiter différemment les résultats d'une opération selon qu'elle réussit ou échoue.
Tout cela est un peu déroutant au début mais très puissant.

Module, fonctions et clauses de garde

Dès qu'un programme dépasse quelques lignes, il devient nécessaire de le structurer.
En Elixir, les fonctions nommées doivent être écrites à l'intérieur de modules :

defmodule BestMovie do
  def ever(name) do
    IO.puts "Le meilleur film de tous les temps est `#{name}`."
  end
end
BestMovie.ever("La cité de la peur") #=> Le meilleur film de tous les temps est `La cité de la peur`.

De son côté, la macro defp définit une fonction privée, c'est-à-dire une fonction qui ne peut être appelée qu'au sein du module qui la déclare :

defmodule MonModule do
  def fonction_publique do
    fonction_privée()
  end

  defp fonction_privée do
    IO.puts "Je suis appelé depuis une fonction privée"
  end
end
MonModule.fonction_privée()   #=> ** (UndefinedFunctionError) function MonModule.fonction_privée/0 is undefined or private.
MonModule.fonction_publique() #=> Je suis appelé depuis une fonction privée

En Elixir, la correspondance de motifs s'applique aux arguments des fonctions : plusieurs peuvent porter le même nom mais le langage choisira la fonction dont les motifs correspondent aux arguments.
Au moyen du mot clé when, les clauses de garde permettent d'étendre cette correspondance de motifs à des vérifications plus complexes comme la distinction des types d'arguments ou un test portant sur leurs valeurs :

defmodule GuardClause do
  def what_is(x) when is_number(x) and x > 0 do
    IO.puts "#{x} est un nombre positif"
  end

  def what_is(x) when is_list(x) do
    IO.puts "#{inspect(x)} est une liste"
  end
end
GuardClause.what_is(99)      #=> 99 est un nombre positif
GuardClause.what_is([1,2,3]) #=> [1,2,3] est une liste

Toutes les expressions ne sont pas autorisées dans les clauses de garde, mais seulement quelques-unes.
Il s'agit d'un choix délibéré du langage pour garantir une exécution efficace.

Listes et récursivité

En Elixir, une liste peut être vide ou se composer d'une tête et d'une queue. La tête (head) contient une valeur et la queue (tail) est elle-même une liste :

iex> [ head | tail ] = [ 1, 2, 3 ]
[1, 2, 3]
iex> head
1
iex> tail
[2, 3]

Ainsi, une liste à un seul élément (que nous écririons habituellement sous la forme [4]) peut s'écrire comme la valeur 4 jointe à une liste vide, soit [ 4 | [ ] ].
Cette définition permet d'aborder certains problèmes de manière récursifs et donc sans s'appuyer sur une variable de boucle et/ou les traditionnels if et else :

defmodule MyList do
  def flip([]), do: []
  def flip([ head | tail ]) do
    flip(tail) ++ [head] # `++` permet de concaténer des listes
  end
end
MyList.flip([1, 2, 3, 4, 5]) #=> [5, 4, 3, 2, 1]
# Explication pas à pas :
#   flip([1, 2, 3, 4, 5])
#     ↳ flip([2, 3, 4, 5]) ++ [1]
#         ↳ flip([3, 4, 5]) ++ [2] ++ [1]
#             ↳ flip([4, 5]) ++ [3] ++ [2] ++ [1]
#                 ↳ flip([5]) ++ [4] ++ [3] ++ [2] ++ [1]
#                     ↳ flip([]) ++ [5] ++ [4] ++ [3] ++ [2] ++ [1]
#                         ↳ [] ++ [5] ++ [4] ++ [3] ++ [2] ++ [1]
#                             ↳ [5, 4, 3, 2, 1]

Note : l'usage de ++ est moins efficace qu'une version utilisant une variable pour accumuler le résultat mais cette approche reste plus didactique pour découvrir la récursion.

L'opérateur pipe

Nous avons tous déjà croisé du code séquentiel où chaque étape dépend du résultat de la précédente :

  cart = ShoppingCart.for_user(user_id)
  items = Inventory.check_availability(cart)
  total = Pricing.calculate_total(items, tax: 1.2)

L'ordre des opérations est clair, mais au final les variables intermédiaires sont là pour éviter des appels imbriqués :

Pricing.calculate_total(
  Inventory.check_availability(
    ShoppingCart.for_user(user_id)
  ),
  tax: 1.2
)

Elixir propose d'écrire ce type de code d'une façon fluide et sans variable intermédiaire :

user_id
|> ShoppingCart.for_user()
|> Inventory.check_availability()
|> Pricing.calculate_total(tax: 1.2)

L'opérateur |> prend le résultat de l'expression située précédemment et l'insère en tant que premier paramètre de l'appel de la fonction suivante.

L'exercice sympa qui utilise tout ça (ou presque)

Maintenant que vous avez les bases, je vous propose un exercice qui m'avait bien plu lorsque j'ai découvert le langage au travers le livre de Dave Thomas : trouver un nombre compris dans un intervalle donné (ex : 1..100 dans une expression ou 1..100//1 pour effectuer une correspondance de motifs, //1 correspondant au pas).
Il existe plusieurs façon de résoudre le problème mais voici ma solution :

defmodule Devine do
  def en_tatonnant(cible, min..max//1) when is_integer(cible) and is_integer(min) and is_integer(max) and cible > min and cible < max do
    estimation = div(min + max, 2)
    IO.puts "Est-ce #{estimation} ?"
    guess(cible, min..max, estimation)
  end
  def en_tatonnant(cible, min..max//1) when not is_integer(cible) or not is_integer(min) or not is_integer(max) or cible < min or cible > max do
    IO.puts "Très drôle…"
  end
  defp guess(cible, min.._//1, estimation) when estimation > cible do
    IO.puts "Non, c'est plus petit… Maintenant on va rechercher entre #{min} et #{estimation}"
    en_tatonnant(cible, min..estimation)
  end
  defp guess(cible, _..max//1, estimation) when estimation < cible do
    IO.puts "Non, c'est plus grand… Maintenant on va rechercher entre #{estimation} et #{max}"
    en_tatonnant(cible, estimation..max)
  end
  defp guess(cible, _, estimation) when estimation == cible do
    IO.puts "Mais oui, c'est bien #{estimation} 🤩"
  end
end
Devine.en_tatonnant(273, 1..1000)
#=> Est-ce 500 ?
#=> Non, c'est plus petit… Maintenant on va rechercher entre 1 et 500
#=> Est-ce 250 ?
#=> Non, c'est plus grand… Maintenant on va rechercher entre 250 et 500
#=> Est-ce 375 ?
#=> Non, c'est plus petit… Maintenant on va rechercher entre 250 et 375
#=> Est-ce 312 ?
#=> Non, c'est plus petit… Maintenant on va rechercher entre 250 et 312
#=> Est-ce 281 ?
#=> Non, c'est plus petit… Maintenant on va rechercher entre 250 et 281
#=> Est-ce 265 ?
#=> Non, c'est plus grand… Maintenant on va rechercher entre 265 et 281
#=> Est-ce 273 ?
#=> Mais oui, c'est bien 273 🤩

Et maintenant

Vous vous doutez bien que je n'ai fait qu'effleurer le sujet mais j'ai trouvé le langage Elixir tellement singulier que je n'ai pas résisté à l'envie de vous le présenter.
Je continue ma découverte de ce langage, à mon rythme ; en ce moment, j'aborde la programmation concurrente.
À n'en pas douter, j'enchaînerai sur le framework Phoenix !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Reçu — 30 octobre 2026 ⏭ Communaute francophone

Hadron, le futur de macOS court-circuite tout macOS

30 octobre 2026 à 14:56

Un hadron est une particule composite, composée de particules subatomiques régies par l'interaction forte, nous dit Wikipédia. Si cela vous fait penser à Proton, ce n’est peut-être pas parce qu’un proton est un hadron, mais parce que Hadron, comme Proton, promet de faire tourner vos jeux (et plus) n’importe où, même sur des systèmes terreux.

Logo Hadron

Vous connaissez peut-être Proton, l’assemblage de Wine et d’autres composants libres que Valve emploie pour faire tourner des jeux Windows sous Linux pour sa plate-forme Steam. Hadron propose la même chose pour macOS.

Des jeux Windows ? Sous macOS ? Quel est le 🌀️💀️⚡️⁉️ de rapport avec LinuxFr.org et son objectif de promotion des logiciels libres ? C’est parce que Hadron est construit de briques libres du sol au plafond : Wine, FEX, Mesa, vkd3d…

Sommaire

7zFM sur macOS et Apple Silicon grâce à HadronLe logiciel libre 7zFM pour Windows x86-64 s‘exécutant sur un Mac mini M1 sous macOS 27 sans utiliser Rosetta 2.

Le développement de Hadron est encore très jeune, confidentiel, mais très rapide et réactif. Votre serviteur a testé de faire tourner le jeu libre Unvanquished et a rencontré deux bugs (1, 2) qui ont tous deux été corrigés dans les deux jours (1, 2), et une nouvelle version incorporant les correctifs a été publiée sous cinq jours (1).

Les spéculations sur « qui est derrière Hadron » pourraient se tourner naturellement vers Valve, qui est le premier bénéficiaire économique d’un tel système, mais le README du projet Hadron est explicite : « It is unofficial. Hadron is not affiliated with or endorsed by Valve, Apple, CodeWeavers or any of the projects it builds on », « C’est un projet non officiel. Hadron n’est ni affilié à, ni approuvé par Valve, Apple, CodeWeavers ou l’un des projets sur lesquels il s’appuie ».

Il semble donc que Hadron soit simplement l’initiative de son auteur David Andrews (Broyojo), ni plus ni moins.

Au delà de la proximité de nom entre Hadron et Proton, Hadron reste délibérément focalisé sur Steam : la fenêtre qui s’affiche quand vous lancez Hadron ne sert qu’à intégrer Hadron à Steam, et les premières versions ne proposaient d’ailleurs pas d’option pour lancer un programme non-Steam (fonctionnalité ajoutée très rapidement en quelques jours aussi). Le but premier de Hadron est Steam, et quand vous rapportez un bug pour un jeu, il vous est demandé l’identifiant Steam de ce jeu (cet identifiant est heureusement optionnel).

Pourquoi Hadron ?

En 2027, Apple sortira macOS 28 et à cette occasion, a prévu de drastiquement réduire l’étendue de la compatibilité Rosetta 2. Rosetta 2 est le système de traduction automatique qui permet de faire tourner des binaires amd64 (x86-64) sur arm64 (Apple Silicon ici, dans les macs « M »). Rosetta 2 a un 2 parce que Rosetta premier du nom s’occupait de traduire les binaires PowerPC vers Intel il y a très longtemps. Par commodité nous dirons simplement Rosetta au lieu de Rosetta 2 dans la suite de l’article.

Apple a annoncé que Rosetta ne sera plus disponible pour les applications, mais qu’ils conserveront une petite sous-partie prévue uniquement pour faire tourner des vieux jeux non maintenus s'appuyant sur des bibliothèques pour Intel (« we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks » (source). C’est une affirmation super floue. Que restera-t-il de Rosetta ? Sur quoi pourra-t-on compter et ne pas compter ?

Pour Apple, décommissionner Rosetta a un intérêt : ne plus fournir toutes les bibliothèques systèmes en double, ne plus avoir à apporter de la maintenance et du code système pour l’architecture amd64, etc. Tout l’effort de migration vers arm64 est entièrement externalisé vers le développeur indépendant. Ça coûte très cher à l’échelle globale, mais rien du tout pour Apple, et leur clientèle est suffisamment captive pour que le développeur au milieu y soit contraint. Si un développeur échoue à porter son logiciel, le développeur perdra des ventes, mais pas nécessairement Apple. Ce n’est pas le problème d’Apple, surtout quand l’acquisition du logiciel a lieu probablement en dehors de leur marché. Ceci est d’autant plus vrai en dehors du jeu : un logiciel de production concurrent remplace facilement un autre s’il venait à disparaître.

Pour un consommateur de jeu, c’est insupportable : il ne veut pas perdre son jeu parce que le développeur ne le développe plus. Il y a un attachement affectif, le joueur y a investi une partie de sa vie, il peut être attaché à l’histoire, etc. Et si le jeu est encore développé, le joueur ne trouve pas d’intérêt à ce que le développeur se retrouve avec plus de travail qui ne lui apportera aucun changement en jeu. Rajouter gratuitement du travail au développeur de jeu n’apporte rien au joueur.

Et pour une plate-forme tierce de vente et de location de logiciels comme Steam et autre GOG GALAXY, c’est une catastrophe : si un développeur échoue à porter son logiciel, ou n’est plus disponible pour cette tâche, ce sont des ventes en moins pour le développeur et pour le vendeur. Un vendeur de jeux qui prend sa commission à chaque vente (et dont ce serait la première sinon la seule activité économique) a intérêt à ce que le moindre effort soit proposé aux développeurs de jeux.

L’architecture de Hadron

Ne pas confondre avec le Grand collisionneur de hadrons ! L’architecture de Hadron est très différente, mais fait aussi se rencontrer plein de particules élémentaires libres pour observer des effets très intéressants.

Diagramme de l’architecture de Hadron Diagramme de l’architecture de Hadron, telle que décrite dans la documentation du projet.

FEX, le traducteur automatique d’instruction processeur

Comme alternative à Rosetta pour traduire les instructions amd64 vers arm64 pour exécuter des logiciels, il existe au moins deux logiciels libres : FEX (dont le développement était initialement secrètement soutenu par Valve), et Box64 développé par notre ptitSeb national.

Ces deux logiciels libres ont été à la base développés pour s’exécuter sous Linux. Hadron a choisi FEX et le fait tourner sous macOS. Ainsi, plus besoin de compter sur Rosetta et d’être dépendant du bon-vouloir d’Apple !

Le choix de FEX correspond bien à l’écosystème de Valve : l’intégration de FEX peut prendre exemple sur celle déjà réalisée pour Steam sur le Steam Frame (un produit de réalité virtuelle tournant sous Linux et sur ARM), et permet d’hériter des tests déjà réalisés par Valve pour le Steam Frame.

En intégrant FEX, Hadron rend les jeux et autres logiciels indépendants de la volonté d’Apple d’abandonner la prise en charge de l’architecture x86.

Wine, l’implémentation libre des API Windows

On ne présente plus Wine, le logiciel libre qui permet de faire tourner depuis des décennies des programmes Windows sous Linux, BSD et macOS. En 2022 Arek Hiler avait prononcé la désormais célèbre phrase Win32 Is The Only Stable ABI on Linux, Win32 est la seule interface binaire de programmation qui soit stable sous Linux. Ce constat de l’ABI Win32 comme une interface très stable s’étend en fait bien au-delà des utilisateurs de Linux.

Wine est une brique fondamentale de Proton, la sous-couche de Valve pour faire tourner des jeux Windows sous Linux. Hadron fait de même pour macOS.

Hadron intègre donc FEX et Wine pour faire tourner des programmes Windows compilés pour x86 (32-bit et 64-bit) sur les macs exécutant macOS sur des processeurs ARM. L’héritage Wintel ne s’effacera donc jamais.

En intégrant Wine, Hadron rend les jeux et autres logiciels indépendants des interfaces de programmation de macOS.

Mesa, Zink et KosmicKrisp

Mesa est la collection de pilotes graphiques libres qui domine nos écosystèmes Linux et BSD. Mais Mesa propose aussi des pilotes pour d’autres plate-formes, comme Windows et macOS.

L’article Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ? posait ce constat en répondant à la question « Et pour Vulkan sur macOS ? » :

En participant au développement de RADV sous Linux et Windows, Valve se donne le pouvoir de contrôler la qualité de la pile logicielle d’exécution des jeux qu’ils vendent, jusqu’au pilote graphique inclus.

Pour macOS, la solution n’est pas à voir du côté de RADV (les derniers macs n’ont plus de cartes graphiques AMD de toute façon), mais du côté de MolktenVK et KosmicKrisp, des pilotes libres convertissant les appels Vulkan vers l’API Metal de macOS.

Sur macOS Vulkan est déjà disponible grâce à MoltenVK, une implémentation libre traduisant Vulkan pour l’API propriétaire Metal de macOS. Valve a investi dans MoltenVK. Cela permet par exemple à Valve de faire tourner leur jeu Dota2 sur macOS et pouvoir continuer à le vendre aux utilisateurs de macOS sans se soucier de l’obsolétisation d’OpenGL sur macOS par Apple.

KosmicKrisp est lui un pilote Mesa qui fait de même (convertir Vulkan vers Metal) mais de façon intimement spécialisée pour les puces AGX que l’on trouve dans les ordinateurs Apple M1, M2, etc. (aussi appelé « Apple Silicon »).

Et vous le voyez venir en mille, Hadron intègre KosmicKrisp pour fournir la prise en charge de l’API graphique Vulkan. KosmicKrisp traduit les appels Vulkan vers l’Interface de programmation (API) propriétaire Metal.

En intégrant KosmicKrisp, Hadron rend les jeux et autres logiciels indépendants de la politique d’Apple refusant de prendre en charge le standard industriel Vulkan.

Mais, et pour OpenGL ? Zink est un pilote Mesa qui implémente OpenGL au dessus de Vulkan, quel que soit le système (Zink tourne déjà sous Linux et Windows, et donc aussi macOS comme on peut le voir). Voilà, problème résolu.

En fait macOS fournit déjà OpenGL, mais ils l’ont déclaré obsolète depuis longtemps et ne fournissent qu’une ancienne version 4.1 qui date de 2010 (16 ans déjà !) qui est 7 ans plus ancienne que la dernière version d’OpenGL (4.6).

Zink implémente donc OpenGL 4.6 et en intégrant Zink, Hadron rend les jeux et autres logiciels indépendant de la volonté d’Apple d’abandonner OpenGL.

Et au passage, Zink propose la dernière version d’OpenGL et est un pilote désormais bien connu des développeurs de jeu, c’est tout bénef !

Hadron a comme politique de favoriser Zink à la place de l’implémentation OpenGL maison d’Apple. Quand un des bugs donnés comme exemple et affectant Unvanquished a été rapporté, l’expérimentation avait été réalisée avant que Hadron ne propose un moyen simple de lancer un logiciel en dehors de Steam, et donc l’expérimentation avait été faite en appelant Wine directement sans passer par le lanceur de Hadron. Le développeur Broyojo a constaté en lisant le journal du moteur de jeu Dæmon que dans ces circonstances, le jeu utilisait l’implémentation OpenGL d’Apple, chose qu’il s’est empressé de corriger fissa. Et pour le coup, ce changement est ce qui a corrigé le bug, trop facile.

L’article sur RADV et Windows indiquait :

Pour un distributeur de jeu vidéo comme Valve c’est excellent : ça signifie que — si nécessaire — le jeu peut être distribué avec RADV sur Windows et Linux pour les utilisateurs de cartes graphiques AMD, et MoltenVK ou KosmicKrisp sur macOS afin de fournir une expérience Vulkan finement contrôlée, et autres combinaisons sus-mentionnées. Cela permet de contrôler et donc d’assurer au maximum la compatibilité d’un jeu.

Nous y sommes. À part que cette fois-ci, ce n’est pas Valve qui en aurait eu l’initiative.

vkd3d-proton, DirectX 12 sur KosmicKrisp

Là où Zink implémente OpenGL sur Vulkan, vkd3d-proton fait de même et implémente DirectX 12 sur Vulkan, lui-même implémenté par KosmicKrisp.

DirectX 12 est l’interface de programmation graphique propriétaire de Microsoft pour Windows, elle est similaire à Metal et Vulkan.

Un développeur de jeu libre n’en a pas besoin : il peut utiliser OpenGL ou Vulkan, mais de très nombreux jeux utilisent Direct X 12, et Hadron s’assure donc de fournir cette prise en charge.

Comme son nom l’indique, vkd3d-proton est une brique essentielle de Proton, et l’est aussi maintenant pour Hadron.

mtld3d et DXMT, les plus anciens Direct3D sur Metal

Vous connaissez peut-être le logiciel DXVK qui implémentent Direct3D 8, 9, 10 et 11 au dessus de Vulkan. Vous aviez peut-être entendu parlé de D9VK qui faisait de même pour D3D9 mais qui est désormais intégré à DXVK, ou WineD3D qui implémentait Direct3D 8, 9, 10 et 11 au dessus de OpenGL.

Proton utilise DXVK sous Linux, implémentant donc D3D sur Vulkan, et Hadron pourrait faire de même, à la façon dont c’est effectivement implémenté avec vkd3d-proton.

Mais il existe deux logiciels qui implémentent D3D sur l’API Metal directement, ce qui permet de supprimer une couche intermédiaire de traduction.

Ces deux logiciels libres sont mtld3d qui implémente D3D9 sur Metal, et dxmt qui implémente D3D10 et D3D11 sur Metal.

Pour D3D8, Hadron ne précise pas si quelque chose est prévu, mais il devrait être possible d’utiliser DXVK, ou encore d3d8to9 qui implémente D3D8 sur D3D9. Et on peut supposer que rien ne devrait techniquement empêcher d’utiliser dd7to9 et autres projets de ce type (voir dxwrapper pour plus de détails).

Win32 + Vulkan + AMD64, la plate-forme universelle ?

Pour un développeur de logiciel libre, ces APIs DirectX sont peu utiles, mais tout le reste de cet écosystème peut profiter aux développeurs de logiciels libres.

Les compilateurs libres du projet MinGW permettent de compiler pour Win32. Wine permet de faire tourner ces programmes Win32 ailleurs que sur Windows. Et en s’appuyant sur les API graphiques OpenGL ou Vulkan, et des bibliothèques comme OpenAL ou SDL pour le son, le fenêtrage et les entrées, un développeur de jeu libre peut donc produire un seul binaire entièrement libre de la tête aux pieds qui tourne partout, sous Linux, BSD, macOS ou Windows.

Alors bien évidemment, certains préféreront un programme natif à leur système, avec de bonnes raisons. Mais quand un lanceur comme Steam ou une alternative libre comme Lutris fait toute l’intégration pour vous, tout ce qui retient se réduit à un attachement affectif (et ça compte beaucoup). C’est un chagrin légitime mais il n’empêche pas de jouer.

Wine fait déjà tourner naturellement les programmes x86 sur Linux et autres BSD. FEX peut être associé à Wine pour faire tourner des programmes Windows x86 sous Linux et macOS sur les processeurs ARM. Et Box64 sait faire de même sous Linux, non-seulement sur ARM64, mais aussi sur PowerPC (en mode petit-boutiste), RISC-V et Loongson.

Certains ont pu déclarer que « AMD64 is the new Java », en réalité, c’est peut-être la triforce Win32 + Vulkan + AMD64 qui est ce nouveau Java. Vous ferez peut-être autant la grimace, mais ça ne marche pas moins.

Et avec Hadron, votre prochain environnement de développement pour macOS pourrait simplement être MinGW, trop bien !

Avec Hadron, le futur de macOS court-circuite tout macOS, et Apple ne peut rien y faire.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Reçu — 29 octobre 2026 ⏭ Communaute francophone
Reçu — 26 octobre 2026 ⏭ Communaute francophone
Reçu — 17 octobre 2026 ⏭ Communaute francophone
❌