So many system bugs are because of unclear memory ownership, buffer overflows, and race conditions. C/C++ don’t help you avoid any of these footguns. Any other system that relies on GC is non-deterministic and prone to mystery hiccups, which is why OS and driver tech has been pretty much the same foundation since the 70s.
Rust lets you avoid 2 of those 3 issues (thread race conditions are still a thing). And being compiled, instead of interpreted bytecode means you can get reasonable performance on smaller machines. No wonder these OS guys are so excited.
Yup. Most of my career has been working on embedded realtime software, so interpreted languages are right out and really only C and a subset of C++ are available. I’ve now been using Rust in that way for about nine months now and while the syntax is sometimes silly feeling, being able to not worry about some many other issues has made development much better.
But libraries like Boost do… if you’re writing in raw C++ you’re doing it wrong. A big part of the power of C/C++ is the mature and modern ecosystem built around it.
Except that C++ libraries often make the end result run slower, instead of the Python way where “native” Python runs at a glacial pace compared to its library calls.
I’ve worked at plenty of companies that no longer exist, and startups that “made it big,” and big companies that lumber along… how good their programming practices were, how well thier software performed, has just about zero correlation with how well they do in business.
As you point out: different tools are more/less appropriate for different applications. Rust has good overlap with C and C++ places, and in kernel land it’s subbing for C.
I’ve never tinkered in kernel space much - repaired a few OpenGL drivers because nobody else would step up and do it, but I usually stay in the higher abstraction levels. What do kernel people think of libraries like GLib?
So many system bugs are because of unclear memory ownership, buffer overflows, and race conditions. C/C++ don’t help you avoid any of these footguns. Any other system that relies on GC is non-deterministic and prone to mystery hiccups, which is why OS and driver tech has been pretty much the same foundation since the 70s.
Rust lets you avoid 2 of those 3 issues (thread race conditions are still a thing). And being compiled, instead of interpreted bytecode means you can get reasonable performance on smaller machines. No wonder these OS guys are so excited.
Yup. Most of my career has been working on embedded realtime software, so interpreted languages are right out and really only C and a subset of C++ are available. I’ve now been using Rust in that way for about nine months now and while the syntax is sometimes silly feeling, being able to not worry about some many other issues has made development much better.
But libraries like Boost do… if you’re writing in raw C++ you’re doing it wrong. A big part of the power of C/C++ is the mature and modern ecosystem built around it.
So, C++ is the new Python?
Except that C++ libraries often make the end result run slower, instead of the Python way where “native” Python runs at a glacial pace compared to its library calls.
Yes, but nobody in their right mind will use boost at OS kernel or driver level. Also, using C++ has vtable/exception overhead. No-go.
I worked at companies that tried both. They no longer exist.
That’s just nonsense. The kernel and most other big C projects are full of structs with manual re-implementations of vtables.
If you don’t want exceptions (I don’t either), C++ doesn’t require you to use them. KDE software builds without them.
I’ve worked at plenty of companies that no longer exist, and startups that “made it big,” and big companies that lumber along… how good their programming practices were, how well thier software performed, has just about zero correlation with how well they do in business.
As you point out: different tools are more/less appropriate for different applications. Rust has good overlap with C and C++ places, and in kernel land it’s subbing for C.
I’ve never tinkered in kernel space much - repaired a few OpenGL drivers because nobody else would step up and do it, but I usually stay in the higher abstraction levels. What do kernel people think of libraries like GLib?