The First Rust-Written Network PHY Driver Set To Land In Linux 6.8

[cj.wijtmans]

"C is for programmers that failed at learning to write proper Assembly production code" - somebody in the 80's.

And you would be somehwat right, look at roller coaster tycoon. C also adds minimal overhead, if you can even call it overhead, allows for many optimizations compared to (bad) assembly. And you can write assembly in C. Much unlike rust.

[cj.wijtmans]

Have a look at the number of CVEs in the Linux kernel that were caused by C this year alone. I wouldn't call the kernel developers "dimwits" and that's exactly the reason why many of them welcome a path to move away from C.

you realize C could have the same tools as rust right? C standards develop as well, so yes old code made with an old C standard could have bugs. And no i am not a fan of C. But rust as a language is utter garbage.

[jacob]

you realize C could have the same tools as rust right? C standards develop as well, so yes old code made with an old C standard could have bugs. And no i am not a fan of C. But rust as a language is utter garbage.

I'm fairly familiar with the tools available for C (for one thing I once wrote a C compiler - in C - and I also worked on a static analyser for C and C++). No, it absolutely, by design, cannot have the same tools as rust. You can't implement strong typing in C, or sum types, sane strings, smart pointers (that actually work, unlike those in C++), a borrow checker, slices, a module system etc., without it immediately ceasing being C.

Now let's see your reasoned, insightful, conclusive arguments why rust is "utter garbage". Among other things we should let Google, Microsoft, Meta, the Linux and GNOME developers, Cloudflare and others know. Those poor guys have been using rust for some time and never noticed that it was such garbage. Fortunately they have you to tell them.

[cj.wijtmans]

Among other things we should let Google, Microsoft, Meta, the Linux and GNOME developers, Cloudflare and others know.

Exactly the companies i avoid for being DARPA issued spyware.

[stormcrow]

you realize C could have the same tools as rust right? C standards develop as well, so yes old code made with an old C standard could have bugs. And no i am not a fan of C. But rust as a language is utter garbage.

It's not about language tools. It's about language assumptions. No, C will never be a fully safe language no matter how many checks, tools, curbs, bumpers, and other detritus it accumulates because the fundamental assumptions about how the language operates will not change. It can't and still be C. Much like C++ is not C, no not even a superset of C. It's become a completely different language with its own high and low level assumptions and ways of doing things. That's a lot of effort that's better served in creating new languages that start with the current understanding of the state of the art in PLT and moves forward, by learning from our mistakes not by compounding them as people like yourself keep proposing.

That's not to say that people that can competently read and write C, C++, assembly, VB, etc won't be in demand. It just means their roles will change to those of maintenance and porting instead of creating new projects much like COBOL, BCPL, Modula, REXX, etc. literate programmers do today. Eventually this will happen to all such current languages in their twilight when appropriate replacements come along allowing changes or hardware failure forces a change, even Rust.

[jacob]

Exactly the companies i avoid for being DARPA issued spyware.

It may very well be the case, but that doesn't change the fact that they all are drawing the same conclusions. Just because Rust is used among others for implementing spyware doesn't mean it's a garbage language.

[jacob]

Sorry, but no one ever said that while holding a straight face for long even back then. The only time I ever heard that was from kids who thought they were 133t writing assembly on their little PC or other toy home (yes they really were toys in comparison) microcomputers. Assembly for those ancient business and scientific systems were extremely specific for each computer they were written for (much like Intel/MASM syntax assembly doesn't run on non-x86 systems without massive effort for any complex program). Assembly wasn't more performant than Fortran in many cases and a hellaciously more painful to write and debug (substitute COBOL for Fortran in certain businesses). Higher level languages like C were embraced as a practical way to get software for computer A to run on computer B with relatively minimal effort. Portability was a major CS problem in the day, security was not. These systems had limited numbers of operators, behind locked doors, while networking was limited to unreliable phone lines, modems, and equally unreliable dedicated subscriber lines. Likewise, a new shift towards addressing the mistakes and limitations of the past, currently epitomized by both C and C++ but also assembly language and other languages that lack robust integrity guarantees, is now necessary. Give it up. Rust and other safe(r) languages are here to stay because the science of information security dictates that humans cannot be trusted to not make mistakes. The evidence is considerable that both users and programmers making flawed assumptions about users, problem domains, and the code they write are the primary problems in information security. There is no such thing as "perfect" code, not even with language model assisted review. Code does not and never will document itself fully. It is literally impossible to write any complex program in C, C++, assembly, etc without making mistakes that will inevitably have security implications. It's also literally impossible to encompass all input in a safe way in any Turing complete language so there's always going to be logic flaws and unaccounted for weird machine states until such time as new PLT paradigms are discovered. Which means, folks, Rust is not going to be the end game of programming languages, either. When someone comes up with something new that addresses Rust's problems and failings, it too will be replaced and the dumb argument now going on about C et al will happen with Rust... and it'll be just as stupid then as this one is now.

I agree with your points, except maybe the last one. One can hope that Rust will create a sufficient barrier to entry to keep those l33t know-it-all kids out, so that when another, better language is created and catches on, there will be much less of this idiotic "knowing".

[oleid]

IMHO - Rust is for programmers that failed at learning to write proper C production code ... since I doubt that anyone can write proper C++ production code.

You are entitled to your opinion. In my opinion, yours shows that you have little idea about Rust or modern concepts in programming languages.

By the way, I've been programming C++ professionally for some 10 years and C for even longer. Currently, I'm working at embedded firmware -- pure C code. And I'd pick rust any day. Sadly, the old product depends on a proprietary C compiler and is nearly done. But the next product is near

[oleid]

And you would be somehwat right, look at roller coaster tycoon. C also adds minimal overhead, if you can even call it overhead, allows for many optimizations compared to (bad) assembly. And you can write assembly in C. Much unlike rust.

Uh, but you can!

https://doc.rust-lang.org/reference/inline-assembly.html

But Rust wouldn't be rust if it wouldn't try to provide safe abstractions to scratch the usual assembly itches (currently not stabilized, yet):

https://doc.rust-lang.org/std/simd/struct.Simd.html

[jacob]

And you would be somehwat right, look at roller coaster tycoon. C also adds minimal overhead, if you can even call it overhead, allows for many optimizations compared to (bad) assembly. And you can write assembly in C. Much unlike rust.

You can write assembly in Rust just like in C (and just like in C, it's a bad idea, except in some very rare and specific circumstances). But you obviously don't know what the all-overriding design goal for the C language was: to have a self-hosting compiler that could run on a machine with 64K of RAM. Apart from some unfortunate tradeoffs that were probably unavoidable in one form or another (probably), like the preprocessor and the supreme ductape approach to separate compilation, it basically meant dumbing the language down by design. No-one ever said that the C type system was any good (particularly Thompson & Ritchie never said that), it is what it is simply because a better one would have been difficult to implement on the PDP-11. C arrays are simple plain pointers with the size of a single machine word not because someone thought it through and concluded that it would be fantastic to have a language like that, but because using slices (in the form of fat pointers, or an implicit "length" parameter always passed around) would have created more register allocation issues and, generally speaking, was too complicated for the extremely constrained system. Etc.