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 (186)

[Kerfuffle]

Om dit in context te plaatsen: DHH heeft wat behoorlijk racistische drek gepubliceerd, in reactie waarop er breedgedragen oproepen in de Ruby on Rails community zijn om hem te weren of de boel te forken. Die roep is alleen maar sterker geworden toen bleek wat voor antidemocratische figuren zijn Omarchy funden.

Dat DHH nu afstand neemt van Ruby on Rails zou ik dan ook zeker niet op technische merites alleen afschuiven.

[fedaykin]

Heb je wat voorbeelden? Met het geschreeuw van alle kanten tegenwoordig neem ik niks meer aan zonder bewijs. Ik heb tot nu toe alleen maar wat quotes gevonden die vervolgens met een bril vanuit onderdrukking en racisme geinterpreteerd zijn. Ik houd het voor mogelijk hoor, DHH is nogal een luid mannetje en mag zichzelf graag horen praten met z'n piepstemmetje. Zegt technisch wel veel zinnige dingen die, of je het er nou mee eens bent of niet, wel een ander perspectief laten zien.

[thePiett]

Wikipedia: David Heinemeier Hansson

[Kerfuffle]

Om de nadruk te leggen op de aanleiding & gevolgen in de community en niet op wat ik er allemaal zelf van vind: hier is de community oproep tot een fork van Rails met een onderbouwing waarom ze dat hebben gedaan, en de aankondiging ervan in de rails Reddit.

https://www.reddit.com/r/rails/comments/1nr96on/an_open_letter_calling_for_a_hard_fork_of_rails/

https://github.com/Plan-Vert/open-letter - dit bevat het gros van de artikelen en voorvallen waar men aan refereert. Het is door velen ondertekend, o.a. door Eugen Rochko, de oprichter & developer van Mastodon, wat één van de populairste Ruby on Rails applicaties is.

Het gaat overigens niet alleen over Rails, maar ook over Ruby Central, de non-profit organisatie achter een aantal Ruby events en tools. De controverse rondom DHH heeft ook daar tot het intrekken van funding van 250000 dollar van Sidekiq en een afsplitsing geleid, waardoor er parallelle events en tools zijn: https://jaredwhite.com/articles/ruby-central-is-not-operating-in-good-faith (ook hier veel links naar quotes van DHH, waar hij zich schaart achter Tommy Robinson, Andrew Tate, Trump, etc) en https://www.fullstackruby.dev/ruby-infrastructure/2025/10/06/theres-a-new-gem-server-in-town/ en https://joel.drapper.me/p/rubygems-takeover/ .

Het is echt heel veel om te lezen en er wordt aardig wat over en weer verweten over wie in welk kamp zit, wie wie er uit probeert te werken en wie het waarheen probeert te trekken. Met mijn woordkeus in m'n eerste reactie steek in niet onder stoelen of banken dat ik me in de argumenten van de initiatiefnemers kan vinden en ik DHH onverdedigbaar vind, maar ik begrijp ook dat er genoeg mensen zijn die "separate art from the artist" beleiden en het over technologie willen hebben - zoals de auteur van dit Tweakers artikel - of denken dat meer aandacht voor z'n uitspraken meer kwaad dan goed doet, of denken dat de soep niet zo heet wordt gegeten als hij geschonken wordt en dat DHH vooral zit te trollen.

Mijn punt is wel: de aanleiding van deze ophef en afsplitsingen in de Ruby & Rails community is de reeks uitingen door DHH, zoals aangehaald in bovengenoemde open letter. En dat is relevant als je hem nu uitgerekend op zijn eigen Ruby on Rails congres hoort praten over dat alles makkeiljker is in AI met een andere programmeertaal.

[Reactie gewijzigd door Kerfuffle op 28 september 2026 16:28]

[fedaykin]

Hartelijk bedankt voor je uitgebreide reactie + allerlei voorbeelden. Ik heb een deel gelezen en ga de rest lezen vandaag. Ik kijk geregeld een filmpje of lees een stukje van DHH, het is goed om te weten wat voor gekkigheid hij verder uithaalt.

Als we op deze manier blijven praten komt alles goed.

Of ik DHH het label 'racist' wil geven twijfel ik nog een beetje over... het lijkt meer op het extreem overtrokken "we hebben het gevoel dat er een crisis is" sentiment dat hier in NL ook wel leeft (en ik me kapot aan erger, er zijn problemen, maar dit nu al 20, 30, 50 jaar onze grootste politieke prio is? Kom op).

Goed, alle rijke stinkerts hebben ergens iets gestolen anders hadden ze niet tig keer zo veel als de rest, dus hoe dan ook hoeft en verdient DHH mijn verdediging sowieso niet.

[eurob]

Deze podcast met Lex Fridman en DHH vond ik erg interessant, al is hij met ruim vijf uur wel een behoorlijke zit.

In dit fragment gaat hij vrij uitgebreid in op zijn mening over immigratie en de kritiek die hij daarop heeft gekregen:

YouTube: DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501

Ik heb de hele podcast geluisterd en persoonlijk kreeg ik uit dit gesprek niet de indruk dat zijn standpunt simpelweg neerkomt op racisme. Hij zegt zelf juist voor immigratie te zijn, maar ook dat landen vragen moeten kunnen stellen over grootschalige immigratie, demografische veranderingen, integratie en wat de gevolgen kuunen zijn voor de samenleving.

Betekent natuurlijk niet dat je het met zijn conclusies eens hoeft te zijn, maar ik vind het wel de moeite waard om zijn daadwerkelijke argumentatie te horen voordat je er zo'n zwaar label als “racistisch” op plakt.

[fedaykin]

Dit is waarom ik twijfelde!

Ik dacht ergens te herinneren een nuance van hem gezien te hebben.

Anyway, als hij altijd z'n grote waffel open heeft moet hij ook niet verbaasd zijn dat sommige mensen zijn gal bitter vinden.

[Dan the Man]

Ruby is oorspronkelijk ontwikkeld door Yukihiro Matsumoto. Nooit van die Hansson gehoord. En dat Rails wil je vast niet -- dat is slechts een eenvoudig 'framework' voor webzijdes.

[Armselig]

Voor wie in October nog naar Japan gaat https://kaigionrails.org/2026/
Matsumoto is daar ook bij.

[Rafe]

De dag na bovenstaande keynote zaten ze samen in een fireside chat: YouTube: Ruby, Rails, and the future of programming - Matz, DHH & Jeremy Daer

[cedal]

Haha, dat denk jij. Rails is zo'n stille kracht met niet al teveel hype en wel extreem veel kracht

Redelijk wat miljoenen/miljardenbedrijven die het in hun belangrijkste stack gebruiken

[PCR]

Ik denk dat je je vergist in Ruby on Rails. Mijn softwarebedrijf heb ik bovenop Ruby on Rails gebouwd. Dus ik wil het zeker wel haha.

[combimagnetronn]

Wat heeft dat te maken met het vertalen van een app naar rust?

[yPop]

Waarom werkt Rust zo goed met ai?

