Ask HN: Why hasn't x86 caught up with Apple M series?
450 points by stephenheron 7d ago 620 comments
Ask HN: Did Developers Undermine Their Own Profession?
8 points by rayanboulares 20h ago 16 comments
Unix co-creator Brian Kernighan on Rust, distros and NixOS
38 MilnerRoute 17 8/31/2025, 5:20:55 PM thenewstack.io ↗
In reality the subject of the talk is Kernighan’s perspective of the history of Unix at Bell Labs. The questions covered in the article are the least interesting part, and make up about six minutes at the very end—a small fraction not just of the 70-minute video, but even of the 30-minute Q&A session.
In short, the headline and article are disappointing clickbait, but the video itself is worth watching for Kernighan’s relating of history and his theories about what confluence of factors made Unix successful (collegial environment, good management, overall mission…).
Another worthwhile video from the same conference (in a different year) is Kernighan’s interview of Ken Thompson: https://www.youtube.com/watch?v=EY6q5dv_B-o&pp=ygUSdmNmIGVhc...
here is what he said, which i got from the writeup at this newstack.io article, which I had found via the discussion at Slashdot https://developers.slashdot.org/story/25/08/30/044226/what-h...
Rust Replacing C?
It was a moment for the ages. “Do you think there’s any sort of merit to Rust replacing C?” one audience member asked, a frequent topic on TNS.
“Or is this just a huge hype bubble that’s waiting to die down?”
In a world that’s been earnestly transitioning for years to more memory-safe languages, the answer from a long-time booster of C — for over half a century — promised to be nothing short of iconic.
“Ohhh, Rust,” Kernigham said, to audience laughter.
‘”I have written only one Rust program, so you should take all of this with a giant grain of salt,” he said. “And I found it a — pain… I just couldn’t grok the mechanisms that were required to do memory safety, in a program where memory wasn’t even an issue!”
Yet his biggest complaint about Rust seemed to be its performance — an especially damning complaint from a man whose early career started on a 16-bit PDP 11/20.
Digital_PDP11-20 front panel - IMG_1498_cropped - Creative Commons via Wikipedia - author Rama and Musee Bolo
Speaking of Rust, Kernighan said “The support mechanism that went with it — this notion of crates and barrels and things like that — was just incomprehensibly big and slow.”
“And the compiler was slow, the code that came out was slow…”
All in all, Kernighan had had a bad experience. “When I tried to figure out what was going on, the language had changed since the last time somebody had posted a description! And so it took days to write a program which in other languages would take maybe five minutes…”
It was his one and only experience with the language, so Kernighan acknowledged that when it comes to Rust “I’m probably unduly cynical.
“But I’m — I don’t think it’s gonna replace C right away, anyway.”
My knowledge of AWK is a bit rusty but I don't think thinking in AWK is compatible with thinking in Rust.
[1] https://en.wikipedia.org/wiki/Brian_Kernighan
That rings a bell. Rust will be much better if it will stick to a stable ABI. We have enough CADT. You found the holy language grail ? Just not deprecate the old stuff.
> ‘”I have written only one Rust program, so you should take all of this with a giant grain of salt,” he said. “And I found it a — pain… I just couldn’t grok the mechanisms that were required to do memory safety, in a program where memory wasn’t even an issue!”
Also that Rust is slow. That is not nothing.
It's like if I took my brief experiences writing C in uni and summarised it was "it's a pain getting all the different files to compile, and I couldn't work out how to import any useful dependencies" - it's not necessarily a _wrong_ opinion, but clearly it's not a useful one. I just don't have enough experience with C to be able to give you a meaningful opinion on it. It sounds like Kernighan is in a similar boat with Rust.
Also some of his comments sound surprising, like there's more context that he didn't communicate or wasn't aware of. For example, Rust code typically performs as quickly as C code (sometimes faster, sometimes slower, depending on various details, but typically they are very similar). But his impression of Rust was that the resulting code was slow, which maybe suggests he was writing quite strange code to begin with, or that he didn't know how to get Rust to compile in release mode or something like that. My hunch is that he was trying out Rust, but also wasn't especially invested in learning it (which is fair enough!) and so maybe missed some stuff that would seem obvious to other new users. Like I said, I did much the same in university when learning C, and as a result simply don't have an informed opinion there.
In the end, the guy has written one program and was completely up front about how that does not make him an expert either in how great Rust is, or how terrible it is. Which is a sensible approach to take.