Ruby on Rails-oprichter vibecodet zijn eigen software om naar 'vreselijk' Rust

De bedenker van Ruby on Rails gaat zijn belangrijkste softwarepakket, mailclient Hey, ombouwen naar Rust. David Heinemeier Hansson wil zijn software vooral nog vibecoden en dat kan beter in Rust, zegt hij uitgerekend op een Ruby on Rails-conferentie.

Heinemeier Hansson, beter bekend als DHH, zegt dat in een wat verwarrende keynote tijdens Rails World 2026. Dat is een grote conferentie voor Ruby on Rails-ontwikkelaars. DHH is daar een grote naam, want hij is de hoofdontwikkelaar van Ruby on Rails.

DHH pleit er in de keynote voor om niet of nauwelijks meer zelf te programmeren. Hij zet volledig in op AI-gegenereerde code en hij laat dat vooral zien in Hey. Dat is een populaire e-mailclient die DHH ontwikkelt. Uiteraard was Hey altijd een Ruby-applicatie, maar daar komt nu een einde aan. Hey wordt voortaan in Rust gebouwd.

Rust maakt het makkelijker de dienst als native clients aan te bieden op verschillende besturingssystemen, in plaats van als webapps. Niet alleen de frontend wordt in Rust geschreven, maar ook de backend. DHH zegt overigens zelf een hekel te hebben aan Rust. Hij vindt het een lelijke, slecht gestructureerde programmeertaal. "Maar Rust is FAN-TAS-TISCH als je er nooit naar hoeft te kijken!" roept hij tijdens de keynote.

Tijdens de keynote vertelt DHH hoe alle programmeurs bij Hey en bij andere software zoals Basecamp, inmiddels volledig met AI-agents werken. "Agents die werken met Rust? Geweldig! Dan hoef ik er nooit naar om te kijken", zegt hij.

De uitspraken zijn saillant, maar niet helemaal onverwacht. DHH is lang geleden al vol op de AI-trein gesprongen. Hij maakt inmiddels Omarchy Linux, een op Arch gebaseerde distro die voornamelijk op AI-gebruikers is gericht. Veel van de code daarvoor wordt door AI-agents gemaakt.

Reacties (32)

[Wokker]

De core van Copilot is onlangs ook omgeschreven naar Rust. Hier is vrij uitgebreid geschreven hoe ze dat hebben gedaan en waarom Rust (of eigenlijk elk statiisch getyped taal) daar zo geschikt was.

https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/

The four largest diagnostic families cover 84%:

37%: Name and import resolution, dominated by E0425 (“cannot find value in this scope”)

22%: Missing methods or fields

14%: Type mismatches

11%: Unsatisfied trait bounds

But note what’s absent from that list: anything truly specific to Rust. Every one of those four categories is bread-and-butter static typing, and a C# or Java or Go compiler would catch all of them just as well, several of them with friendlier diagnostics, and all of them a great deal faster. If this is the argument for pointing agents at Rust, it’s really an argument for pointing them at any statically typed language.

[Reactie gewijzigd door Wokker op 26 september 2026 12:09]

[yPop]

Waarom werkt Rust zo goed met ai?

[Scribe]

Als ik een gokje zou moeten doen is het omdat het juist een heel overzichtelijke en gestructueerde taal is. En de compiler vangt heel veel dingen op dus veel bugs kun je al op compile time registreren

[MehHuntah]

omdat rust veel fouten al op compiler niveau oplost die normaal op runtime optreden, en heel duidelijke foutmeldingen geeft wat je fout doet.. Dus als het compileert werkt het (technisch) ook gewoon gelijk.. (of het functioneel werkt hangt af van je model en van de kwaliteit van je prompts/plan spec).

[graey]

De feedbackloop is met de rust compiler gewoon heel effectief. De compiler zegt niet alleen "computer says no" maar ook waarom, redelijk uitgebreid. Dat geldt niet voor elke taal, al is dat vaak op te lossen met wat extra tools. Rust is heel strikt, en doordat het ook uitlegt wat niet geaccepteerd wordt kan een AI agent daarop itereren tot het in ieder geval valide code is. Als je overkoepelende ontwerp/idee dan ook klopt, kun je best ver komen.

[xfj]

Het is meer dat Rust veel voordelen biedt, maar daarvoor meer tijd kost om in te schrijven. Nu is tijd niet meer het probleem.

[Finder]

