Solved Is Rust now killing C++ and eventually C with it ?

You realize that you have just fessed up to the shortcomings of C and the very reason that devs are considering Rust?

This is a very good, easy-to-understand explanation.
C for certain has shortcomings (I am very willing to acknowledge that). But there is no language on the horizon that is a better option at the moment. Most developers know this and so we just keep on trucking along with C.

Basically, once some genius invents a close(ish) superset of C which is 100% safe and provides >75% direct interop with existing C, I think then a big revolution will happen. I suspect this will come once we start needing to look into how C can be extended to leverage a massive paradigm shift in how computers work (perhaps quantum processors, etc).

From the mailing list (Actually the very message that this thread linked to!), one of the things mentioned as "Impossible to do in C" is
Oh, looking through the code, he probably means due to the liberal use of lambdas.

Its not impossible, just awkward the way he wants to do them (different languages do make things easier!). The C equivalent would be function pointers with a fair amount of wrangling user-data. Not worth it when C++ exists and is in base.

Upstream fusefs has a number of tests in C. Likewise it is very possible to write code that makes it "impossible to do in anything other than C". setjmp/longjmp, etc. Its whatever agenda the developer wants to push really ;)

Isn't it the job of wpa_supplicant to automate it, like everybody else already does? Even if it's ultimately not the fault of the FreeBSD wpa_supplicant implementation, roaming is an important aspect of wifi usage at all, and does deserve to be automated.
Its wpa_supplicant's job to instruct the deeper layers of the wifi stack to roam. These layers unfortunately ignore the request (for some drivers) because it is not yet implemented.

But yes, I agree, roaming is important. I am glad it is still on their TODO list. They recently imported iwx(4) from OpenBSD/Haiku, which is great for immediate use. I just hope that isn't because they are starting to get fatigued with the iwlwifi port!
 
Basically, once some genius invents a close(ish) superset of C which is 100% safe and >75% compatible with direct interop, I think then a big revolution will happen.
Isn't that what happened with C++? Yeah, it's not exactly memory-safe (making any code memory-safe is still a required chore for the programmer, with extra LOC), but other than that, it does check the boxes.

BTW, that same message does reference a couple examples of kernel modules that are in C++, and kind of have to live in the kernel tree: devd and zfsd... and the dev does want to rewrite them.

Its wpa_supplicant's job to instruct the deeper layers of the wifi stack to roam. These layers unfortunately ignore the request (for some drivers) because it is not yet implemented.
My take is, make do with what you've got. If wpa_supplicant sends requests that get ignored, there's gotta be a way to properly handle that. and at least make sure that connection details do persist in some form or shape, somewhere, until they need to get applied again. If wpa_supplicant.conf is not the place to look to make sure that the details of a successful connection persist AND get correctly applied, using whatever drivers we do have, whatever APIs are available and known to work - somebody does need to nail down the movement of that data.
 
You realize that you have just fessed up to the shortcomings of C and the very reason that devs are considering Rust?

This is a very good, easy-to-understand explanation.
Programmers are called "programmers" because they know how to overcome these inconveniences, otherwise they are not programmers. To each his own job
 
Programmers are called "programmers" because they know how to overcome these inconveniences, otherwise they are not programmers. To each his own job
This - so much this.

"Everybody needs to be able to do everything with little knowledge but they can't under any circumstances shoot themselves in the foot" is literally a step backwards in the societal structures of humanity.
Should everybody go back to producing their own milk and bread?

Our living standards improved drastically because of specialization. People started focusing on one thing and learned to master it.
Rather than doing 50 things shitty, do one thing really well.
 
Programmers are called "programmers" because they know how to overcome these inconveniences, otherwise they are not programmers. To each his own job
Even if they have to use brainfuck to overcome the memory safety issues of C/C++ ? What if they can write something in C/C++ but not brainfuck?
 
Isn't that what happened with C++? Yeah, it's not exactly memory-safe (making any code memory-safe is still a required chore for the programmer, with extra LOC), but other than that, it does check the boxes.
C++ is a good compromise. The fact it builds on C and still provides ~90% safety is probably the reason why it did gain so much popularity so quickly.
Building on C *and* 100% safety is the dream though!

