What Happened When Unix Co-Creator Brian Kernighan Tried Rust? (thenewstack.io) 94
"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:3, 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:Seriously? (Score:5, Interesting)
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++, references are explicit) and if you're coming from decades of C and only just picking up rust, the semantic differences alone are going to throw you for a loop, because Rust takes major deviations from most systems languages when it comes to semantics, which are pretty fundamental.
For example in rust, passing a user defined struct as a variable is always a move unless otherwise specified, where in C it's always a copy. I could see him saying "wtf, this isn't even a memory management issue, why is the compiler complaining?" when it is, especially for non-primitive types, just C developers understandably aren't normally used to thinking of it as such, because for that they typically think of references, mallocs, and frees.
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:3)
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)
No kidding. But this is Java we're talking about. Idiomatic Java is pure code smell. When's the last time you ever looked at factories, use of (still nullable) optional types, or code that doesn't properly account for type erasure because it's supposed to not be relevant to regular developers, and thought to yourself, "wow, this is great code!"
Yeah...me neither.
Re: (Score:1)
Whoosh!
Re: (Score:1)
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)
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".
Remember, we're talking the semantics of the *language*, not what the compiler is doing or what ends up in the machine code. When a value is "moved" in rust, what previously "owned" it can't do anything with it after that. But underneath it's still a memcpy.
in C from a "copy" into a "move" just by changing the "semantics" of the existing operators, but WITHOUT riddling them with extra hidden magic properties?
Well, rust *IS* a different language with different semantics, and unlike with C++, no "hidden magic properties" are needed. Period. In fact, in C++, it's not semantic at all, rather it's done with a class in the standard library, which may very well hav
Re: (Score:2)
Well C doesn't have destructors so there's no real difference between a move and a copy.
The "hidden" thing is misplaced. It's only hidden if you consider C to be some sort of universal truth.
Rust and c++ call destructors live objects at the end of the scope. This is no more hidden than C bumping the stack pointer at the end of the scope. It's something that the compiler does for you, but it always does it and it's completely predictable, and part of the whole point of the language so it's not hidden.
In C yo
Re: (Score:2)
The "hidden" thing is misplaced. It's only hidden if you consider C to be some sort of universal truth.
C is trying to be portable assembly, and IMO it does well at that. But an inevitable side effect of is that it's just as brittle as assembly.
Rust and c++ call destructors live objects at the end of the scope.
In C++, yes, but rust is a little different.
This is no more hidden than C bumping the stack pointer at the end of the scope. It's something that the compiler does for you, but it always does it and it's completely predictable, and part of the whole point of the language so it's not hidden.
A move in Rust has the same effect until the lifetime of the variable has expired. For example if I moved variable foo to the stack plane of function bar, the original copy would* remain intact, and AFAIK (though I don't work on the compiler) you basically get the C treatment for that original memory (*but again, compiler opt
Re: (Score:2)
And probably worth noting that despite years of using rust, I've never been in a situation where I've had to write my own destructor
The only things I've written destructors for are wrapping C libraries (though often less need with unique PTR with custom deleters now) and OS provided resources. I've had cause to work with file descriptors, and I wrote a bear trivial holding class which closed them if they are destructed.
I imagine working day to day in rust is similar: the automatic destructors do 99.9% of w
Re:Seriously? (Score:4, Insightful)
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:2)
Yes it is a thing! ADA/SPARK is all in on that. There's a theorem prover built in.
Re:Seriously? (Score:4, Interesting)
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 in beginner level stuff.
Or maybe they were written for experts who know what memory safety is about and assume context and experience that not everyone has.
It's hopefully one of the outputs of the Linux Rust project would produce - Rust for C programmers - if you've done kernel programming and want to check out the Rust side, a comprehensive reference guide.
Of course, the biggest program is generally documentation, so it's likely he just couldn't wrap himself around what little he had to go by. It either assumed you know the concepts of memory safety inside and out, or assumed you know the runtime completely. And of course, lacking sufficient examples to figure it out from code. Sure the Linux kernel APIs are often a mystery, but there are often plenty of example code and drivers to go around so you can figure it out.
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:Seriously? (Score:5, Interesting)
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 fucking south (see, for example, the deprecated gets function.) Throw UTF-8 into the mix, which allows for variable-size characters, and you've got a fucking nightmare (note: This is why rust will panic if you attempt to slice into a string and your offset was in the middle of a UTF-8 character, which can cause all sorts of memory safety bugs if it didn't.)
My hunch is that the reason Apple to this day still keeps having so many string parsing bugs that result in the entire OS being compromised (both macos and ios) is because of objective-C, which a lot of their trusted middleware code is still written in, inherits this property without benefiting from the newer data structures available in modern languages, and I suspect they have proprietary structures meant for parsing unicode that don't work particularly well.
Re: (Score:3)
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)
That's the problem with strings though: They're deceptively complicated, and few people realize that. Remember, even the standard library gets function got it wrong, and that wasn't even in the age of unicode.
Re: (Score:2)
However you can easily handle them the way you want, like making a 'struct' of a char array and and 'int' for length. Then there are many 3rd party libs that handle Unicode etc.
This is what makes C differ from most other languages: in C you know the underlying structure of your data.
Re: (Score:2)
However you can easily handle them the way you want, like making a 'struct' of a char array and and 'int' for length.
In a way, that's like saying you can easily roll your own crypto. Will it work? Probably, especially if you test it. Will it be foolproof? Almost certainly not. Even if you use a crypto library, you can still misuse it by, for example, failing to pad your data, or even just padding it improperly.
Re: (Score:2)
It's surprising that there isn't a really good library for C/Unicode string handling that has become a de facto standard. Then again, Unicode is itself a bit of a disaster.
Same with time handling. It's an annoying but not unsolvable problem, yet there is no really good standard implementation.
Re: (Score:2)
It's surprising that there isn't a really good library for C/Unicode string handling that has become a de facto standard.
Probably because it would be very un-C. Same reason C doesn't have any universally used memory structures that are common in other languages to the point that the language has syntax built around them, like hashmaps.
Re: (Score:1, Troll)
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)
Unless you are in incompetent. Then you are just another bad craftsperson blaming their tools.
Re: (Score:3)
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)
Those happen on arrays and pointers, whether on the stack, heap or global static spaces.
Umm...how do you buffer overflow a pointer? I mean...I could see overflowing an (unsigned) integer, which is what a pointer really is at the end of the day, only significance is that it's sized to exactly match the size of your memory addresses. But that's quite distinct from a buffer overflow, and only relevant to pointer arithmetic.
Re: (Score:2)
I meant using a pointer to the base of a buffer, then writing data beyond the end of the buffer the pointer refers to.
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:1)
I am saying know and understand when to be careful.
Re: (Score:2)
Well, that this gets moderated down just proves my point: Too many incompetents in software and it is damaging things overall massively.
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)
No, Doxygen support only determines which languages aren't acceptable.
Actually, a good documentation program that can generate static html pages, is easy to use, doesn't take up too much vertical space, and a few other requirements it the criterion, but basically that's Doxygen or Javadoc, and I don't like Java. ... Well, actually one of the requirements is the same documentation system needs to work on all the programs in the project.
E.g. Markdown takes up too much vertical space. (The requirement for bla
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:3)
Whether the language is mainstream or not isn't one of my considerations. What libraries are available, of course, is related to that, and that *is* one of my considerations.
Python is fine when the application is I/O bound anyway.
Re: (Score:2)
Re: (Score:2)
D is fast and handles Unicode well. If the application is I/O bound, Python is a better choice. If it doesn't use Unicode, C++ is preferred. (This preference is partially driven by available libraries. If libraries are significant you pick whichever has the best libraries. Were libraries equal I'd probably always pick D, though coding in Python is a bit faster.)
Re: (Score:3)
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)
Utterly fail by raising an exception if what was returned was "None", and so instead I often rely on
To me,
if val != None:
Always works fine in python and seems a lot easier to read than the rust example. I don't know why you would write it with a type check as long as you know the method returns none or the type. Even "if object != None and type(object) is Class" is a lot easier to read. I don't need to know rust to know that it is hard to read. I have used other languages with the ? nil check like Swift and I find it extremely frustrating because you are forced to ALWAYS do it. I just end up bypa
Re: (Score:2)
You just did a fantastic job of demonstrating my point, and you don't even know it.
if val != None:
That doesn't always do what you think it does, and will inevitably bite you in the ass at some point. Which is why I don't do it.
https://stackoverflow.com/ques... [stackoverflow.com]
I think the difference between you and me is the level of autism I throw into coding. I HATE brittle code, and....that...is brittle code. Probably also worth noting that I've only been doing python for about a year (if that) and ended up finding out things like this
Re: (Score:2)
Re: (Score:2)
Ok well you do you. Meanwhile I'll be coding four times as fast as you.
No, you won't. But you will produce substandard code in that same amount of time.
I develop to make money from the end product, not by the hour.
If I was by the hour, it would be somewhere between $185/hour and $200/hour. I'm not sure yet because I haven't yet calculated what the gains are on the shares I've sold this year, but in the interest of being fair, the range I gave you is likely on the low end.
And if you can't use != None without getting into trouble
Engineering is far less about whether could, and far more about whether you should. In other words, soundness always takes priority. A systemic problem in python is that
Re: (Score:2)
Probably not. I had a look at Rust and it just looked excessively complicated.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Seriously? (Score:5, 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:Seriously? (Score:5, Interesting)
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 in updating apps every year or two if they are working.
But when I do dig into it I expect to allocate a week or three to get used to it.
By contrast you can spend a day with Lua and do some useful small things but they are small things.
C is easy to start writing bad programs with and almost impossible to write secure programs with. I wouldn't depend on somebody with less than three years of C to put a server on the wire.
Re: (Score:1)
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: (Score:2)
And idiots like the one that moded this down are the reason why so much software is so insecure.
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.
Re: Seriously? (Score:2)
Based on your position, we should never ask COBOL creators what they think about Java or Python.
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:The root of the problem (Score:5, Insightful)
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:3)
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.
Re: (Score:2)
>... 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.
C++ is the easiest to learn now in, like, ever.
It's a mistake you have to know all the ins and outs of the language. The mini
Re: (Score:3)
If all you know is a minimal subset of the language, you don't know the language. What you describe may be ok for a toy app you write on your own time and never need to support or put to serious use, but not for anything approaching actual development. What you describe is hacking, not developing.
Re: (Score:2)
Agree. Most of my debugging time was spent debugging problems caused by ambiguities in the description of the language.
He mentioned this experience with Rust before (Score:5, 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:5, Interesting)
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 your Mac using Terminal.
Lastly here is some trivia about Webster's 2nd Intl. (1934) cited by Kernighan
in his lecture, which I snuck over to BSD after Dennis Ritchie handed me
a 9-track tape at NASA Ames Research Center.
Although I intimated (see /usr/share/dict/README on your Mac)
that "the supplier" (Ritchie, via Doug McIlroy) thought it might be
out-of-copyright, 'tis not so! A search of copyright renewals at Stanford
shows that it was renewed in 1961, so that orig. date + 95 years
still applies, or until 2029. But shhh, don't tell anyone!
Protected mode should be enough (Score:2)
1. If your program cannot manage memory and crashes, that's your fault.
2. If your program can be used to hack into other programs, that's the operating systems fault.
3. If your program can hack into the OS, that's the hardware's fault.
You can work around 1 with a better designed language, but not the other two, and that's where systems are cracked. (phones, consoles, IoT)
Very old man isn't very good at learning new thing (Score:1)
No thank you. (Score:3)