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?
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?