BTW, that same message does reference a couple examples of kernel modules that are in C++, and kind of have to live in the kernel tree: devd and zfsd... and the dev does want to rewrite them.
I don't know about zfsd but I think devd should just be rewritten in C. If you look through the code it is tiny. This possibly shouldn't have been C++ in the first place. It was overkill. Didn't one of the members on these forums develop a Rust implementation already? I recall seeing something about it.

Slightly related; Apple's macOS drivers (kexts) and DriverKit are C++ and it does fairly well. But now it means that Rust will be hard to use in future. C <-> Rust is easy. C++ <-> Rust is not so easy.

If wpa_supplicant sends requests that get ignored, there's gotta be a way to properly handle that. and at least make sure that connection details do persist in some form or shape, somewhere, until they need to get applied again.
I'm not a wifi expert but roaming is actually quite a low level functionality. You want the hardware to mostly handle it transparently so as you go between access points, there is no interruption as the higher layers needs to reassociate. That said, maybe there is something else at play causing your issues? I know on some eduroam or "_The Cloud" access points, my machines simply don't play ball. On others, it is almost perfect. Annoying.
 
For the love of God, quit being so hung up on "programming language safety" people! There is safety in becoming an expert and understanding the domain in which you work. I for one am a guy who disables the seatbelt chime the second I buy a new vehicle. I despise auto-modes on digital SLR cameras, and if I want to shoot myself in the foot then I believe that is my perogitive. If safety is a concern then learn and use the AUTOSAR/MISRA safe coding standards. Systems programmers need to understand systems and low-level programming and there is no subsitute for knowledge. the advent of "safe languages" just screams intellectual laziness in my book.

This rust crap reminds me of the kiddies who think you can write python as embedded code for safety critical apps and then want to release those apps on PIs.
 
For the love of God, quick being so hung up on "programming language safety" people! There is safety in becoming an expert and understanding the domain in which you work.
Very true. Safety is important but it shouldn't be at the absolute expense of an elegant solution. It is just one part of the software development process. Correctness first, safety second.
 
But now it means that Rust will be hard to use in future. C <-> Rust is easy. C++ <-> Rust is not so easy.

Apparently interfacing C and Rust is not very easy, it is what the Linux kernel people fight over.

Anything to C++ is a nightmare if you don't go through a plain C layer. The only language that does interface to C++ as such is to my knowledge the Common Lisp compiler Clasp, which uses the LLVM libraries to parse C++ (a huge task). https://github.com/clasp-developers/clasp The amount of code to achieve the C++compatibility is insane. And even that gives you only some but not all of C++.
 
I for one am a guy who disables the seatbelt chime the second I buy a new vehicle.
Yeah, and then forget about the seatbelt altogether until you get pulled over by a cop? I've seen tons of people who forget about the turn signal or hazard lights. Those people don't even bother with turn signals when they are in a turning lane.

If safety is a concern then learn and use the AUTOSAR/MISRA safe coding standards. Systems programmers need to understand systems and low-level programming and there is no subsitute for knowledge. the advent of "safe languages" just screams intellectual laziness in my book.
Yeah, and this is Open Source, entirely volunteer-driven efforts... If people were paid, then yeah, it's viable to enforce those safety standards for programming - if you have the brains to detect such violations. With unpaid efforts, it's far more pragmatic to automate the safety.
 
If safety is a concern then learn and use the AUTOSAR/MISRA safe coding standards. Systems programmers need to understand systems and low-level programming and there is no subsitute for knowledge. the advent of "safe languages" just screams intellectual laziness in my book.

What about the libraries you have to use? How do you ensure they obeyed to your coding standards?

One undeniable advantage of Rust is not that it is safe. It isn't, because you have to have unsafe code sections and use C code to get anything real world done. The advantage is that you only need to review some parts of a library, and with a good library hopefully a small part.
 
What about the libraries you have to use? How do you ensure they obeyed to your coding standards?