Omarchy is echt wel leuk om op een oude laptopt installeren en te gebruiken. Plezant ook hoe enthousiast DHH met dit onderwerp bezig is, interessante gast.

[Jerryy]

Wat je interessant noemt... https://jakelazaroff.com/words/dhh-is-way-worse-than-i-thought/

[MMaster23]

Interessante gast? Ja hij heeft "interessante" opvattingen over immigratie en minderheden. Lees zeker eens de link die @Jerryy hieronder post.

[MMaster23]

Waarom Tweakers nog steeds post over "DHH" verbaast mij nog steeds. Alleen al zijn naam zo afkorten geeft hem teveel aandacht naar mijn mening. Een vibecodende fascist is niet nieuwswaardig.

[bantoo]

Het is inderdaad een extreem irritant en aandachtsgeil persoon.

[TijsZonderH]

Meer mensen kennen hem onder die afkorting dan zijn normale naam, dus ik vind het niet gek dat te gebruiken. En verder: helemaal eens over hem persoonlijk. Maar hij is, like it or not, een invloedrijke figuur binnen de ontwikkelaarswereld en hij heeft veel relevants te melden over een belangrijke shift binnen die wereld. Dat negeren vanwege de persoon voelt ook vreemd. Beetje art van de artist scheiden.

[thomasv]

Eens, het probleem negeren gaat het probleem niet mee weg, en de cancel culture heeft ook geen zin want daarmee genieten ze alleen maar "infamy". Blij te zien dat art van artist scheiden op dit platform nog kan.

[PCR]

Qua ideologie sta ik ook verder van hem af. Maar vakinhoudelijk heeft hij een enorme invloed. En dat heeft hij ook gehad op mij. Mede dankzij hem heb ik een softwarebedrijf kunnen opbouwen met Ruby on Rails web apps. Zijn olifant-in-de-porseleinkast-gedrag zorgt ervoor dat er altijd gedonder rondom hem is. Ik hou daarvan en als hij wat te melden heeft dan let ik altijd even op. Maar ik snap heel goed dat mensen hem irritant vinden.

[Barsonax]

Zolang je snapt wat er gebeurt prima maar de vraag is in hoeverre dat op lange termijn in stand blijft als je niet meer naar de code kijkt. Op gegeven moment is die kennis weg en hoe ga je dan de agents aansturen?

[Triblade_8472]

Niet, dat is dus mijn grootste angst van AI.

Het wordt als een volwaardig mens gezien ipv een hulpmiddel gezien inzake specifieke taken als programmeren.

De huidige jeugd gaat alles vibecoden. Als AI ooit kapot gaat of te duur wordt dan kan niemand meer iets. Of nog veel erger: alle kennis en macht ligt bij de grootste Amerikaanse bedrijven. Dat ze dit (legaal) gejat hebben doet er dan ook niet meer toe.

[Exirion]

Ik maak me dan ook niet zo'n zorgen in de komende jaren overbodig te worden. Senioriteit in system engineering wordt steeds zeldzamer maar zeker niet overbodig. Het kloppen van code is maar een deel van het werk.

[CAPSLOCK2000]

De huidige jeugd gaat alles vibecoden. Als AI ooit kapot gaat of te duur wordt dan kan niemand meer iets. Of nog veel erger: alle kennis en macht ligt bij de grootste Amerikaanse bedrijven. Dat ze dit (legaal) gejat hebben doet er dan ook niet meer toe.

Ik denk dat vibecoden inderdaad de toekomst heeft en binnenkort bijna niemand het nog met de hand doet, net zoals handgeschreven asm is verdwenen en iedereen hogere talen gebruikt met een automatische compiler/interpreter. De voordelen van snel ontwikkelen zijn groter dan de nadelen van minder goede code. Moderne compilers zijn daarbij zo goed in optimalisatie geworden dat ze beter werk leveren dan de meeste programmeurs met de hand kunnen.

De afhankelijkheid van (buitenlandse) bedrijven is wel een probleem, al kun je ook dat zeggen over de afhankelijkheid van compilers van bv MS en Intel.

[Wolfos]

Moderne compilers zijn daarbij zo goed in optimalisatie geworden dat ze beter werk leveren dan de meeste programmeurs met de hand kunnen.

Ja, en nee. Micro-optimalisaties op assembly niveau zijn redelijk zeldzaam geworden, maar als je een compleet verkeerde aanpak hebt dan kost dat veel meer en daar kan een compiler niet voor behoeden.