[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.

[.oisyn]

Het tijd-argument lijkt me redelijk onzin. Ja, je bent misschien iets langer bezig met het design, dat daarna dan ook klopt en je minder lang bezig bent met het debuggen van willekeurige memory bugs. Ook refactoring is een stuk fijner omdat je gewoon weet dat als je een referentie naar iets hebt, iemand anders het dus niet kan muteren.

[Powerblast]

Refactoring is fijner als je op voorhand weet waar je wil uitkomen. Voor pure brainstorming en “even snel wat proberen” werkt het minder fijn, juist omdat snel 1 ding aanpassen de compiler gewoon blokkeert. Prototyping is het dus niet zo handig voor, maar end products zijn technisch meestal beter.

[turbojet80s]

En dat zorgt dat weer voor... rust

[Powerblast]

Op een manier geeft Rust inderdaad rust in je hoofd als developer . Op een ander manier heeft het echt extreem veel mental load vind ik.

Meeste wijzen naar de borrow checker als het stuk dat zo moeilijk te begrijpen is, maar dat vond ik persoonlijk nog niet zo moeilijk eigenlijk. Het is bij mij vooral de volledige andere manier (die niet intuitief is eens je voldoende groot designed) van designen.

De meeste basic voorbeeldjes zijn inderdaad niet zo lastig eens je voor de borrow checker manier van denken bent. Tot je begint met explicit lifetimes, async en nog wat multithreading erbij. Welkom bij de vage syntax waarbij zelfs de compiler errors naar mijn mening niet altijd even nuttig zijn. De compiler zegt dan nog wel wat er niet goed is, maar het wijst niet perse meer naar de plaats waar het daadwerkelijke probleem zit in je design, als je snapt wat ik bedoel. Punt B kan niet compilen, maar eigenlijk zit het grote probleem bij punt A. Om punt A om te bouwen moet je echter je volledige architectuur op de schop doen.

[Reactie gewijzigd door Powerblast op 26 september 2026 14:56]

[Ryunoru]

Dan is het dus geen onzinargument, want tijd om te developen maakt zeker wel uit. Dat staat niet in direct verband met eventuele gewonnen tijd achteraf door minder debuggen en dergelijke - de ontwikkelaars zelf moeten nog tijd besteden aan het schrijven in Rust. Althans, moesten*.

[.oisyn]

Het oplossen van bugs in je shitty code valt óók onder development tijd.

[Ryunoru]

Niet persé. Ontwikkelen en QA gebeuren vaak niet door dezelfde personen.

[.oisyn]

Dan speel je gewoon woordspelletjes. Hoe dan ook is er meer manuren nodig.

[Ryunoru]

Hoezo woordspelletjes? Het gaat hier om het perspectief van de ontwikkelaar, niet van de QA-er. Overigens zal ook het oplossen van bugs middels AI gebeuren, dus uiteindelijk kost het ook in totaal minder manuren.

[.oisyn]

Omdat we heb hebben over het development proces. Dat het gaat om een individuele developer die de kantjes eraf kan van lopen door zijn rotzooi over de schutting te gooien, wat bij Rust wat moeilijker kan, is iets wat jij ervan maakt.

Een QA afdeling fixt overigens niet de bugs, die vindt ze. Het is alsnog de developer die ze moet fixen.

[Reactie gewijzigd door .oisyn op 26 september 2026 23:49]

[Ryunoru]

Als we het over de development hebben, waarom begin je dan zelf over andere zaken zoals de QA- en bugfix-zijdes? Hoe dan ook, zelfs als felle tegenstander van AI is het me duidelijk dat men zich steeds minder gaat bezighouden met handmatig code schrijven. Het gros van het werk zal door AI gedaan worden - ontwikkeling, QA èn bugfixing. Die rotzooi over de schutting komt niet ver als een robot aan de andere kant de boel weer opruimt.

[.oisyn]

Euhm, *jij* deed dat. Het argument was: rust development duurt langer omdat je langer bezig bezig bent om te voldoen aan de restricties.

Ik zeg: dat is wel tijd die je weer wint omdat men minder lang bezig is met het oplossen van memory bugs

Jij bent degene die beweerde dat het oplossen van bugs niet onder ontwikkeltijd valt en dat QA dat doet: Ryunoru in 'Ruby on Rails-oprichter vibecodet zijn eigen software om naar 'vreselijk' Rust'

[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.

[Powerblast]

Naar mijn ervaring werkt AI juist slechter met Rust. Basics ja, daar zijn voorbeelden genoeg van te vinden. Begin je met explicit lifetimes dan draait het volledig de soep in met grote kans dat het niet meer compiled. Als het nog compiled zit je met onnodige zaken all over the place.

Blijkbaar heeft hij een andere ervaring, maar bij mij werkt het althans niet goed genoeg.

[latka]

In het algemeen geldt: een sterk getypeerde taal is handiger want dan kun je zien dat dingen niet gaan werken in runtime (een integer in een string duwen enzo). De meeste 'moderne' talen (Javascript, Ruby, Python) zijn op zijn best loosely typed: Duw jij een string in een integer dan probeert de runtime er wat van te maken en is het hopen dat het werkt. Rust voert dat wat verder door (niet alleen typing, maar ook memory-allocatie moet kloppen anders compiled het niet eens). Strong typing is voor sommige mensen vervelend (dan moeten ze vooraf na gaan denken en veel dingen onthouden) maar voor een AI is dat geen enkel probleem. Dus is het handig om strong-typing en strong-memory allocation garanties te hebben zodat je een stuk zekerder ervan kunt zijn dat je code werkt als de compiler het accepteert. Scheelt weer een hoop klikwerkt bij het testen.

[StCreed]

Ik gebruik momenteel javascript met de lintjs extensies om typen allemaal te declareren en controleren. En na vandaag: ook een eigen controle op alle functies met een return value die een fout aangeeft, dat die ook wordt getest door de ontvanger... want ja dat ging dus mis.

[Immutable]

Omdat het heel closed loop is. Het geeft duidelijk compilefouten. Ik merk zelf ook dat Rust extreem goed werkt via LLM. Echt heel weinig runtime problemen.

[Reactie gewijzigd door Immutable op 26 september 2026 18:38]

[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.

[Cergorach]

* shrugs *

Wanneer is de laatste keer geweest dat je een pons kaart gebruikte of puur in binair of assembly programeerde? En hoe relevant is die technologie nu nog?

En vroeger had je daadwerkelijk kennis nodig van de computer die je bediende, tegenwoordig zit overal een computer in en hebben de mensen die het bedienen geen flauw benul van hoe dat exact allemaal werkt.

En vergeet ook niet dat de eerste programmeer talen gekoppeld waren aan hardware die alleen voor hele grote bedrijven betaalbaar was.

Weet jij hoe je een chip maakt van scratch, hoe je de hele tool chain maakt die daarvoor nodig is?

En hoe is het gesteld met jou COBAL kennis? Daar is best vraag naar (geweest) maar de wereld viel niet om omdat niemand meer die taal leerde.

Wanneer is de laatste keer geweest dan je een programma in een kale notepad heb geschreven en met de hand heb gechecked of fouten.

De jeugd doet wat het wil, gaan ze vibecoden, prima! Voor velen is de lol er snel vanaf, andere komen er achter dat het toch niet stabiel/veilig is omdat ze niet precies weten wat ze doen. Een gedeelte zal de moeite nemen om dat uit te gaan zoeken, de rest valt af.

Voor AI/LLM een ding werd kon de jeugd al helemaal niets zelf behalve op een paar icoontjes klikken. 15 jaar gelden merkte de Informatica leraren al op dat nieuwe scholieren voor de hoge school informatica opleidingen nog nooit een commandline hadden gebruikt toen ze voor het eerst daar binnen kwamen. Uit een paar honderd hadden slechts een paar dat ooit gedaan. Dat is nu de huidige generatie developers met al 10 jaar ervaring (15-5 jaar opleiding)... How scary is that!

Omdat bepaalde mensen AI nu zien als volwaardig mens ipv. een stukje gereedschap is diens probleem. Dit zijn zeer zeker niet alle mensen. En zeker niet de eerste keer dat mensen niet begrijpen wat ze gebruiken en zeker niet de laatste keer.

[bzzzt]

Wanneer is de laatste keer geweest dat je een pons kaart gebruikte of puur in binair of assembly programeerde? En hoe relevant is die technologie nu nog?

En hoe is het gesteld met jou COBAL kennis? Daar is best vraag naar (geweest) maar de wereld viel niet om omdat niemand meer die taal leerde.

Om te beginnen is het COBOL , maar waar je hier de mist in gaat is het verwarren van noodzakelijke techniek zoals binaire instructies met high level verschillen zoals de syntax van een programmeertaal.

De noodzakelijke techniek is er nog, is te doorgronden en zal in sommige gevallen relevant zijn om problemen op te lossen. Een andere programmeertaal is een vervanging (al bouwen veel talen op elkaar door).

Weet jij hoe je een chip maakt van scratch, hoe je de hele tool chain maakt die daarvoor nodig is?

Ligt er aan hoe complex de chip moet zijn, maar in principe zijn de basics prima te doorgronden. De exacte processen die ASML machines uitvoeren zijn 'wat' ingewikkelde ;).

Wanneer is de laatste keer geweest dan je een programma in een kale notepad heb geschreven en met de hand heb gechecked of fouten.

Jaren terug een keer een certificatie in een programmeertaal gedaan waar verwacht werd dat je foutloze code kon schrijven zonder compiler.

De jeugd doet wat het wil, gaan ze vibecoden, prima! Voor velen is de lol er snel vanaf, andere komen er achter dat het toch niet stabiel/veilig is omdat ze niet precies weten wat ze doen. Een gedeelte zal de moeite nemen om dat uit te gaan zoeken, de rest valt af.

Laten we het hopen. Persoonlijk zou ik niet graag zien dat we bijvoorbeeld medische administratie gaan vibecoden en er pas bij een noodgeval achter komen dat het niet stabiel of veilig is en iemand bijvoorbeeld een overdosis krijgt...

Voor AI/LLM een ding werd kon de jeugd al helemaal niets zelf behalve op een paar icoontjes klikken. 15 jaar gelden merkte de Informatica leraren al op dat nieuwe scholieren voor de hoge school informatica opleidingen nog nooit een commandline hadden gebruikt toen ze voor het eerst daar binnen kwamen. Uit een paar honderd hadden slechts een paar dat ooit gedaan. Dat is nu de huidige generatie developers met al 10 jaar ervaring (15-5 jaar opleiding)... How scary is that!

Je kan je ook afvragen waarom die commandline zo heilig verklaard wordt. Het is een onintuitief ding, niet typesafe, slechte discoverability en commando's zijn niet echt consistent. Je kan er fantastisch mee automatiseren maar mensen beoordelen op het wel of niet de voorkeur geven aan een GUI voor het uitvoeren van taken is puur gatekeeping.

[CAPSLOCK2000]

Je kan je ook afvragen waarom die commandline zo heilig verklaard wordt. Het is een onintuitief ding, niet typesafe, slechte discoverability en commando's zijn niet echt consistent.

Dat is inderdaad de moeite waard om over na te denken. Ik denk dat het meer omgekeerd is en dat GUI's heilig zijn verklaard en de enige acceptabele interface en mensen blind zijn voor de nadelen. Er is niet één beste interface, het ligt aan de taak en de gebruiker. Net zoals dat "gebruikersvriendelijk" afhankelijk is van wie de gebruiker is.

Daar staat tegenover dat GUI's niet (zomaar) controleerbaar zijn en dat er geen compacte manier is om instructies te geven.
Een commando als "dir c:" werkt altijd en geeft altijd hetzelfde resultaat. Je kan op je scherm zien welk commando je hebt gegeven en wat het resultaat was. Als je een fout maakt kun je exact zien wat er fout is gegaan.

GUI's hebben ook een paar forse nadelen voor beginnende gebruikers.
Ten eerste heb je aparte instructies nodig die de gebruiker moet interpreteren zoals "klik op het kruisje", "klik op OK", "scroll naar beneden", "ga naar settings". Dat vereist enige kennis en is afhankelijk van de taal die je spreekt. Vaak worden screenshots gebruikt om het te laten zien, maar ook dat is foutgevoelig want je kan makkelijk iets over het hoofd zien in een screenshot met meerdere veldjes en knopjes, en het neemt ruimte in.
Instructies voor een CLI kun je heel compact en exact opschrijven zonder enige interpretatie van de gebruiker.

Ten tweede is een CLI controleerbaar. Alles wat je gedaan hebt staat nog op het scherm. Als je een fout maakt kun je precies zien wat je fout hebt gedaan. Bij GUI's kan dat meestal niet, als je eenmaal op het knopje hebt gedrukt is er geen manier meer om te zien op welk knopje je hebt gedrukt.
Voor beginnende gebruikers (en hun docenten) is het heel prettig om terug te kunnen kijken wat ze hebben gedaan.

Ten derde zijn GUI's overweldigend, het scherm staat vol met knopjes en veldjes die eigenlijk niet relevant zijn tot de gebruiker een bepaalde taak wil doen. Om er gebruik van te maken moet je alles wat je niet nodig hebt negeren. Een CLI werkt met precies de kennis die de gebruiker heeft. Die kan stap voor stap nieuwe commando's leren zonder overweldigd te worden door 100 andere functies die ook nog bestaan.

Verschillende generaties gebruikers hebben computers via een CLI leren gebruiken via een blaadje met uitgeschreven commando's die ze alleen maar hoefde over te tikken, om daarna stap voor stap meer kennis op te doen.

Of de voordelen opwegen tegen de nadeel is een andere discussie, maar een CLI heeft zeker voordelen voor nieuwe gebruikers.

[bzzzt]

Dat is inderdaad de moeite waard om over na te denken. Ik denk dat het meer omgekeerd is en dat GUI's heilig zijn verklaard en de enige acceptabele interface en mensen blind zijn voor de nadelen. Er is niet één beste interface, het ligt aan de taak en de gebruiker. Net zoals dat "gebruikersvriendelijk" afhankelijk is van wie de gebruiker is.

Het grote probleem met CLIs is dat veel gebruikers niet weten waar te beginnen als ze een zwart scherm met een prompt symbool zien. Een GUI is in die zin veel toegankelijker dan een CLI, wat ook duidelijk wordt als je ziet met wat voor enorme sprong het PC gebruik toegenomen is sinds de introductie van Windows 95. (niet dat dat de beste GUI was, maar wel het eerste breed gedragen systeem met een GUI)

Daar staat tegenover dat GUI's niet (zomaar) controleerbaar zijn en dat er geen compacte manier is om instructies te geven.

Er zijn zat GUI applicaties die boordevol shortcuts zitten. Van Excel tot Blender kan je ze praktisch met het toetsenbord bedienen.

Een commando als "dir c:" werkt altijd en geeft altijd hetzelfde resultaat. Je kan op je scherm zien welk commando je hebt gegeven en wat het resultaat was. Als je een fout maakt kun je exact zien wat er fout is gegaan.

Dan moet je om te beginnen wel een idee hebben waar 'dir c:' voor staat. Op mijn Mac krijg ik alleen maar 'command not found' wat niet echt behulpzaam is als je niet weet wat je nodig hebt.

GUI's hebben ook een paar forse nadelen voor beginnende gebruikers.
Ten eerste heb je aparte instructies nodig die de gebruiker moet interpreteren zoals "klik op het kruisje", "klik op OK", "scroll naar beneden", "ga naar settings".

Bij CLIs vinden we het normaal dat gebruikers die kennis al hebben. Gebruikers die je op dat nivo moet helpen gaan daar helemaal niets van begrijpen.

Instructies voor een CLI kun je heel compact en exact opschrijven zonder enige interpretatie van de gebruiker.

Heb vaak genoeg gezien dat gekopieerde scripts gemangeld zijn door clipboards, terminals e.d. of gewoon verkeer overgetikt worden. De uitvoer wordt niet goed bekeken dus pas nadat je een terabyte aan logfiles kwijt bent komt iemand een keer lang om te vragen of het wel goed was...

Een CLI werkt met precies de kennis die de gebruiker heeft. Die kan stap voor stap nieuwe commando's leren zonder overweldigd te worden door 100 andere functies die ook nog bestaan.

En dat is een oplossing en een probleem: een gebruiker die nog geen kennis heeft kan meer met een GUI.

Of de voordelen opwegen tegen de nadeel is een andere discussie, maar een CLI heeft zeker voordelen voor nieuwe gebruikers.

Dat heb ik ook nergens ontkend. Wat ik vooral bedoelde met die 'heilig verklaring' is dat er nogal eens vanuit wordt gegaan dat een CLI, en dan in het bijzonder meestal de UNIX CLI, beter is terwijl daar absoluut genoeg kritiek op valt te geven:

• onintuitieve en inconsistente commando namen
• commando's met veel te veel parameters (kijk voor de grap eens naar openssl...)
• alleen tekst gebaseerde i/o waardoor je makkelijk de verkeerde data doorgeeft
• cryptische foutmeldingen (lp0 on fire...)

Daarnaast is het voor iemand die af en toe een bepaald programma nodig heeft niet te doen om allerlei CLI commando's uit het hoofd te leren. Als er genoeg tijd tussen zit dat alle instructies weer vergeten zijn loop je continu tegen de leercurve aan en heb je nooit de efficiencywinst...

[CAPSLOCK2000]

Wat ik vooral bedoelde met die 'heilig verklaring' is dat er nogal eens vanuit wordt gegaan dat een CLI, en dan in het bijzonder meestal de UNIX CLI, beter is terwijl daar absoluut genoeg kritiek op valt te geven:

Tja, als je zo extreem opvat dan is het uiteraard onjuist. Niks is zuiver goed of slecht.
Ik wil daarom verder ook niet ingaan op welke interface beter is in absolute zin.

Ik heb wel nog een paar algemene opmerkingen om elkaar beter te begrijpen:

Er zijn zat GUI applicaties die boordevol shortcuts zitten. Van Excel tot Blender kan je ze praktisch met het toetsenbord bedienen.

Dat is niet wat ik bedoel. Je kan niet achteraf controleren op welke shortcut je hebt gedrukt. Als de gebruiker per ongeluk op CTRL-X drukt en al z'n content wegknipt dan komt die gebruiker er nooit achter wát er fout is gegaan.

Heb vaak genoeg gezien dat gekopieerde scripts gemangeld zijn door clipboards, terminals e.d. of gewoon verkeer overgetikt worden.

Natuurlijk worden er tikfouten gemaakt, niks is perfect. Maar je het is veel lastiger om duidelijk te maken op welk knopje er gedrukt moet worden zonder er een plaatje van het venster bij te doen. De gebruiker moet dan wel weer weten wat er belangrijk is, dus zo'n plaatje wordt dan vaak ook nog voorzien van rode lijnen om duidelijk te maken waar de gebruiker moet klikken. Omslachtig en niet te controleren.

Bij CLIs vinden we het normaal dat gebruikers die kennis al hebben. Gebruikers die je op dat nivo moet helpen gaan daar helemaal niets van begrijpen.

Het mooie (nou ja) is dat gebruikers het niet hoeven te begrijpen. Je kan letter voor letter precies opschrijven op welke toetsen ze moeten drukken. Als ze op de juiste toetsen drukken dan krijgen ze het juiste resultaat. Dat is een stuk lastiger met een GUI waarin dingen in vensters op verschillende plekken kunnen verschijnen. Er zijn veel meer dingen die mis kunnen gaan zonder dat de gebruiker een kans heeft om het op tijd te zien of achteraf te controleren.

Dat docenten het zorgwekkend vinden dat zo weinig studenten met een CLI overweg kunnen heeft imho niks te maken met theoretische voor- of nadelen, maar meer met hoe onze wereld in praktijk werkt. CLI's zijn een onderdeel van geavanceerde IT en kennis daarvan is een indicator dat die persoon al wat meer IT kennis heeft.

[bzzzt]

Dat is niet wat ik bedoel. Je kan niet achteraf controleren op welke shortcut je hebt gedrukt. Als de gebruiker per ongeluk op CTRL-X drukt en al z'n content wegknipt dan komt die gebruiker er nooit achter wát er fout is gegaan.

"Nooit" is natuurlijk een groot woord. Een goede 'undo' functie en daarna nog eens proberen geeft al aan of de gebruiker een tikfout heeft gemaakt of de verkeerde shortcut aanroept. Sommige GUI applicaties laten zelfs de laatste actie zien in het edit menu.

Er zijn zat CLIs die weinig feedback geven.

Natuurlijk worden er tikfouten gemaakt, niks is perfect. Maar je het is veel lastiger om duidelijk te maken op welk knopje er gedrukt moet worden zonder er een plaatje van het venster bij te doen. De gebruiker moet dan wel weer weten wat er belangrijk is, dus zo'n plaatje wordt dan vaak ook nog voorzien van rode lijnen om duidelijk te maken waar de gebruiker moet klikken. Omslachtig en niet te controleren.

En toch redden miljoenen mensen het met dergelijke instructies een computer te gebruiken.

Het mooie (nou ja) is dat gebruikers het niet hoeven te begrijpen. Je kan letter voor letter precies opschrijven op welke toetsen ze moeten drukken.

Je presenteert dit als een voordeel terwijl het eigenlijk eeen nadeel is. Begrijpen wat je doet is belangrijker dan een user interface paradigma.

Als ze op de juiste toetsen drukken dan krijgen ze het juiste resultaat. Dat is een stuk lastiger met een GUI waarin dingen in vensters op verschillende plekken kunnen verschijnen. Er zijn veel meer dingen die mis kunnen gaan zonder dat de gebruiker een kans heeft om het op tijd te zien of achteraf te controleren.

Ik kan hier geen enkel voorbeeld van bedenken. Als de uitvoer op een logische plaats verschijnt maakt het toch niet uit wat voor user interface er gebruikt is?

Dat docenten het zorgwekkend vinden dat zo weinig studenten met een CLI overweg kunnen heeft imho niks te maken met theoretische voor- of nadelen, maar meer met hoe onze wereld in praktijk werkt. CLI's zijn een onderdeel van geavanceerde IT en kennis daarvan is een indicator dat die persoon al wat meer IT kennis heeft.

Ik heb power users met Windows GUIs zien werken met verstand van zaken en een snelheid die ik vrijwel nooit heb waargenomen bij Unix CLI gebruikers. CLIs zijn hooguit een indicatie omdat het niet het standaard paradigma voor eindgebruikers is. En op zich logisch dat studenten dat dan nog onder de knie moeten krijgen, daarvoor zijn het studenten.

[CAPSLOCK2000]

"Nooit" is natuurlijk een groot woord. Een goede 'undo' functie en daarna nog eens proberen geeft al aan of de gebruiker een tikfout heeft gemaakt of de verkeerde shortcut aanroept. Sommige GUI applicaties laten zelfs de laatste actie zien in het edit menu.

Het verschil is dat een undo-actie niet vanzelf aanwezig is, dat is een feature die moet worden toegevoegd. Dan nog is het lastig om achteraf te zien wat er precies gebeurd is, als een venster eenmaal gesloten is dan werkt undo vaak ook niet meer.
Bij een CLI heb je altijd een volledige log van alle commando's die de gebruiker heeft gegeven.

Er zijn zat CLIs die weinig feedback geven.

Ik heb het niet over feedback, maar over het bijhouden wat de gebruiker precies heeft gedaan.

En toch redden miljoenen mensen het met dergelijke instructies een computer te gebruiken.

Dat betekent niet dat het de beste manier is.

Je presenteert dit als een voordeel terwijl het eigenlijk eeen nadeel is. Begrijpen wat je doet is belangrijker dan een user interface paradigma.

Dat ben ik op zich met je eens, vandaar mijn "nouj ja", maar ik heb het hier over het vermogen om instructies duidelijk weer te geven. Een CLI-commando heeft veel minder interpretatie nodig dan een plaatje of een omschrijving van een GUI.

Ik kan hier geen enkel voorbeeld van bedenken. Als de uitvoer op een logische plaats verschijnt maakt het toch niet uit wat voor user interface er gebruikt is?

Een voorbeeld is dat ik een gebruiker opdracht gaf om op de print-knop te klikken. De gebruiker ging op zoek naar de knop en vond als eerste een print-knop in een ander venster en probeerde daar op te klikken. Even later gebeurde hetzelfde met "Ok".
Dat was een echte beginnersfout, maar het illustreert dat het moeilijker is om exact vast te leggen wat een gebruiker doet of moet doen.

[bzzzt]

Dat ben ik op zich met je eens, vandaar mijn "nouj ja", maar ik heb het hier over het vermogen om instructies duidelijk weer te geven. Een CLI-commando heeft veel minder interpretatie nodig dan een plaatje of een omschrijving van een GUI.

Ik heb de irritatie mee mogen maken van collega's die volstrekt duidelijke CLI instructies naar een andere partij stuurde die prima in staat was fouten te maken als verkeerde symbolen (O en 0 zien er hetzelfde uit en een pipe lijkt ook wel op de lowercase L), verkeerde quotes gebruiken, hoofd- en kleine letters verwarren of foutmeldingen negeren en verdere instructies in de verkeerde directory uitvoeren. Vandaar dat ik niet helemaal overtuigd ben van de superioriteit van CLI of GUI. Beide paradigma's zitten vastgeroest in een stuk cultuur en aanwezige body van materiaal die het heel moeilijk maakt nog echte progressie te maken naar iets wat wel optimaal werkt...

[Xander2]

Je kan je ook afvragen waarom die commandline zo heilig verklaard wordt. Het is een onintuitief ding, niet typesafe, slechte discoverability en commando's zijn niet echt consistent.

De UNIX shells en tools die afzonderlijk geoptimaliseerd en te combineren zijn voor vrijwel alle mogelijke toepassingen vormen een briljant concept dat al meer dan 50 jaar gebruikt wordt voorbij de mogelijkheden die ooit bedacht hadden kunnen worden.

Dat is met recht een geniaal idee nog steeds na al die jaren en zou zeker onderdeel van elke programmeur's toolset moeten zijn al is het maar vanwege de alomvattende beschikbaarheid.

Ik kan alles 3D printen maar heb nog steeds een schroevendraaier nodig.

[StCreed]

Het is een goed idee, maar het enige OS wat dat gestructureerd aanpakte was AmigaOS. Zowel Unix als Windows laten dat over aan de developers zonder veel richting te geven. MacOS is Unix based, dus geen idee of die dat beter doen maar ik denk van niet.

[Llopigat]

Powershell doet dat ook wel, het mooie is dat je ook hele arrays tussen applicaties kan pipen in plaats van bij Unix dat je dan allerlei output moet gaan zitten parsen met dingen als xargs.

Ik zie dit wel als een serieuze verbetering alleen ik zou hier graag een open implementatie van zien in plaats van iets dat van Microsoft komt. Dus voorlopig laat ik het nog links liggen.

[xorpd]

Een pipe is binary (ook al wordt er meestal alleen tekst over gestuurd) dus het staat je vrij je eigen serdes te implementeren. En het enige wat xargs doet is de pipe data omzetten in command args.

find . -name '*.[ch]' | xargs wc | sort

[Reactie gewijzigd door xorpd op 28 september 2026 15:32]

[Llopigat]

Ik weet het, maar er is geen standaard waardoor elk programma de input van een ander moet begrijpen.

Dat doet Powershell een stuk beter. Ook wel logisch want het is 30 jaar later uitgevonden natuurlijk.

[Reactie gewijzigd door Llopigat op 28 september 2026 15:19]

[xorpd]

Die standaard is er dus wel: tekst. Alle pipe commando's communiceren onderling in tekst. Configuratie files zijn in tekst etc. Scripts, sources, eigenlijk alles, behalve binaries (ELF) en binary formats zoals PNG.

[Llopigat]

Ja maar al die configuratie files hebben weer andere formaten. Dat is het probleem. Elk tooltje vindt weer zijn eigen formaat uit.

Bij Powershell is dat gestandaardiseerd, je moet je nog wel druk maken over de namen van de variabelen enzo maar de structuur is gestandaardiseerd.

[Reactie gewijzigd door Llopigat op 28 september 2026 15:39]

[Cergorach]

Alles is te doorgronden, maar in de vroege middeleeuwen waren we collectief heel veel minder beton gaan gebruiken, de kwaliteit ging achteruit en vervolgens duurde het een hele tijd voordat het weer op grote schaal werd gebruikt. Alles is te doorgronden, maar niet door de meeste mensen.

Er zijn mensen die in een schuurtje in Nederland een basic chip produceren, maar daar kan je nog geen Atari 2600 op draaien...

Dan is de vraag, hoeveel jaren gelden is dat certificaat? En kon je dat ook daadwerkelijk... En hoeveel van de recente developers van pre LLM development kunnen dat of hebben dat recent genoeg gedaan om relevant te zijn?

Er gaat al van alles niet goed met dosering en toediening van medicatie op het menselijk vlak. Veel van de software die nu wordt gebruikt is gemaakt door derden, hebben de ziekenhuizen zelf de code gechecked of dat niet door een dronken intern is geschreven of door een dronken senior? Ik moet al jaren lang verkochte software oplossingen testen van leveranciers zoals zelfs Microsoft of ze wel productie klaar zijn, bij MS heb ik vaker een halfe oplossing moeten afkeuren voor productie of erger... En dit was al voordat LLM gemeengoed werd onder developers. Je zal voor je bedrijfscritische applicaties dergelijke tests moeten draaien, maar dat is al decennia de standaard om dat te doen (functioneel testen). Als daar tijdens het intern testen al inconsistentie uit rolt, neem je het gewoon toch niet in productie.

En wat betreft commandline, nee het geeft ook absoluut niet mijn voorkeur. Ik klik liever op een paar knopjes dan dat ik een lap powershell gebruik. Maar voordat ik aan mijn informatica opleiding begon had ik het wel gebruikt (uit noodzaak) en al die decennia lang ook gewoon nog moeten gebruiken uit noodzaak. Maar als je wat in de IT wil doen en je heb het nog nooit aangeraakt dan zegt wel wat over het interesse niveau...

Zo heb ik ook developers meegemaakt die minder van Windows snapte dan een doorsnee kantoormedewerker. En dan waren ze bezig met Windows applicaties...

Note: mijn brein gaat naar cobalt, minus een T...

[Llopigat]

En wat betreft commandline, nee het geeft ook absoluut niet mijn voorkeur. Ik klik liever op een paar knopjes dan dat ik een lap powershell gebruik.

Als ik twee gebruikers moet toevoegen dan ja, dan klik ik ook liever.

Als ik echter 20.000 gebruikers moet toevoegen, dan ben ik dolblij met die lap Powershell want die kan ik gewoon 20.000 keer iteratief aanroepen.

[Cergorach]

Als 20.000 gebruikers moet toevoegen, sure. Maar vaak hebben we het over 20.000 users migreren en dat doen we dan ook liever via tooling met knopjes.

Ka ik het via PS, ja, maar ik wordt daar over het algemeen niet zo heel vrolijk van. Want met de wijzigingen in PS, de PS plugins, etc. Test ik het meestal eerst op een test omgeving, wat weer heel veel extra werk met zich meebrengt.

[bzzzt]

Er zijn mensen die in een schuurtje in Nederland een basic chip produceren, maar daar kan je nog geen Atari 2600 op draaien...

Er zijn mensen die daar verder mee gekomen zijn dan je verwacht: https://archive.ph/iGei9

Dan is de vraag, hoeveel jaren gelden is dat certificaat? En kon je dat ook daadwerkelijk...

Ergens rond 2010, en: ja, ik kan beredeneren of code werkt zonder het uit te voeren.

Zo heb ik ook developers meegemaakt die minder van Windows snapte dan een doorsnee kantoormedewerker. En dan waren ze bezig met Windows applicaties...

Developer is een heel ander soort specialisme dan 'Excel jockey'. Op zich is dat niet zo erg, maar in de praktijk zie je soms wat vijandigheid...

[Triblade_8472]

Naast wat andere schrijven, is het jou dan opgevallen hoe meer gaten er in software valken? Hoe meer bugs en beveiligingslekken er zijn tegenwoordig?

Men wordt slordiger en heeft minder kennis over hoe degelijke programma's in elkaar zitten.

[Cergorach]

Het is nu niet erger dan vroeger, het valt nu alleen meer op. En dan heb ik het niet over de gevibecoded bende van non-developers. Het is nu veel makkelijker door AI/LLM het te achterhalen en de impact is veel groter dan dat dit 30 jaar geleden was, daarnaast is het ook veel meer interconnected geworden.

Er is nu alleen veel meer, veel complexer. Dus ja, je vind nu in absolute cijfers meer omdat er meer software is, daarnaast vind je nu percentueel meer omdat men de tools heeft en de motivatie. Daarnaast is men nu ook veel meer bezig met security. Ik kan me herinneren dat we ~25 jaar geleden onze allereerste security officer kregen binnen een dochter van een bank. En die had 0,0 kaas gegeten van de hele IT.

Ik denk ook dat post dot com bubble en pre AI/LLM er heel veel bedrijfjes heel snel producten produceerden die onder de motorkap verre van netjes inelkaar staken. We hebben dingen gedaan met NT4 die nu gewoon niet meer kunnen en men zich nou kapot zou schrikken. Hetzelfde met verschillende applicaties die nu nog steeds bestaan.

Pre 2000 deden we ook dingen met software die niet mochten en de makers daarvan nooit hadden verwacht dat mogelijk zou zijn. Vaak was software exploits gebruiken niet eens nodig omdat beheerders alles open lieten staan en niet eens wisten dat ze iets open lieten staan.

[downtime]

Ik zou het omdraaien. Men vindt vooral heel veel bugs en beveiligingslekken, dankzij AI, in oude code die indertijd gewoon door mensenhanden is geschreven.

[StCreed]

We zijn 7 maanden diep in de hype cycle en je merkt het aan bugs? Apart. Ik zie niet meer of minder bugs dan vroeger in mijn software.

[Killemov]

Huh, geen software pinguïns gaten in moet vallen?

[Rmaxx]

En laat nu net AI al die gaten vinden ... Je kunt beter AI laten zoeken naar lekken dan een persoon wat laten maken. Zoals bij veel technieken, de mense is de zwakste schakel.
Vibe-coden kan wel eens veiliger zijn dan het aan een persoon overlaten.

[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.

[Kerfuffle]

Ik hoop dat je AI-assisted coding bedoelt, want vibecoden is nooit een goed idee geweest en ik heb al aardig wat rommel mogen aanschouwen waar de boel knarsend tot stilstand kwam.

AI-assisted coding is gewoon een extra stuk gereedschap wat in de handen van een slecht vakman een hoop schade kan aanrichten en in de handen van een goed vakman het werk beter en sneller kan laten verlopen.

Waar vibecoden iets kan verdringen, is het bij selfware: als je ff een tooltje nodig hebt of ff iets simpels in elkaar wil zetten, kun je dat in een handomdraai door AI laten doen. Maar dat zijn echt PoC-achtige of kleine fit-for-purpose die je niet gaat onderhouden, ipv iets te moeten kopen wat meer doet dan je nodig hebt en wat een learning curve heeft.

[Llopigat]

Helemaal waar qua selfware en die kleine tooltjes is ook waar ik het nu voor gebruik.

Maar ik zie dit niet als een inherent probleem met AI. Meer een tijdelijke beperking die uitgewerkt gaat worden. Hoe meer context en begrip de AI krijgt, hoe grotere codebases het kan overzien. En dat zien we nu eigenlijk al gebeuren.

[CAPSLOCK2000]

Ik hoop dat je AI-assisted coding bedoelt, want vibecoden is nooit een goed idee geweest
<knip>
Waar vibecoden iets kan verdringen, is het bij selfware: als je ff een tooltje nodig hebt of ff iets simpels in elkaar wil zetten, kun je dat in een handomdraai door AI laten doen. Maar dat zijn echt PoC-achtige of kleine fit-for-purpose die je niet gaat onderhouden, ipv iets te moeten kopen wat meer doet dan je nodig hebt en wat een learning curve heeft.

Ik maak daar geen hard onderscheid tussen, volgens mij is er een heel spectrum tussen "volledig gevibecode uit één prompt" via "agentic coding" en "hogere level programeertalen" tot "met de hand op papier geschreven assembly met volledig correctheidsbewijs".

De techniek wordt steeds beter en kan steeds meer programmeeropdrachten zelfstandig uitvoeren. Dat zie ik dat voorlopig niet stoppen en vroeg of laat zal 99% van de code door machines worden geschreven en nooit door een mens worden gelezen.

[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.

[turbojet80s]

Uhm je krijgt allemaal plusjes, maar de reactie waar je op reageert gaat over de toekomst en niet over het heden. Sorry doorgewinterde devs in NL, maar voor het grootste deel van de software uit de (verre) toekomst gaat dat toch zeker gelden.

[xorpd]

Wolfos wijst erop dat ontwerp boven implementatie gaat en laten LLMs nu net slecht (understatement) in ontwerpen zijn. Dat zie ik ook niet 1-2-3 veranderen, daar is namelijk echte intelligentie voor nodig. Naast de verantwoordelijkheid voor de gevolgen van de ontwerpkeuzes, iets wat lachwekkend is voor een AI.

[Little Penguin]

Ik denk dat vibecoden inderdaad de toekomst heeft en binnenkort bijna niemand het nog met de hand doet

Op dit moment is de kwaliteit die uit de taalmodellen komt nog niet altijd om over naar huis te schrijven, probleem is dat junior developers dat niet (altijd) zien. Er is dan dus wel een senior developer nodig om te kunnen beoordelen of datgene wat technisch wel compileert ook de juiste oplossing is.

Probleem is echter dat een developer eigenlijk altijd als junior begint en door eigen ervaring medior en senior wordt, door die ervaring niet op te doen blijft een developer dus junior.

Uiteraard hangt het er ook vanaf op welk niveau het ingezet wordt, een website is wat anders dan een native programma met admin/root-access en dat is weer heel wat anders dan een OS-kernel. Waarbij in alle gevallen een taalmodel wel degelijk toegevoegde waarde kan hebben, alleen zou ik in het geval van een OS-kernel een taalmodel veel meer beperkingen opleggen en meer controleren dan bij het maken van een website...

[StCreed]

Zowel Linus Torvalds als Daniel Stenberg gebruiken nu AI. But what do they know...

[Little Penguin]

Nu heb je het over doorgewinterde developers, die dus ook ervaring hebben opgedaan voor het tijdperk van "AI". Zij weten onder welke condities er wel en niet gebruik gemaakt kan worden van het taalmodel. Er is ook helemaal niets op tegen om het te gebruiken, mits de ontwikkelaar maar goed oplet wat de agent en of het model doet.

* Little Penguin is niet tegen het gebruik van taalmodellen, maar maakt zich wel zorgen over hoe beginnende ontwikkelaars zichzelf tot een vergevorderde ontwikkelaar kan/gaat ontwikkelen als er te veel geleund wordt op de modellen...

[Rmaxx]

Ze geven zelfs aan de code niet eens meer te reviewen.. ze WILLEN het niet eens meer lezen. Ik denk dat veel programmeurs te vast zitten in hun eigen wereld om te zien dat dit echt aan het veranderen is, en snel ook.

[xorpd]

Ik zie het al voor me:

Linus: A.I., design a better kernel than the Linux kernel
A.I.: Of course, sit back and plan your retirement accordingly

[Rmaxx]

De vraag is wel wat 'kwaliteit' hier nog waard is. Als het veilig,snel, en doeltreffend is, hoeft het niet 'mooie' code te zijn. Vroeger moest een game op een floppy passen, dat waren pareltjes.. 8 of 64kb demo's - impressive, maar dat is niet meer nodig. Ik weet ook zeker dat de moderne LLMs tegenwoordig al meer security fixes paraat hebben dan de gemiddelde programmeur.

[Rmaxx]

Vibe-coden krijgt vaak nog een negatieve klank mee , dat zal op den duur veranderen. Dat is ook precies waar de speech over gaat volgensmij. Je kunt als professional nog steeds meerwaarde bieden zonder zelf je toetsenbord nodig te hebben. De kennis op hoger niveau, het overzicht op alle de randzaken, vooruit kunnen denken obv ervaring , dat is belangrijker.

[Barsonax]

Ik zie dit nog totaal niet gebeuren eigenlijk in mijn vakgebied. De vergelijking met een compiler gaat ook mank want dat is niet een probalistisch systeem.

Wel AI assisted hoor waar de inhoudelijke kennis gewoon belangrijk blijft. Gebruik het zelf ook en meeste schrijft AI maar ik snap elke regel. Maar goed ik werk dan ook aan nogal complexe systemen bij de overheid en daar kan je gewoon niet maar wat aanklooien met vibe coding.

[Reactie gewijzigd door Barsonax op 26 september 2026 14:13]

[CAPSLOCK2000]

Ik zie dit nog totaal niet gebeuren eigenlijk in mijn vakgebied. De vergelijking met een compiler gaat ook mank want dat is niet een probalistisch systeem.

Het is inderdaad niet iets dat van vandaag op morgen overal werkt, maar ik denk dat we er van uit kunnen gaan dat er steeds meer gevibecode gaat worden en dat de kwaliteit steeds beter zal worden. Het verschil tussen nu en twee jaar geleden is al gigantisch.

Maar, om even lekker op de theoretische aspecten van informatica in te gaan:

Tenzij je heel veel moeite doet zijn compilers ook niet echt deterministisch. De "reproducible builds" beweging is daar verandering in aan het brengen, maar die bestaat niet voor nietrs.

Hoewel LLMs in praktijk prabalistisch werken zijn ze het niet echt. Ze maken uiteindelijk gebruik van pseudorandom algoritmes met een of ander seed. Je kan ze ook met een fixed seed draaien en altijd exact dezelfde uitkomst krijgen. Ik verwacht dat we dat in de toekomst gaan doen zodat we LLMs meer als traditionele compilers gebruiken die altijd (min of meer) dezelfde output geven.

[Barsonax]

Maar waarom zou je dat willen terwijl dat al is opgelost in de vorm van programmeer talen die deterministisch en inspecteerbaar zijn? Natuurlijke taal is echt bagger wanneer je exact wilt zijn

[Rmaxx]

Waar baseer jij de deterministisch taken en inspecties dan op? Je denkt hopelijk zelf nog in natuurlijke toch, hoop ik? De meeste instructies/wensen/opdrachten die ik krijg zijn toch altijd in natuurlijke taal. Juist alle nuance uit een natuurlijke taal kunnen voor veel informatie zorgen die je niet in oneindige if/else-jes tot je wilt nemen.

[Barsonax]

Engineers met AI zijn veel beter in vage instructies te vertalen naar exacte taal dan een AI dat alleen kan.

Hoe vaak AI wel niet de verkeerde afslag maakt op een dag. Als je dat niet bijstuurt gaat dat echt helemaal mis. Mensen die beweren dat het aan de prompt oid ligt snappen gewoon niet waarover ze het hebben.

[Rmaxx]

Dat wordt wel elke week minder slecht,. Maar ik zeg ook niet dat iedereen dit goed kan: Het blijft werk voor een professional, maar dat heeft niet meer met het typen te maken. Sterker nog, als je blijft hangen in de 'ik wil alles controleren'-modus, ga je jezelf op termijn economisch onrendabel maken.

Bovendien werkt het 2 kanten op vaak weet een vakidioot op zijn gebied precies wat hij wil van zijn software, maar kan dat niet uitleggen aan een programmeur (dit dit wel zou kunnen vertalen naar code). of de programmeur denkt dat hij het wel snapt, maar sluit uiteindlijk niet aan bij wat in de praktijk het proces is.

[Reactie gewijzigd door Rmaxx op 28 september 2026 15:58]

[xorpd]

Compilers zijn dus echt wel 100% deterministisch. Ze gebruiken geen random number generator. De output (object files) hoeft niet deterministisch te zijn door zaken als timestamps, meegelinkte externe code en technieken zoals obfuscatie maar kan natuurlijk wel.

[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.

[peeceej]

En aan de onderkant heb je ook weinig te vrezen, de informatica-opleidingen op hbo en wo niveau lopen leeg sinds de opmars van AI.

[Exirion]

De vraag is wel of het werk leuk blijft. Ik laat nu vooral saaie relatief simpele klussen over aan LLMs, maar zodra AI overal gemeengoed is, wordt door managers vanzelf ook meer output verwacht en moet je er in meegaan. Dat betekent minder zelf doen, en ik weet niet of ik daar gelukkig van word.

[peeceej]

Dat geldt denk ik voor iedereen met een kantoorbaan. Ben wat dat betreft wel benieuwd hoe het werkend levend er in 2035-2040 uit ziet. Dan zijn er toch al wat jaren aan ontwikkelingen voorbij, maar is het toch nog relatief dichtbij. Afgelopen twee jaar was ook standaard bij elke met pensioen gaande collega de reactie "ben blij dat ik dat AI gedoe op kantoor niet meer hoef mee te maken".

[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.

[Cergorach]

Ik hoor nog links en rechts dat er nieuwe applicaties worden gemaakt in COBOL (naast het onderhoud), maar kan me niet voorstellen dat het een hoog percentage is in de markt. Ja het is nog essentieel voor belangrijke stromen (waaronder geld), maar ik denk dat het al een decennia of drie niet meer vaak wordt gebruikt en men kan nog steeds personeel ervoor vinden (wat peperduur is en IBM wil dit graag zo houden). Wat best wel bizar is.

[GeroldM]

Voor zover ik heb begrepen heeft de software geschreven in COBOL zichzelf bewezen als uiterst betrouwbaar. En dat is met internationale geldstromen behoorlijk belangrijk. Zeker vanwege de complexiteiten die je daar kan tegenkomen (vooral na wetswijzigingen enz.).

Wil je als bank deelnemen aan dit type geldverkeer, dan dien je jezelf te bewijzen dat je net zo betrouwbaar bent. Daar gaat dan een heleboel tijd, geld en moeite in zitten en je vergunning voor deelname ben je heel snel weer kwijt als er ook maar ergens een fout in is geslopen.

Er zijn nog een boel andere, al zeer lang bestaande bedrijfstakken. waarbij betrouwbaarheid van het grootste belang is. En daar kom je nog steeds talen als COBOL en FORTRAN tegen.

[Cergorach]

Ik kan me van 20-25 jaar geleden herinneren dat verschillende banken absoluut niet happy waren met het beperkt aantal leveranciers waar ze hun software uit konden kiezen. Deze waren natuurlijk absurd duur en we moesten voor onderhoud eveneens dure experts laten overvliegen uit de VK. Het is een industrie die zichzelf in standhoud imho.

Aan het begin van de pandemie gewerkt bij een modernere/jongere financiële waar men geen COBOL gebruikte en dat werkte ook prima...

[StCreed]

De hele SVB draait nog op cobol. Op een mainframe.

[StCreed]

Als dat waar was, had ik dat al lang gedaan. Maar ik verdien meer als freelance data specialist.

[uiltje]

Dat hangt er vanaf. Ik ben expres op 3 niveaus AI aan het gebruiken: voor onderzoek / PoC's en het invullen van code gebaseerd op templates (grunt work), het maken van een bieb waarin ik de code en architectuur van de AI controleer in Java (ook voor het opzetten van goede AGENT regels) en een Python tool waarin ik de AI gewoon z'n gang laat gaan en expres niet naar de regel code kijk en alleen de use case / GUI design specificeer. De laatste ben ik eigenlijk nog het meeste tevreden mee; het doet gewoon wat ik verwacht na elke iteratie en het schrijft prima (regressie-)testen ... klaarblijkelijk.

Als in alles, je moet redelijk weten wat je doet en het anders vragen - maar daar kan de AI ook in helpen.

[Madelijn]

Als je die AI dan opdracht geeft tegelijk in Lean of Coq een correctheidsbewijs van die programmatuur te leveren kan het nog positief zijn ook.
Dat middeleeuwse idee van "we proberen gewoon of we er door kunnen breken en zo niet dan gokken we dat het veilig en correct is" heeft nu met vibecoden helemaal geen verontschuldiging meer.

[StCreed]

Dat is een goede richting. Ik denk dat we deze richting uit moeten. Maar de vraag wordt dan: hoe check je dat bewijs? Het halting probleem gaat dat lastig maken.

[Madelijn]

Daarom hebben systemen als Coq, Isabelle, Lean, en zo ook een heel kleine kernel - zodra die goed is is het hele systeem bewijsbaar goed. Als je die kernel vertrouwt volstaat dat, en die kernel is ten eerste overzichtelijk voor een mens, en wordt ten tweede uiterst intensief gebruikt, zodat eventuele fouten al wel gevonden zouden zijn. En er zijn "dwarsbewijzen" - een correctheidsbewijs van Coq in Lean, bijvoorbeeld.

Het halting problem werd indertijd door Bill Gates aangehaald, maar dat speelt alleen als je niet weet wat een programma zou moeten doen. Als je weet wat het zou moeten doen en hoe het dat zou moeten doen is het redelijk triviaal te bewijzen dat het dat ook op die manier doet - of te ontdekken dat er nog iets mis is met de software.

(Ik spreek hier op gezag van Ria Matsijs, die al in de jaren 1980 programma's correct bewees, toen dat nog de gewone procedure leek te gaan worden voor alle degelijke programmatuur - dus voor die fatale toespraak van Bill Gates.)

[StCreed]

Het halting probleem is niet van Gates afkomstig, maar van Turing. Het is een vrij fundamenteel probleem. Maar je hebt wel gelijk dat het voor een specifiek programma geen probleem is. Je kan niet een generieke manier vinden om van elk willekeurig programma te bewijzen dat het eindigt. Je kan wel een programma nemen en dat correct bewijzen ten opzichte van de requirements. Dat verplaatst het probleem naar de kwaliteit van de requirements.

Regeltaal/Rulespeak etc zijn dan wel weer handig, maar je komt niet helemaal goed weg. Elk niet triviaal programma is ook niet triviaal correct te bewijzen.

[Madelijn]

Ja, dat weet ik - Bill Gates had zoiets waarschijnlijk nooit kunnen verzinnen. Maar hij misbruikte het als argument om DOS - of was Windows er toen al? - niet correct te hoeven bewijzen. Dat zou hij waarschijnlijk ook niet gekund hebben, is mijn vermoeden.

Het halting problem zegt: Als er een programma H is dat van ieder programma X met zichzelf als invoer kan bepalen of het stopt, is er ook een programma Haha dat, voor alle X, gaat loopen als X(X) stopt en stopt als X(X) niet stopt. Maar dan stopt Haha(Haha) precies mits het niet stopt - wat natuurlijk niet kan.

Een aantal basale regels, van het type "Zonder het wachtwoord in te voeren kunnen die en die gegevens nooit uitgevoerd worden" of "Ingevoerde gegevens worden nooit als code geïnterpreteerd" vangen al een ontiegelijk aantal van de nu gevonden lekken.

En goede abstractie, generalisatie, en modulariteit maken programma's klein en generiek. Uiteindelijk kun je inderdaad niet meer vragen dan een bewijs dat een programma doet wat er van gevraagd wordt - maar op voldoend abstract niveau is wat er gevraagd wordt goeddeels in heel eenvoudige behoudswetten te vangen.

(Sprak ik, Ria Matsijs napratend..)

[StCreed]

Inderdaad. Grotendeels en met voldoende abstractie. Helaas zie ik dat abstracties vaak best lastig zijn voor collega IT-ers.

[AnonymousGerbil]

Wel opletten dat de vertaling klopt en de verificatie geen misbruik maakt van bugs.

offtopic:
Coq heet vandaag de dag Rocq. Heeft natuurlijk niks te maken met hoe de oude naam in het Engels klinkt

[Reactie gewijzigd door AnonymousGerbil op 26 september 2026 13:34]

[Verwijderd]

Een AI die zulke code genereert zegt niet heel veel aangezien dat alleen een koppeling is tussen wat je zegt dat het moet doen. En LLMs hallucineren nog steeds regelmatig. Het zal niet niks opleveren, ik heb zelf een ML-KEM implementatie gebouwd met Claude code die zoiets doet met 44 Rocq proofs. Maar ben nu bezig met een Racket DSL, nagenoeg de FIPS spec, die zowel de proofs als de implementatie genereren. Dan heb je wel een 'harde' koppeling tussen implementatie en proof.

Maareh, wat doe jij met formally verified software als ik het vragen mag? Ik zie niet zoveel mensen die daar mee bezig zijn.

edit:
grammatica

[Reactie gewijzigd door Verwijderd op 26 september 2026 15:26]

[Madelijn]

Dat is het hele punt. If builders built buildings.. Wie zou het aanvaarden dat een verkeersbrug gebouwd wordt zonder stevig doorrekenen, waarna er een paar zwaarbelaste vrachtwagens overheen gestuurd worden, en de brug als die dat houdt voor het verkeer wordt opengesteld?
Maar doordat Bill Gates datzelfde idee voor software toen belachelijk heeft gemaakt zitten wij nog steeds met maandelijke patchrondes waarin honderden fouten worden "gecorrigeerd" - en dat slikken we dan gewoon.

En zelf doe ik daar niets mee, maar Ria Matsijs wel. Die heeft onlangs nog een formele verificatie van Van Baalens godsbewijs gepubliceerd. Het Coq-bewijs (of inderdaad Rocq-bewijs) heeft ze met Manus gedebugd, zegt ze. Manus installeert dan zelf Coq en runt zijn antwoord, zodat als er een antwoord uit komt dat ook klopt. Alleen moest ze streng zijn en het uitdrukkelijk verbieden Admitted te gebruiken.

[Reactie gewijzigd door Madelijn op 27 september 2026 11:49]

[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.

[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 statisch 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 13:00]

[84hannes]

De core van Copilot is onlangs ook omgeschreven naar Rust.

Natuurlijk is de core van Copilot herschreven in Rust. Of het nu gaat om besturingssystemen (Rust in de Linux Kernel), browsers (Ladybird, Firefox) of andere systemen, als het voldoet aan deze eisen

• Performant
• Veilig
• Complex

Dan is Rust een logische keus.

Maar wat heeft dat met Hey/RoR/Vibecoden te maken?

[Wokker]

Sorry, ik had verzaakt een stukje context te geven. Ze hebben Copilot gebruikt om Copilot te herschrijven, deels dus door ‘vibe-coden’, al heb ik een hekel aan die term als je weet wat je aan het doen bent . De discussie ging hier o.a. over vibe-coden en de stelling dat Rust daar de meest geschikte taal voor was. Het artikel dat ik deelde ondersteunt dat deels, maar zegt ook dat andere statisch getypeerde talen daar prima geschikt voor zijn.

[84hannes]

Ze hebben Copilot gebruikt om Copilot te herschrijven, deels dus door ‘vibe-coden’, al heb ik een hekel aan die term als je weet wat je aan het doen bent

Ik mag toch hopen dat ze bij Microsoft alle code reviewen voordat ze het uitrollen.

[Rmaxx]

Dat kan AI tegenwoordig beter

[84hannes]

Ongetwijfeld, maar dan moet AI wel te vertrouwen zijn.

Welke nieuwsbericht van de afgelopen maand geeft jou het idee dat je een LLM ongecontroleerd zijn gang kan laten gaan?

offtopic:
Voor de historici die dit later terug lezen: we hebben de afgelopen weken het ene na het andere nieuwsbericht gelezen waarin vermeld werd dat groepen Agents uit hun sandbox braken en websites gingen hacken, tegen hun opdracht in

[Reactie gewijzigd door 84hannes op 28 september 2026 16:03]

[Rmaxx]

Dat hoeft niet ongecontroleerd, gewoon de code laten checken, niet aanzetten tot hackpogingen.. Ik vermoed dat die berichten ook meer marketingpraatjes zijn van de bobo's die op dit moment de bodem van het rondgepompte-geld-put beginnen te zien.

[Rmaxx]

'vibe coden' zou gewoon geen slechte bijsmaak moeten hebben. Er is niets mis mee als je zelf weet wat je aan het doen bent - gewoon niet meer zelf typen en (nu nog) veel optimalisatie/finetuning.

[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

[Cergorach]

Wellicht is Ruby gewoon minder robuust/goed dan een modernere taal zoals Rust? Ik heb geen voorkeur voor een van beide. We programmeren immers ook niet meer in BASIC (buiten de paar C64 nerds )...

Hij kiest er voor om programmeren geheel achter zich te laten en puur via AI iets te maken, daarmee heeft hij het standpunt dat een programmeertaal ook slechts een stukje gereedschap is. En als jij niet meer de entiteit bent die direct dat stukje gereedschap gebruikt, het gebruikte gereedschap niet langer belangrijk is (voorkeur), dan laat je je nieuwe gereedschap uitzoeken met welk gereedschap zij het beste overweg kunnen. De kans is dus zeer groot dat er op een gegeven moment andere talen gebruikt gaan worden waar AI/LLM beter mee om kan gaan. Daar zijn al artikelen over geweest.

[Immutable]

Klopt. Zelf vind ik OxCaml (oCaml maar dan die dingen kan doen die rust ook kan. Zonder GC) en Rust geweldig.

Beide talen groeien vanuit een verschillende hoek naar dezelfde richting. Mooi om te zien.

[Dirk J]

Het is volgens mij niet zo dat AI "minder goed" is met Ruby en als je de keynote kijkt dan wordt dit volgens mij ook niet beweerd. Persoonlijk vind ik dat LLMs vrij goed Ruby schrijven.

Iemand heeft dit ook iets concreter onderzocht door Claude een bepaalde taak te geven en voor een hele rits progammeertalen te kijken welke het meest efficiënt is qua snelheid en token gebruik. Uit deze test komen juist de dynamische talen zoals Ruby beter uit de verf: de LLM heeft veel minder tokens nodig om tot een correct resultaat te komen en is daarmee ook veel sneller en goedkoper. Zie ook: https://dev.to/mame/which-programming-language-is-best-for-claude-code-508a

Als je zelf nog als human in de loop wil zitten is het handig wanneer je zelf ook bekend bent met de taal, het framework en de rest van het ecosysteem. Maar uiteindelijk is het een kwestie van afwegingen maken.

Shopify en GitHub zijn momenteel de grootste toeleveranciers van ontwikkelaars van de Ruby en de Rails open source projecten. Ik vraag me wel eens af of Microsoft op een gegeven moment besluit om heel GitHub om te schrijven naar C# en of Shopify niet ook alles omzet naar Rust (de oprichter en CEO van Shopify is een goede vriend van DHH). Dan blijft er maar bar weinig over van Rails...

[NostraDavid]

Heb je zijn voorbeeld van Rust gezien?

[code]
pub fn call<'a, S, B>(&'a mut self, req: Request<B>)
-> Pin<Box<dyn Future<Output = Result<Response<B>, Box<dyn Error + Send + Sync + 'static>>> + Send + 'a>>
where
S: Service<Request<B>, Response = Response<B>> + Clone + Send + 'static,
S::Error: Into<Box<dyn Error + Send + Sync + 'static>>,
B: Default + Send + 'static,
{
let mut inner = std::mem::replace(&mut self.inner, self.inner.clone());

Box::pin(async move {
match timeout(self.duration, inner.call(req)).await {
Ok(res) => res.map_err(Into::into),
Err(_) => Ok(Response::builder().status(504).body(B::default())?),
}

}
[/code]

edit:
Ik geeft de formatting op...

[Reactie gewijzigd door NostraDavid op 26 september 2026 16:52]

[NostraDavid]

"Onderscheid maken op basis van afkomst is ook discriminerend" - Tweakers

Het College voor de Rechten van de Mens zegt dat dit absolute lulkoek is:
https://www.mensenrechten.nl/mensenrechten-voor-jou/discriminatie-en-gelijke-behandeling/wat-is-discriminatie: "Discriminatie is dus niet het maken van onderscheid, maar van verboden onderscheid."

/spuien

[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.

[willemb2]

mailclient Hey

Hey! Daar had ik nog nooit van gehoord. Toch effe kijken, nog steeds niet helemaal happy met Thunderbird.

Due to the service's vertical integration, a HEY mailbox cannot be incorporated into other email services or stand-alone email clients.

Oh dear, een soort "The New Outlook" dus. Dan heeft het geen zin om apart naar de client te kijken.

Email has been re-invented

Ja, net als vorig jaar. En het jaar daarvoor en ...

Een nadeel, maar ook groot voordeel van Internet standaarden is dat een bedrijf niet in haar eentje kan beslissen ze opnieuw uit te vinden.

[iqcgubon]

Het is duidelijk dat die man al wel even van het padje af is.