One undeniable advantage of Rust is not that it is safe. It isn't, because you have to have unsafe code sections and use C code to get anything real world done. The advantage is that you only need to review some parts of a library, and with a good library hopefully a small part.
OK. Fair question, which begs a question in response...How often do you encounter true "bugs" in well supported long lived libraries? certainly real bugs are a rarity in the std c lib, and in libraries I'd consider using with my code. If you're talking about 3rd party high level libraries, then I'd suggest that the vendors need to be held to a higher standard than the drivvel we've come to expect in 2025.
 
Apparently interfacing C and Rust is not very easy, it is what the Linux kernel people fight over.
Indeed, its all relative. No cross-language interop is "easy". Bindings are horrible things.

Anything to C++ is a nightmare if you don't go through a plain C layer. The only language that does interface to C++ as such is to my knowledge the Common Lisp compiler Clasp, which uses the LLVM libraries to parse C++ (a huge task). https://github.com/clasp-developers/clasp The amount of code to achieve the C++compatibility is insane. And even that gives you only some but not all of C++.
Interesting. I know Apple tried to improve C++ interop with Swift a little while ago. Not really very big on the Apple ecosystem to have tried it myself. Almost all others just fall back to C.
 
and to clarify my above post, I'm not arguing against rust as a general purpose multi-paraidm language...If it floats your boat then use it, but it has no business being called a "systems programming" language. It does not meet the criteria because its priorities don't properly align with the close-to hardware control of systems programs.
 
OK. Fair question, which begs a question in response...How often do you encounter true "bugs" in well supported long lived libraries? certainly real bugs are a rarity in the std c lib, and in libraries I'd consider using with my code. If you're talking about 3rd party high level libraries, then I'd suggest that the vendors need to be held to a higher standard than the drivvel we've come to expect in 2025.

Well, for starters all the SSL libraries had memory bugs. Those are certainly well-estabilished.

Another class of libraries coming to mind if for file formats and serialization. Libxml had a security relevant memory bug just a couple weeks ago.

Holding a commercial vendor to high standards is futile. They didn't even get the software for the 737 Max right. It's all garbage. The best you can do is require the source code and review. And as I said Rust has the potential to narrow down the amount of code you have to review. Whether that potential is realized in practice I do not know.
 
Well, for starters all the SSL libraries had memory bugs. Those are certainly well-estabilished.

Another class of libraries coming to mind if for file formats and serialization. Libxml had a security relevant memory bug just a couple weeks ago.
Ok. One more comment and then I'll go away. LOL

and are these the kinds of libraries you'd use in "systems programming" or are they more "applications programming" libraries? My argument agaisnt rust is more about its unsuitability for coding kernels and OS support programs.
 
Ok. One more comment and then I'll go away. LOL

and are these the kinds of libraries you'd use in "systems programming" or are they more "applications programming" libraries? My argument agaisnt rust is more about its unsuitability for coding kernels and OS support programs.

The SSL libs are absolutely for systems programming, too. Parts of them end up in the kernel. And they should, the kernel should not needlessly reimplement cryptographic functions.

When it comes to output formats and standard file formats, FreeBSD has recently equipped many commandline tools with Json output so that it can be parsed easier and safer than perl'ing the line-based ASCII output.
 
rust as a general purpose multi-paraidm language [...] but it has no business being called a "systems programming" language.
I think the term "system programming" is a bit fuzzy. AFAIK golang advertises itself as a system programming language too.
System as "close to hardware" vs system as "complex multi-application thing" (or whatever).
 
Well, for starters all the SSL libraries had memory bugs. Those are certainly well-estabilished.

Another class of libraries coming to mind if for file formats and serialization. Libxml had a security relevant memory bug just a couple weeks ago.

Holding a commercial vendor to high standards is futile. They didn't even get the software for the 737 Max right. It's all garbage. The best you can do is require the source code and review. And as I said Rust has the potential to narrow down the amount of code you have to review. Whether that potential is realized in practice I do not know.

Why we should rewrite something that intract's with unsafe C code?! unsafe C/C++ code already does that job
If security is most important thing and rust gives us security, so only solution is rewrite everything in rust, nothing ELSE.
I think the problem is nobody has responsibility to doing that (rewrite world and kernel) you write/rewrite an small part of base and bye! we should enter a new language because of some small things?
I believe developer/users ratio of FreeBSD is more than windows, macos or even linux.
 
Back
Top