What Happened When Unix Co-Creator Brian Kernighan Tried Rust? (thenewstack.io) 58
"I'm still teaching at Princeton," 83-year-old Brian Kernighan recently told an audience at New Jersey's InfoAge Science and History Museums.
And last month the video was uploaded to YouTube, a new article points out, "showing that his talk ended with a unique question-and-answer session that turned almost historic..." "Do you think there's any sort of merit to Rust replacing C?" one audience member asked... "Or is this just a huge hype bubble that's waiting to die down...?"
'"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!" 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."
Kernighan was also asked about NixOS and HolyC — but his formative experiences remain rooted in Bell Labs starts in the 1970s, where he remembers it was "great fun to hang out with these people."
And he acknowledged that the descendants of Unix now power nearly every cellphone. "I find it intriguing... And I also find it kind of irritating that underneath there is a system that I could do things with — but I can't get at it!"
Kernighan answered questions from Slashdot readers in 2009 and again in 2015...
And last month the video was uploaded to YouTube, a new article points out, "showing that his talk ended with a unique question-and-answer session that turned almost historic..." "Do you think there's any sort of merit to Rust replacing C?" one audience member asked... "Or is this just a huge hype bubble that's waiting to die down...?"
'"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!" 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."
Kernighan was also asked about NixOS and HolyC — but his formative experiences remain rooted in Bell Labs starts in the 1970s, where he remembers it was "great fun to hang out with these people."
And he acknowledged that the descendants of Unix now power nearly every cellphone. "I find it intriguing... And I also find it kind of irritating that underneath there is a system that I could do things with — but I can't get at it!"
Kernighan answered questions from Slashdot readers in 2009 and again in 2015...
Seriously? (Score:4, Funny)
What kind of an idiot asks Brian Kernighan something like that?
It's like asking Henry Ford what he thinks of the new Toyota.
Re:Seriously? (Score:5, Insightful)
Re: (Score:3)
At least for what TFS has included, I think he's just more of an old dude set in his ways on that. The semantic differences between C and Rust are huge (also as you might note in my signature, semantics is one of a few major differences between languages that extends beyond syntax, and the very much non-developer who claims to be a developer doesn't even know that -- notice for example that java has quite different semantics from C++, namely Java is mostly implicitly pass by reference, whereas in C++, refer
Re: (Score:2)
Er *ahem* pointers, rather than references, for those C developers that read my post.
Re: (Score:2)
And the claim that C++ references are “explicit” is only partially true, as the & or * syntax is required in declarations, but there is MUCH room for ambiguity
Probably. This is why I don't use C++: The whole thing is jank and just an overall shit language. To quote Linus Torvalds:
C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.
It's funny because it's true!
Though I also don't like Java either. I was forced to use it for about 6 months and longer it went on, the more I realized that it's a language that pretends to be strongly typed but really isn't, you should never expect it to run on different versions of the runtime including just minor releases on the same platform, and if you aren't overly reliant on the r
Re: (Score:2)
I don't know what you were doing, but having to use reflection is generally considered a code smell, if not outright banned in most code bases. Generally its only accepted in serialization libraries. If that's what you got out of working in Java, it sounds more like you were doing it wrong.
Re: (Score:2)
That's utter, abject nonsense. That kind of analyzing C through the lens of the lousy, parasitic concepts that Rust is dealing in is just like how the homeopaths are calling the actual, evidence-based medicine "allopathy".
What would take to change something like ... } foo; ... func(foo)
struct {
in C from a "copy" into a "move" just by changing the "semantics" of the exis
Re: (Score:3)
Re: (Score:1)
So these things he says aren't true? He said that he was being forced to do memory safety when it wasnt even a concern and that the compiler was slow. Was he wrong about that?
Yes. Unless all of your variables are floats and integers on the stack, memory safety is always an issue when you write code in C. (If all of his values were actually floats and integers on the stack, he would have had no problem writing the Rust code either.)
Re: (Score:3)
Re: (Score:2)
He said it would have taken about 5 minutes in C, so I think you're right.
Re: (Score:2)
Or rather, that he was writing one that could be written with a leak. You can't access freed memory if you never free memory, and short programs can often get away with that.
Re: (Score:2)
To be fair, memory safety is only an issue if your code has a bug. I just assumed he was writing a short inconsequential program that could be written without a leak.
Memory safety is a pain when you're asked to prove the correctness if your code.
There are things like a subset of C such as MISRA C and static analysis tools that let you do some very limited checking. But it doesn't quite rise to the level of a formal proof.
Re: (Score:2)
You can reduce the parts were memory safety is a concern and encapsulate them. For example, put them into functions and assume them as correct for that proof. Then make very sure the functions are correct and not exploitable. Gives you only partial correctness, but still. One big problem is that some C coders like to use "clever" code. That type of code is rarely needed.
Re: (Score:2)
And outside of a masters degree course somewhere, where has that ever been a thing? Formal proving of programs isn't something done anywhere. Even then its utility is dubious- "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth
Re: (Score:3)
It could also be that the tutorials for learning Rust simply ... suck.
Maybe they were written for first time programmers, and he couldn't be bothered reading them because he had to wade through chapters of "this is how computers do numbers" stuff. But in doing so, he missed out on very important concepts to the language because they were buried
Re: (Score:2)
It could also be that the tutorials for learning Rust simply ... suck.
Well, they assume a lot. I got through the start of one and thought that most people will fail to understand a lot of it. That alone makes it unsuitable as mainstream language. I did get all of it, but I have imperative, OO, functional and assembler language experience and I am an IT security expert. I still did not feel and desire to continue, it just looks like it makes everything harder with few benefits. At least if you know what you are doing.
Re: (Score:1, Interesting)
One of the frequently-admired features of Unix is the fact that a lot of the basic utilities are filters - they take text on stdin and produce transformed text on stdout that can be fed to another filter in the chain.
C is a really terrible language to use for text-processing, even more so once you move beyond ASCII. How it ever survived for writing such programs is actually quite hard to imagine. In fact, I can't really think of a use for which it is particularly suited - it doesn't give you the real contro
Nursery paradigm (Score:2)
the familiar ideas of scope and lifetime that came from languages like Algol don't really apply and are hard to describe when there are asynchronous threads that may or may not also be running in parallel.
The "nursery" paradigm can help to bring some sense of scope and lifetime back to a multithreaded task. See "Notes on structured concurrency, or: Go statement considered harmful" by Nathaniel J. Smith [vorpus.org] (8000 words)
Re: (Score:3)
C is a really terrible language to use for text-processing, even more so once you move beyond ASCII.
Don't know why you were modded down because this is so true. The way C handles strings is pretty fly-by-night, which IIRC is something it inherited from its PDP-11 days. They're just character arrays that are terminated by a null character. That's it. There's no length indicator stored with it (i.e. no fat pointers) so you just keep reading unless and until there's a null character to tell it when it's done, which may or may not exist where you intended it to. There are so many ways this can go incredibly f
Re: (Score:2)
C strings are not intended for heavy lifting. If you do that, you are expected to use a string library or use your own approach.
Re: (Score:2)
Actually, C is pretty good for text-processing if you know what you are doing. Yes, it takes some more effort, but you get blazing speed and other advantages. Sure, if you just want to do some smaller things with text, do Perl. But forget about larger jobs that way.
Re: (Score:2)
So these things he says aren't true? He said that he was being forced to do memory safety when it wasnt even a concern and that the compiler was slow. Was he wrong about that?
Yes. Unless all of your variables are floats and integers on the stack, memory safety is always an issue when you write code in C. (If all of his values were actually floats and integers on the stack, he would have had no problem writing the Rust code either.)
That is some fine nonsense you have there. First, putting things on the stack does not protect them. Second, unless you do certain things in C it is actually memory-safe.
Re: (Score:2)
Scalars on the stack are "automatic" variables. There is no explicit memory management needed by the programmer. They are pretty safe, as long as you don't do stupid C casting tricks.
The "certain things" you refer to includes using *any* pointer or array value in any way, including allocating, freeing, indexing and dereferencing. That essentially means any operations on items other than the automatic scalars I already covered. (For completeness, we can also consider "plain old data" structs lacking embedded
Re: (Score:2)
Scalars on the stack are "automatic" variables. There is no explicit memory management needed by the programmer. They are pretty safe, as long as you don't do stupid C casting tricks.
I guess you never have heard of buffer overflows on the stack then ...
Re: (Score:2)
How are you going to get a buffer overflow on an integer or float scalar?
Those happen on arrays and pointers, whether on the stack, heap or global static spaces. You can also overflow the entire stack using unbounded recursive function calls, but that's a different issue.
Your seem to be totally ignorant about how different data types work.
Re: (Score:2)
Second, unless you do certain things in C it is actually memory-safe.
So what are you saying, never mutate or free memory once it has been allocated?
Re: (Score:2)
I am saying know and understand when to be careful.
Re: (Score:2, Interesting)
Rust really shouldn't be treated as a general purpose language. It's a specialized language for special situations: when you want to get the absolute fastest performance possible, and you're willing to put in extra work to get it, but you don't want to sacrifice memory safety.
For most code that most people write, you're better off using a language that gives up a little performance to get memory safety without the effort. There are lots of languages like that: Java, C#, Kotlin, Swift, etc. They give the
Re: (Score:2)
An interesting selection of langauges. I, personally, switch between C++, Python, and D, depending on what I'm doing. I find all of the ones you selected ... umm ... less suitable. I'd be interested in Go if Doxygen could handle it. Similarly for Ruby. Both have cases where they would be the better choice, but documentation of my work says to avoid them. (And Sphinx is lousy, but since Doxygen handles Python I don't need to deal with it.)
Re: Seriously? (Score:2)
Re: (Score:2)
C++ is an older language used for performance critical code. It isn't memory safe, which can lead to a lot of bugs. There are times when that tradeoff makes sense, but it's not the right choice for most projects today. And if you're starting a new project of that sort, consider whether Rust might be a better choice.
Python is for code that isn't performance critical at all. If you write the same algorithm in all the languages we've mentioned, the Python version could easily end up 20 times slower than mo
Re: (Score:2)
For most code that most people write, you're better off using a language that gives up a little performance to get memory safety without the effort.
Why do that when it just comes naturally to you? I'm asked to write a lot of python at work, occasionally golang, but for my personal projects my default choice is rust, even for little things. A lot of that comes down to rust's tooling being very top shelf, (honestly I think the thing I hate about Java the most is the tooling, which I probably spend more time fighting with than anything else in that language) but there are a lot of semantic bugs that will bite you hard at runtime that aren't even relevant
Re: (Score:2)
Probably not. I had a look at Rust and it just looked excessively complicated.
Re:Seriously? (Score:4, Informative)
Asking Henry Ford about a car would indeed be rather daft. That would be like a lot asking Kernighan what he thinks about the the latest version of MS Office. It's not a very interesting topic to ask about.
What was asked is more akin to asking Henry Ford about what he thinks about the Toyota car design and manufacturing process. And there he'd have a lot of interesting insight, comparing it to his sensibilities which were instrumental in kickstarting the modern industrial era.
Kernighans experience of Rust illuminates some aspects of the modern development experience that are usually not made explicit. The developers who use the language are accustomed to it, and very few people come at it with the amount of experience Kernighan has. The objections to using the lamguage I have read from others have been a lot less articulate and succinct. And at the same time, his explanation tells me a lot about why these aspects are no issue to many others.
Re: (Score:2)
I bought "Java for C++ Programmers" and "Java in 21 days" back in the day.
It took me probably a couple weeks to really get the hang of it to the point I was building message queues and passing objects among threads (a client-server app).
It was probably only my 9th or 10th language at the time and quite different than some others I'd used.
I've looked at Rust fundamentals and am currently waiting for the dust to settle. Odds are good that Java code I wrote in the 90's would mostly run today. Not interested
Re: (Score:2)
I wouldn't depend on somebody with less than three years of C to put a server on the wire.
I would not depend on anybody with only 3 year of experience to write secure code in any language, period.
Re:Seriously? (Score:4, Informative)
I expect Henry Ford would have pretty insightful things to say about the new Toyota.
Kernighan is an accomplished computer scientist who's written books about several languages, including the famous one he wrote about C.
Always with the pot-boiler to get views (Score:2, Insightful)
Attention seeking behavior by pumping up the most trivial of things and events by the media and social media is a detriment to progress.
Trying to boil the pot to pit us into "group x" and "group y" to get red-meat shouting matches on every area of life, technology, trend, whatever is not forward progress.
The root of the problem (Score:2)
"And he acknowledged that the descendants of Unix now power nearly every cellphone. "I find it intriguing... And I also find it kind of irritating that underneath there is a system that I could do things with — but I can't get at it!"" - That's called lock-down enshitification for the sake of monetization. Tech bros are your gods and you need to bow to them accordingly.
Re: (Score:2)
I'd be interested to know... (Score:5, Insightful)
... what he thinks of modern C++ where the learning curve for newbies is now getting close to vertical. Speaking as a C++ dev of 25 years I wouldn't go near the language now if I was starting out, the number of paradigms and syntactic complexity has become ridiculous. And yes, if you're going to work on code written by others you do need to know and understand all these paradigms.
Re: I'd be interested to know... (Score:2)
Sure, if you only ever work on code written by one person. Meanwhile, back in the real world...
Re: (Score:2)
Complexity kills. On language level just the same as on code level. One reason why applied CS/IT/coding is not a mature engineering discipline is that the tools are not mature and often massively to complex to understand.
He mentioned this experience with Rust before (Score:4, Informative)
In a podcast in 2022 Kernighan mentioned an experience with Rust, and it appears to be this one. At that time he considered it too brief to have much of an opinion on the language, and apparently it was already a while back, when the language was changing very rapidly and not yet very popular.
He didn't mention the issues he took up this time either. The discussion went in many directions, but it's a bit strange he didn't bring up more of what he experienced at that time, especially since the focus of the podcast was on what has changed in the fifty years since he started out with C and UNIX.
https://changelog.com/podcast/... [changelog.com]
What Happened When Colonel Sanders Tried Church's? (Score:1)
All in all, the Colonel had had a bad experience.
Age: part of the issue? (Score:2, Interesting)
But in the last few years, I tried the Rust tutorial. Two times. I failed. My brain cannot cope with the syntax. It's way to close to C/C++, but with different and new meanings.
I think "I'm too old for this shit"
I find confort telling me that the younger coders need sidekicks to hide low level considerations.
But I ma
Re: (Score:2)
Re: (Score:2)
I am not comfortable with Rust, but I can kind of work it out (it's part of my job now). But I'm lost when I face a Haskell program that I did not write myself.
I think some languages are so similar that it's not too much trouble to switch between them. That was the cast for me with Pascal and C, and to some degree between C and a decent macro assembler from the 1990's.
Other languages are so naturally intuitive or so like a formal algebra subset that they are not too difficult to pick up. Such as the case wi
Rust: Desperate for Linux Merit Badge (Score:1)
Re: (Score:2)
Some people do that. Quite a few start their own kernel projects which usually run out of steam. I think if you want to be part of a massive community, you're going to be going with a mainstream kernel like Linux or FreeBSD.
If you want to do kernel development without having to learn Rust, then FreeBSD is an option currently. Although there are proof of concepts for writing kernel modules in Rust for FreeBSD, it hasn't quite taken hold of that project like it has for Linux.
C/Unix stringology lore from a BSD contributor (Score:2)
There are a couple of odd postings here about C being deficient
for string-handling. Unless you are talking about comparison with
SNOBOL, C is wonderful for strings!
E.g. for Berkeley Unix, I jammed in C/shell-based code 'locate'
(née 'fastfind') for file finding, non-numerical code for LZW-based 'compress',
and GNU [ef?]grep for hybrid Boyer-Moore regexp search, and did
samizdat work on fast anagram generation (see Scientific American
for October 1984). Some of it is still around or is otherwise
runnable on