Een compiler kan een loop sneller maken, jij kan er zelf voor zorgen dat die loop überhaupt niet meer bestaat.

[Killemov]

Er is iets vergelijkbaars aan de hand met COBOL ontwikkelaars maar dan voor het onderhouden van oude systemen. Als je COBOL kennis hebt dan kun je voor verschrikkelijk hoge uurtarieven gaan werken.

[closefuture]

Rust maakt het makkelijker de dienst als native clients aan te bieden op verschillende besturingssystemen, in plaats van als webapps.

Het maken van native apps was volgens mij nooit echt het grootste probleem. Het probleem is distributie van de applicaties. Dat is iets wat makkelijk is met een browser. Het verschil tussen in je browser naar "maps.google.com" gaan en het eerste moeten installeren van Google Earth. En hoe frictieloos je die applicatie installatie ook probeert te maken, het gaat nooit zo snel en frictieloos zijn als "maps.google.com" in typen in je browser.

EDIT: Beetje apart dat dit is "irrelevant" gemodeerd word. Voor context; Ik was iets van 10 jaar lang verantwoordelijk voor het maken en distribueren van een Windows en macOS app. Hiervoor hebben we van alles ingezet en uiteindelijk met "Google Omaha" redelijk frictieloos gekregen. Min of meer hetzelfde als de flow van de Chrome installatie van vandaag de dag. Beter dan dat gaat het niet worden op bijvoorbeeld Windows. Echter bleef de native app qua gebruik altijd ver achter op de web app, hoeveel we ook stuurde naar de native app.

[Reactie gewijzigd door closefuture op 26 september 2026 11:53]

[rjvdboon]

Hiervoor hebben we van alles ingezet en uiteindelijk met "Google Omaha" redelijk frictieloos gekregen

De github repo van Google Omaha is read-only sinds Aug 2025 en wordt dus niet meer onderhouden. Zijn jullie al aan het kijken naar een vervanger? En zo ja, welke? (ik zoek zelf ook Iets dergelijks)

[closefuture]

Omaha ansich is volgens mij niet dood, het is verplaatst naar de Chromium source tree. In deze blogpost Chromium Updater ("Omaha 4") Tutorial kun je lezen hoe je het nog steeds kunt gebruiken.

De use-case van de native applicaties die wij hebben is veranderd waardoor het nu eigenlijk meer een soort "one shot" use case is. Zeg maar meer zoals iemand die eenmalig TeamViewer gebruikt om remote geholpen te worden. Daarom maken we nu executables die helemaal opzich zelf staan en direct de applicatie runnen met warp. Daarom heb ik geen ervaring met Omaha 4, maar op basis van mijn ervaring met Omaha 3 zou ik het zeker proberen.

[Scribe]

Vraag me toch soms af of hij weet waar hij het over heeft...

Omarchy krijgt dan wel veel geld maar heb ik uberhaupt geen vertrouwen in. Rust heeft goede performance en is juist veel makkelijker en duidelijker om te lezen, misschien biased omdat hij elke taal behalve zijn eigen slecht vindt...

[graey]

Ook interessant om af te vragen: waarom is AI minder goed met Ruby? Dat komt niet door een of ander natuurverschijnsel ofzo, het bestaat langer dan Rust en heeft lang veel gebruikers geteld. Mogelijk is het gewoon te impopulaire geworden (volgens mij geen acceptabele boodschap voor DHH), of zijn de dev tools inferieur waardoor de feedbackloop tijdens agentic development minder effectief is. Hij kiest er dus voor om dat te accepteren en Ruby dan maar achter zich te laten in dit geval. Interessant

[Exirion]

Zal wel gesponsord worden door Anthropic ofzo.

[PCR]

Ik ben zwaar fan van DHH. De man weet precies welke snaar hij moet raken om de boel weer flink op te schudden. Dit is daar een perfect voorbeeld van. Ik hou er wel van. Maar goed, ook ik heb de afgelopen maanden nauwelijks een regel code geschreven dus ik zit sowieso al wel wat in zijn kamp.

[Xander2]

Ruby on Rails had lang geleden een impact en was elegant en handig voor webapps.

Achterhaald door performance, geheugengebruik en multithreading issues, er zijn gewoon betere stacks.

Ik heb geprobeerd de keynote te kijken maar het gaat de eerste 10 minuten over AI en klassieke schilders.

Ik denk dat er weinig meer te melden is over Ruby en Ruby on Rails.