7 ms·
I feel like if C++ didn't break through this barrier then I wouldn't hold my breath for Rust.
by mehrdadn 8y ago
I feel like if C++ didn't break through this barrier then I wouldn't hold my breath for Rust.
- Someone1234 8y agoI don't follow that argument. C++ didn't break through because the benefits didn't outweigh the drawbacks compared to straight C (meaning you can implement C++ like concepts in straight C, and not have to deal with a lot of baggage C++ brings). Rust is a whole other kettle of fish. It has more or less been proven by this point that people cannot write memory safe C, even experts in the language are still introducing memory-unsafe bugs in 2018. Therefore Rust is bringing features the C language cannot offer. Which isn't to say I know that Rust will be "successful." I don't know that. But I do know it is worth TRYING to see if it can be successful, and C++'s lack of success isn't really a counter-argument. I'm still sad that Microsoft's Singularity OS[0] never got further developed, interesting concept. [0] https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system)
- pjmlp 8y agoBias is everything, Joe Duffy briefly mentioned at his RustConf keynote that many at WinDev did not believe Midori was possible, even when shown running in front of them.
- andrekandre 8y agoi think this would be the link, if anyone is interested: https://www.youtube.com/watch?v=EVm938gMWl0 https://www.youtube.com/watch?v=EVm938gMWl0
- mehrdadn 8y agoYeah I was sad about Singularity too. As for C++, yes it doesn't being an absolute guarantee of memory safety, but C is so error prone that it's ridiculous to suggest anything below an absolute 100% guarantee wouldn't be a compelling improvement. C++ was a gigantic improvement in the safety of C (i.e. such that following good coding practices actually gives you legitimate confidence your code is memory-safe) while still having all of its flexibilities, and yet it still got shunned, so I'm unconvinced that a nitpicky language like Rust makes all the difference just because of its formal verification. If kernel folks wanted compiler help with memory safety they could've embraced C++ and gotten most of the way there.
- vardump 8y ago> ... It has more or less been proven by this point that people cannot write memory safe C, ... Or concurrency safe. There aren't many languages that can help with this class of bugs. Like race conditions. (Someone on HN said Pony is another language that has concurrency/thread safety guarantees.)
- JoeAltmaier 8y agoC++ can bring very little baggage. That's why its widely used in Embedded environments. And I'd wager that C++ can write far better optimized abstractions than a human in C every could. In most cases. Writing memory-safe C is clearly possible - many other enviroments are written in C. It come down to using a safe subset.
- TheCoelacanth 8y ago> Writing memory-safe C is clearly possible - many other enviroments are written in C Show me one major piece of C software that does not have frequent memory-safety bugs and I might believe that.
- richardwhiuk 8y agodjbdns/qmail might qualify here.
- tptacek 8y agoqmail had LP64 memory corruption bugs.
- JoachimSchipper 8y agoOne ever right? I wouldn't count that as "frequent" - lots of programs in memory-safe languages have more/worse bugs than qmail. Of course, the existence of one significant not-too-vulnerable C program doesn't really prove a lot either way...
- tptacek 8y agoI though Georgi Guninski found several.
- milkey_mouse 8y agoNot to shill but I'm working on a Singularity/Midori-inspired Rust JIT-compiled operating system. If that ever gets anywhere I'll post a link/Show HN.
- pjmlp 8y agoIt did, just not on pure UNIX clones. Symbian, BeOS, Haiku, Genode, ARM mbed, macOS IO Kit, Android (specially after Treble), Fuchsia, Windows, IBM mainframes (old PL/S code has been partially replaced with C++) ...
- mehrdadn 8y agoI guess by OS programming I assumed they meant the kernel. Fuchsia is hardly an established OS at the moment so I don't really compare against it, and for Windows, MS's documentation has repeatedly discouraged C++. I'm sure some use C++ in the kernel anyway but I'm not under the impression it's generally accepted.
- pjmlp 8y agoAll the examples I gave, except for Fuchsia, are examples of C++ in production for kernel code. Windows has been slowly moving into C++ since Windows 8, as Microsoft considers C++ the future of systems programming in Windows. https://docs.microsoft.com/en-us/cpp/build/reference/kernel-create-kernel-mode-binary?view=vs-2017 https://docs.microsoft.com/en-us/cpp/build/reference/kernel-... https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_coded_in_c_or_assembler/d4g9we9/ https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...
- mehrdadn 8y agoWow that's good to hear, thanks. (I wasn't familiar with the other OSes so that's why I didn't comment on them.)
- pjmlp 8y agoHere is some information for you, or anyone else, to look into then. https://os.mbed.com/docs/mbed-os/v5.11/apis/drivers.html https://os.mbed.com/docs/mbed-os/v5.11/apis/drivers.html https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Introduction/Introduction.html?language=objc#//apple_ref/doc/uid/TP0000011 https://developer.apple.com/library/archive/documentation/De... https://genode.org/documentation/genode-foundations-18-05.pdf https://genode.org/documentation/genode-foundations-18-05.pd... https://www.haiku-os.org/docs/api/ https://www.haiku-os.org/docs/api/ https://source.android.com/devices/architecture https://source.android.com/devices/architecture https://source.android.com/devices/architecture/hidl-cpp/index.html https://source.android.com/devices/architecture/hidl-cpp/ind... https://www.amazon.com/Symbian-OS-Internals-Real-time-Programming/dp/0470025247 https://www.amazon.com/Symbian-OS-Internals-Real-time-Progra...
- swebs 8y agoHere's the explanation from Linus for C++ http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
- jcranmer 8y agoThis is a prime example of the gatekeeping nature of C programming you see: the idea that, if you're not using C, you're not a serious programmer, so go away and play with your toy language. The main actual objection to C++ is that, well, the exception handling model is controversial, and it is especially ill-suited to kernel programming. RTTI can also get thrown in the lump here. Standard libraries aren't going to work in the kernel anyways, and so if you strip that out, what benefits does C++ get you over C? The correct answer, actually, is that you get RAII for added safety, and tooling such as IDEs have better support for finding all implementations of a virtual function than they do function pointers, but for a lot of C programmers, this can be a sense of "real programmers shouldn't need such assistive technology."
- bogomipz 8y ago>"The main actual objection to C++ is that, well, the exception handling model is controversial" I am not familiar with this. Can you way why exactly it is considered controversial?
- Retra 8y agoGoing from memory here, since I can't find any references. I believe there are problems in the handling of exceptions in constructors and destructors, which permeates into other parts of the language such as how arrays are constructed, etc. For one, the only way a constructor can fail is through an exception, and that's pretty heavy-handed for a language which markets itself as "don't pay for what you don't use." So you can't do RAII in C++ without exception handling. (Note that Rust solves this by not even having constructors.) There are also some problems with exceptions being slow code paths, but that probably varies by compiler.
- zaarn 8y agoUsing C++ for kernel development means you first have to drop most of the useful parts of C++ and take usability hits with almost all the other features. Rust and C have an advantage because both are fairly close to the metal, Rust in no_std mode isn't much different than C but the compiler is angry at you all the time.
- mehrdadn 8y ago> Using C++ for kernel development means you first have to drop most of the useful parts of C++ and take usability hits with almost all the other features. What? No... the most useful parts of C++ are its compile-time facilities... templates and type utilities and RAII/smart pointers/etc. (I could go on and on) all of which are still there. You'd lose some runtime stuff like the ability to throw exceptions and some RTTI, which some people already advise each other to avoid in user mode too (not to say I agree, but they're still finding a lot of use in C++ without this). If losing those is equivalent to losing most of C++ for you then you're not really taking advantage of C++ to begin with.
- DowsingSpoon 8y ago>Using C++ for kernel development means you first have to drop most of the useful parts of C++ and take usability hits with almost all the other features. This is commonly accepted wisdom, but it's not entirely true. (It's only a little bit true.) The kernel is a freestanding environment where big chunks of the standard library are missing. However, the most useful parts, like unique_ptr<T>, can be reimplemented as needed. The kernel absolutely can support RTTI and exceptions. Porting libcxxrt is relatively simple, for example, even if implementing the entire Itanium C++ ABI is a big task. Though, the kernel should still avoid throwing and catching exceptions in sensitive code like interrupt handlers. This is not radically different from other C++ projects. The use of exceptions is typically discouraged, for example, in tight inner loops. It is true that enabling RTTI and exceptions causes code size to explode. This is a valid concern. While memory is cheap, cache misses are not cheap. Mark functions and methods with "noexcept" as needed where this becomes a problem. Finally, it's absolutely true that exceptions make it impossible for the kernel to make solid real-time guarantees. Fortunately, most operating systems only have soft real-time constraints, if that.
- yellowapple 8y agoWho says that C++ didn't break through that barrier, though? Sure, the big popular OS projects like (I'm assuming) Windows and Linux mostly stick to C in their kernels, but Haiku (for example) seems to be doing quite alright being written predominantly in C++, including in the kernel: https://git.haiku-os.org/haiku/tree/src/system/kernel https://git.haiku-os.org/haiku/tree/src/system/kernel Outside the kernel, C++ seems to have more significantly broken through that barrier.
- mehrdadn 8y agoYou've repeated one of the existing responses from 9 hours ago.
- yellowapple 8y agoSorry about that. In my defense, I linked directly to example source code.