More from David Heinemeier Hansson
The appeal of "vibe coding" — where programmers lean back and prompt their way through an entire project with AI — appears partly to be based on the fact that so many development environments are deeply unpleasant to work with. So it's no wonder that all these programmers stuck working with cumbersome languages and frameworks can't wait to give up on the coding part of software development. If I found writing code a chore, I'd be looking for retirement too. But I don't. I mean, I used to! When I started programming, it was purely because I wanted programs. Learning to code was a necessary but inconvenient step toward bringing systems to life. That all changed when I learned Ruby and built Rails. Ruby's entire premise is "programmer happiness": that writing code should be a joy. And historically, the language was willing to trade run-time performance, memory usage, and other machine sympathies against the pursuit of said programmer happiness. These days, it seems like you can eat your cake and have it too, though. Ruby, after thirty years of constant improvement, is now incredibly fast and efficient, yet remains a delight to work with. That ethos couldn't shine brighter now. Disgruntled programmers have finally realized that an escape from nasty syntax, boilerplate galore, and ecosystem hyper-churn is possible. That's the appeal of AI: having it hide away all that unpleasantness. Only it's like cleaning your room by stuffing the mess under the bed — it doesn't make it go away! But the instinct is correct: Programming should be a vibe! It should be fun! It should resemble English closely enough that line noise doesn't obscure the underlying ideas and decisions. It should allow a richness of expression that serves the human reader instead of favoring the strictness preferred by the computer. Ruby does. And given that, I have no interest in giving up writing code. That's not the unpleasant part that I want AI to take off my hands. Just so I can — what? — become a project manager for a murder of AI crows? I've had the option to retreat up the manager ladder for most of my career, but I've steadily refused, because I really like writing Ruby! It's the most enjoyable part of the job! That doesn't mean AI doesn't have a role to play when writing Ruby. I'm conversing and collaborating with LLMs all day long — looking up APIs, clarifying concepts, and asking stupid questions. AI is a superb pair programmer, but I'd retire before permanently handing it the keyboard to drive the code. Maybe one day, wanting to write code will be a quaint concept. Like tending to horses for transportation in the modern world — done as a hobby but devoid of any economic value. I don't think anyone knows just how far we can push the intelligence and creativity of these insatiable token munchers. And I wouldn't bet against their advance, but it's clear to me that a big part of their appeal to programmers is the wisdom that Ruby was founded on: Programming should favor and flatter the human.
The web will be far worse off if Google is forced to sell Chrome, even if it's to atone for legitimate ad-market monopoly abuses. Which mean we'll all be worse off as the web would lose ground to actual monopoly platforms, like the iOS App Store and Google's own Play Store. First, Chrome won the browser war fair and square by building a better surfboard for the internet. This wasn't some opportune acquisition. This was the result of grand investments, great technical prowess, and markets doing what they're supposed to do: rewarding the best. Besides, we have a million alternatives. Firefox still exists, so does Safari, so does the billion Chromium-based browsers like Brave and Edge. And we finally even have new engines on the way with the Ladybird browser. Look, Google's trillion-dollar business depends on a thriving web that can be searched by Google.com, that can be plastered in AdSense, and that now can feed the wisdom of AI. Thus, Google's incredible work to further the web isn't an act of charity, it's of economic self-interest, and that's why it works. Capitalism doesn't run on benevolence, but incentives. We want an 800-pound gorilla in the web's corner! Because Apple would love nothing better (despite the admirable work to keep up with Chrome by Team Safari) to see the web's capacity as an application platform diminished. As would every other owner of a proprietary application platform. Microsoft fought the web tooth and nail back in the 90s because they knew that a free, open application platform would undermine lock-in — and it did! But the vitality of that free and open application platform depends on constant development. If the web stagnates, other platforms will gain. But with Team Chrome pushing the web forward in a million ways — be it import maps, nested CSS, web push, etc. — is therefore essential. This is a classic wealth vs. riches mistake. Lawyers see Chrome as valuable in a moment's snapshot, but the value is all in the wealth that continued investment brings. A Chrome left to languish with half the investment will evaporate as quickly as a lottery winner's riches. Wealth requires maintenance to endure. Google should not get away with rigging the online ad market, but forcing it to sell Chrome will do great damage to the web.
We received over 2,200 applications for our just-closed junior programmer opening, and now we're going through all of them by hand and by human. No AI screening here. It's a lot of work, but we have a great team who take the work seriously, so in a few weeks, we'll be able to invite a group of finalists to the next phase. This highlights the folly of thinking that what it'll take to land a job like this is some specific list of criteria, though. Yes, you have to present a baseline of relevant markers to even get into consideration, like a great cover letter that doesn't smell like AI slop, promising projects or work experience or educational background, etc. But to actually get the job, you have to be the best of the ones who've applied! It sounds self-evident, maybe, but I see questions time and again about it, so it must not be. Almost every job opening is grading applicants on the curve of everyone who has applied. And the best candidate of the lot gets the job. You can't quantify what that looks like in advance. I'm excited to see who makes it to the final stage. I already hear early whispers that we got some exceptional applicants in this round. It would be great to help counter the narrative that this industry no longer needs juniors. That's simply retarded. However good AI gets, we're always going to need people who know the ins and outs of what the machine comes up with. Maybe not as many, maybe not in the same roles, but it's truly utopian thinking that mankind won't need people capable of vetting the work done by AI in five minutes.
The new AMD HX370 option in the Framework 13 is a good step forward in performance for developers. It runs our HEY test suite in 2m7s, compared to 2m43s for the 7840U (and 2m49s for a M4 Pro!). It's also about 20% faster in most single-core tasks than the 7840U. But is that enough to warrant the jump in price? AMD's latest, best chips have suddenly gotten pretty expensive. The F13 w/ HX370 now costs $1,992 with 32GB RAM / 1TB. Almost the same an M4 Pro MBP14 w/ 24GB / 1TB ($2,199). I'd pick the Framework any day for its better keyboard, 3:2 matte screen, repairability, and superb Linux compatibility, but it won't be because the top option is "cheaper" any more. Of course you could also just go with the budget 6-core Ryzen AI 5 340 in same spec for $1,362. I'm sure that's a great machine too. But maybe the sweet spot is actually the Ryzen AI 7 350. It "only" has 8 cores (vs 12 on the 370), but four of those are performance cores -- the same as the 370. And it's $300 cheaper. So ~$1,600 gets you out the door. I haven't actually tried the 350, though, so that's just speculation. I've been running the 370 for the last few months. Whichever chip you choose, the rest of the Framework 13 package is as good as it ever was. This remains my favorite laptop of at least the last decade. I've been running one for over a year now, and combined with Omakub + Neovim, it's the first machine in forever where I've actually enjoyed programming on a 13" screen. The 3:2 aspect ratio combined with Linux's superb multiple desktops that switch with 0ms lag and no animations means I barely miss the trusted 6K Apple XDR screen when working away from the desk. The HX370 gives me about 6 hours of battery life in mixed use. About the same as the old 7840U. Though if all I'm doing is writing, I can squeeze that to 8-10 hours. That's good enough for me, but not as good as a Qualcomm machine or an Apple M-chip machine. For some people, those extra hours really make the difference. What does make a difference, of course, is Linux. I've written repeatedly about how much of a joy it's been to rediscover Linux on the desktop, and it's a joy that keeps on giving. For web work, it's so good. And for any work that requires even a minimum of Docker, it's so fast (as the HEY suite run time attests). Apple still has a strong hardware game, but their software story is falling apart. I haven't heard many people sing the praises of new iOS or macOS releases in a long while. It seems like without an asshole in charge, both have move towards more bloat, more ads, more gimmicks, more control. Linux is an incredible antidote to this nonsense these days. It's also just fun! Seeing AMD catch up in outright performance if not efficiency has been a delight. Watching Framework perfect their 13" laptop while remaining 100% backwards compatible in terms of upgrades with the first versions is heartwarming. And getting to test the new Framework Desktop in advance of its Q3 release has only affirmed my commitment to both. But on the new HX370, it's in my opinion the best Linux laptop you can buy today, which by extension makes it the best web developer laptop too. The top spec might have gotten a bit pricey, but there are options all along the budget spectrum, which retains all the key ingredients any way. Hard to go wrong. Forza Framework!
More in programming
For many years now, I’ve been using an old YubiKey along with the free tier of Duo Security to add a second factor to my SSH logins. This is klunky, and has a number of drawbacks (dependency on a cloud service and Internet among them). I decided it was time to upgrade, so I recently … Continue reading How to Use SSH with FIDO2/U2F Security Keys →
RST defaults to high This is an addendum to the article about Espressif’s automatic reset. In that article, we observed the effect of the RST pin on the ESP32-S2-Saola-1RI board: I skipped over this topic quickly, so I am now taking the time to explain how the RST pin manages to have a defined behavior … Continue reading The ESP32-S2 reset pin → The post The ESP32-S2 reset pin appeared first on Quentin Santos.
We build a minimal X86 assembly program, run it… and hit a crash. But that crash is exactly what makes this program worth writing.
In 2023 I attended RubyKaigi for the first time and also wrote my first recap, which I’m pleased to say was well-received! This was my third time attending RubyKaigi, and I was once again really impressed with the event. I’m eternally grateful to the conference organizers, local organizers (organizers recruited each year who live/lived in the area RubyKaigi is held), designers, NOC team, helpers, sponsors, speakers, and other attendees for helping create such a memorable experience, not just during the three day conference, but over my entire time in Matsuyama. What is RubyKaigi? RubyKaigi is a three-day technology conference focused on the Ruby programming language, held annually “somewhere in Japan.” It attracts a global audience and this year welcomed over 1500 attendees to Matsuyama, Ehime. The traveling nature of the conference means that for the majority of the attendees (not just the international ones), it’s a chance to take a trip—and the days leading up to and following the event are full of fun encounters with other Rubyists as we wander around town. Checking social media a few days before the conference, I saw posts tagged with “RubyKaigi Day –3” and started getting FOMO! Talks RubyKaigi featured 3 keynotes, 51 talks, 11 Lightning talks, the TRICK showcase, and Ruby Committers and the World. There were talks in the Main Hall, Sub Hall, and Pearls Room, so you frequently had 3 options to choose from at any given time. Despite being held in Japan, RubyKaigi is an international conference that welcomes English speakers; all talks in the Sub Hall are in English, for example, and all the Japanese talks also have real-time translation and subtitles. Organizers put a great deal of thought into crafting the schedule to maximize everyone’s chances of seeing the talks they’re interested in. For example, every time slot has at least one English and one Japanese talk, and colleagues are scheduled to speak at different times so their work friends don’t have to split their support. The power of pre-study One great feature of RubyKaigi is its esoteric talks, delivered by speakers who are enthusiastic experts in their domains. I’m more of a Ruby user than a Ruby committer (the core team who have merge access to the Ruby repository), so every year there are talks during which I understand nothing—and I know I’m not alone in that. One of the topics I struggle with is parsers, so before the conference I created these sketch notes covering “How Do Computers Understand Ruby?”. Then, as I was listening to previously incomprehensible talks I found myself thinking, “I know this concept! I can understand! Wow, that’s cool!” Sketch notes on "How do Computers Understand Ruby" My plan for next year is to organize my schedule as soon as RubyKaigi’s talks are announced, and create a pre-conference study plan based on the talks I’m going to see. Just when I thought I’d leveled up, I attended Ryo Kajiwara’s talk “You Can Save Lives with End-to-End Encryption in Ruby,” where he talked about the importance of end-to-end encryption and told us all to stop using SMTP. It was a humbling experience because, after the first few slides, I couldn’t understand anything. Ruby taught me about encoding under the hood This year’s opening keynote was delivered by Mari Imaizumi, who took us on the journey of how converting the information you want to convey into symbols has been a thing since basically forever, as well as how she originally got interested in encoding. She talked about the competing standards for character encoding, and her experience with Mojibake. It made me think about how lucky I am, that the internet heavily favours English speakers. Even when I was exploring the Web in the 2000s, it was rare for me to come across content scrambled by encoding. TRICK 2025: Episode I There was a point at which it seemed like the awards were going to be a one-man-show, as Pen-san took the fifth, fourth, and third places, but the first-place winner was Don Yang, who until then hadn’t received any awards. The moment that stood out for me, though, was when Pen-san was talking about his work that won “Best ASMR”: code in the shape of bubbles that produces the sound of ocean waves when run. Pen-san explained how the sound was made and said something like, “Once you know this, anyone can write this code.” To his right you could see Matz waving his arm like, “No, no!” which captured my own feelings perfectly. Drawing of Pen san and Matz ZJIT: building a next-generation Ruby JIT Maxime Chevalier-Boisvert started her talk by apologising for YJIT not being fast enough. Because YJIT is hitting a plateau, she is now working on ZJIT. While YJIT uses a technique called Lazy Basic Block Versioning, ZJIT is method-based JIT. It will be able to “see” more chunks of code and thus be able to optimize more than YJIT. Ruby committers and the world There were humorous moments, like when the panel was asked, “What do you want to depreciate in Ruby 4.0?” Matz answered, “I don’t want to depreciate anything. If stuff breaks people will complain to me!” Also, when the question was, “If you didn’t have to think about compatibility, what would you change?” the committers started debating the compatibility of a suggested change, leading the moderator to say committers are always thinking about compatibility. Matz ended this segment with the comment that it might seem like there’s a big gap between those on stage and those in the audience, but it’s not that big—it’s something that you can definitely cross. Sketch notes for Ruby Committers and The World Eliminating unnecessary implicit allocations Despite this being an unfamiliar topic for me, Jeremy Evans explained things so well even I could follow along. I really liked how approachable this talk was! Jeremy shared about how he’d made a bug fix that resulted in Ruby allocating an object where it hadn’t allocated one before. Turns out, even when you’re known for fixing bugs, you can still cause bugs. And as he fixed this case, more cases were added to the code through new commits. To prevent new code changes from adding unnecessary allocations, he wrote the “Allocation Test Suite,” which was included in the Ruby 3.4 release. Optimizing JRuby 10 JRuby 10 is Ruby 3.4 compatible! What stood out to me the most was the slide showing a long list of CRuby committers, and then three committers on the JRuby side: Charles Nutter (the speaker), his friend, and his son. This was one of those talks where the pre-study really helped—I could better understand just what sort of work goes into JRuby. Itandi’s sponsor lightning talk Usually sponsors use their time to talk about their company, but the speaker for Itandi spent most of his time introducing his favorite manga, Shoujiki Fudousan. He encouraged us to come visit the Itandi booth, where they had set up a game in which you could win a copy of the manga. Sponsors This year there were a total of 102 sponsors, with so many gold and platinum-level sponsors the organizers held a lottery for the booths. To encourage attendees to visit each booth, there was once again a stamp rally with spaces for all 46 booths, although you could reach the pin-badge goal with just 35 stamps. It also helped keep track of where you had/hadn’t been. Since sponsors are an invaluable part of the conference, and they put so much effort into their booths, I always want to be able to show my appreciation and hear what each of them have to say. With 46 to visit, though, it was somewhat difficult! Each booth had plenty of novelties to hand out and also fun activities, such as lotteries, games, surveys and quizzes, and coding challenges. By day three, though, the warm weather had me apologetically skipping all coding challenges and quizzes, as my brain had melted. For me, the most memorable novelty was SmartHR’s acrylic charm collection! Since they missed out on a booth this year, they instead created 24 different acrylic charms. To collect them, you had to talk to people wearing SmartHR hoodies. I felt that was a unique solution and a great icebreaker. Collection of SmartHR acrylic charms I actually sent out a plea on X (Twitter) because I was missing just a few charms—and some SmartHR employees gave me charms from their own collection so I could complete the set! (Although it turns out I’m still missing the table-flipping charm, so if anyone wants to help out here . . . ) Hallway track (Events) Every year RubyKaigi has various official events scheduled before and after the conference. It’s not just one official after party—this year there were lunches, meetups, drinkups, board games, karaoke, live acts until three a.m., morning group exercises (there’s photographic proof of people running), and even an 18-hour ferry ride. I need sleep to understand the talks, and I need to wake up early because the conference is starting, and I need to stay up late to connect with other attendees! The official events I attended this year were SmartHR’s pre-event study session, the Women and Non-binary Dinner, the RubyKaigi Official Party, the STORES CAFE for Women, the Leaner Board Game Night, RubyKaraoke, RubyMusicMixin 2025 and the codeTakt Drinkup. I got to chat with so many people, including: Udzura-san, who inspired my Ruby study notes; Naoko-san, one of STORES’s founders; and Elle, a fellow Australian who traveled to Japan for RubyKaigi! The venues were also amazing. The official party was in a huge park next to Matsuyama Castle, and the board game event took place in what seemed to be a wedding reception hall. Compared to the conference, where you are usually racing to visit booths or heading to your next talk, it’s at these events you can really get to know your fellow Rubyists. But it’s not just about the official events; my time was also full of random, valuable catch ups and meetings. For lunch, I went out to eat tai meshi (sea bream rice) with some of the ladies I met at the dinner. I was staying at emorihouse, so following the after party we continued drinking and chatting in our rooms. After RubyMusicMixin, I didn’t want the night to end and bumped into a crew headed towards the river. And on day four, the cafe I wanted to go to was full, but I got in by joining Eririn-san who was already seated. That night I ended up singing karaoke with a couple of international speakers after running into them near Dogo Onsen earlier that day. Part of the joy of RubyKaigi is the impromptu events, the ones that you join because the town is so full of Rubyists you can’t help but run into them. I organised an event! This year I organised the Day 0 Women and Non-binary Dinner&DrinkUp. We were sponsored by TokyoDev, and we had a 100 percent turnout! I’m grateful to everyone who came, especially Emori-san who helped me with taking orders and on-the-day Japanese communications. With this event, I wanted to create a space where women and non-binary people–whether from Japan or overseas, RubyKaigi veterans or first-timers—could connect with each other before the conference started, while enjoying Matsuyama’s local specialities. We’re still a minority among developers, so it was exciting for me to see so many of us together in one place! Group photo from Women & Non-binary Dinner and DrinkUp! I’d love to host a similar event next year, so if you or your company is interested in sponsoring, please reach out! Matz-yama (Matsuyama) Last year’s RubyKaigi closed with the announcement that “We’ve taken Matz to the ocean [Okinawa], so now it’s time to take him to the mountains.” (Yama means “mountain” in Japanese.) Matsuyama city is located in Ehime, Shikoku, and its famous tourist attractions include Matsuyama Castle and Dogo Onsen, which is said to have inspired the bathhouse in Spirited Away. RubyKaigi banner on display at Okaido Shipping Street Ehime is renowned for mikan (蜜柑, mandarin oranges), and everywhere you go there is mikan and Mikyan, Ehime’s adorable mascot character. Before arriving, everyone told me, “In Ehime, mikan juice comes out of the tap,” which I thought meant there were literally pipes with mikan juice flowing through them all over Ehime! However, reality is not so exciting: yes, mikan juice does flow from taps, but there’s clearly a container behind the tap! There’s no underground mikan juice pipe network. 😢 RubyKaigi also highlighted Ehime’s specialties. This year’s theme color was red-orange, break-time snacks were mikan and mikan jelly, the logo paid homage to the cut fruit, and one of the sponsors even had a mikan juice tap at their booth! Also, included among this year’s official novelties was a RubyKaigi imabari towel, since Imabari city in Ehime is world famous for their towels. I’m an absolute fan of how RubyKaigi highlights the local region and encourages attendees to explore the area. Not only does this introduce international attendees to parts of Japan they might otherwise not visit, it’s a chance for local attendees to play tourist as well. Community In Matz’s closing keynote, Programming Language for AI Age, he touched on how it’s odd to delegate the fun tasks to an AI. After all, if AI does all the fun things and we do all the hard things, where’s the joy for us in that? To me, creating software is a collaborative activity—through collaboration we produce better software. Writing code is fun! Being able to connect with others is fun! Talking to new people is fun! I’ve met so many amazing people through the Ruby community, and RubyKaigi has played an important role in that. Through the community I’ve gotten advice, learned new things, and shared resources. My sketch-notes have been appreciated by others, and as I walk around there are #rubyfriends everywhere who all make me feel so welcomed. RubyKaigi attracts a variety of attendees: developers and non-developers, Ruby experts and Ruby beginners. It’s a fun conference with a wonderful community, and even though it’s a technical conference, non-technical people can enjoy participating as well. Community growth comes with its own issues, but I think attracting newcomers is an important aspect of RubyKaigi. As someone who first came as a developer completely new to Ruby, every year I learn more and am inspired to give back to the Ruby community. I hope that RubyKaigi continues to inspire participants to love Ruby, and encourages them to understand and improve it. By growing the Ruby community, we ensure Ruby will continue on as a Programming Language for the AI Age. Looking forward to Hakodate next year, and to seeing you all there! PS: Surprise, Detective Conan? I really love the Detective Conan series. This year RubyKaigi Day Three and the 2025 Detective Conan movie premiere were on the same day . . . so as soon as Matsuda-san said, “It’s over!” I ran out of the hall to go watch the movie at Cinema Sunshine Kinuyama. And next year’s RubyKaigi location, Hakodate, was the setting for the 2024 Detective Conan movie. What a deep connection RubyKaigi and Detective Conan have! Detective Conan decorations set up at the cinema in Kinuyama