3 ms·

I think there's an underlying concept here. C is three things: 1. A mid-level language, by which I mean a language where you do all of the mechanics but you a

by msla 8y ago

I think there's an underlying concept here. C is three things: 1. A mid-level language, by which I mean a language where you do all of the mechanics but you abstract most of the machine-specific details. Memory management is manual, but you don't know or care about how malloc() works behind the scenes, and you can't even ask. You get integers with defined semantics up to things like overflow/wraparound, but you don't know or care if they're implemented in terms of multiple machine words or even if there's such a thing as a carry flag. It's midway between a macro assembler and, say, Python, which does nontrivial magic behind the scenes. 2. An unsafe language, with nontrivial undefined behavior (the overflow/wraparound stuff I mentioned above) with no guide rails like the ones Java provides, where if you overflow the language specifies an error will occur. In C, very little checking code of that type is emitted or specified. 3. A systems programming language, where programmers do unsafe things, like writing values to DMA registers, things the language can't abstract away because... well... you have to write an OS kernel in something, after all. This is unsafe by design, as opposed to the above, where things are unsafe because of a safety/speed trade-off. Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. That's just an uncomfortable position for a language to be in. My point is, it could move Rust-ward and high-level-ward if it ditched some C-isms from the language... but you gave a good explanation of why it won't.

pjmlp 8y ago
> Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. The first systems programming language to introduce this concept was ESPOL , created in 1961, already with the notion of unsafe code blocks. Even better, according to surviving manuals, binaries with unsafe blocks were tainted and required enabling execution by the admin user.
danra 8y ago
> C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. How so? Take std::unique_ptr for example, which exists since C++11. It facilitates using the language in a safer manner, and at a higher level of abstraction (you no longer have to manually malloc and free/new and delete - you just have the concept of scoped ownership), while at the same time not adding any “behind the scenes” magic (e.g. garbage collection) so as not to leave room for any high-level language to be more performant than it is - that’s the real motto of C++, to my understanding.
- msla 8y ago
  > while at the same time not adding any “behind the scenes” magic (e.g. garbage collection) Stuff the compiler does statically is still magic. Anything which makes it more difficult to see the assembly language through the code is magic.
  - msla 8y ago
    It seems odd that this comment, of all of the ones I've made, is getting downvoted. Did I break a taboo? Am I not supposed to notice that the + operator in C++ programs can represent vastly different amounts of CPU work and memory usage in different contexts? Or that RAII does substantial amounts of work which is hidden from the source code? Seems like magic is magic regardless of whether it happens at compile time or runtime.
floatingatoll 8y ago
The interest in making languages safer, rather than in making code written in them safer, seems to have developed into a bigger factor recently than it was in the 90s. I can’t personally think of any not-Rust languages that prioritize operating safety over ease of coding (compared to Rust). Perl lets you rewrite the global interpreter at runtime, PHP enables decades-old code to continue running, Apple Basic offered PEEK and POKE for writing arbitrary bytes to anywhere addressable by the memory controller. I’m sure some exist, but my point is that we have been favoring expanded capabilities for decades and only now are we starting to favor expanded safeties. When taken in that light, it makes perfect sense that C++ has always wanted to expand the capabilities of C without caring about safeties. What else could have resulted from that history?
- steveklabnik 8y ago
  In some sense. I’m not sure when “langsec” started, but it’s certainly older than rust.
  - floatingatoll 8y ago
    While it is certainly true that Langsec has been around since we invented programming, Rust is the only viable language I’ve encountered in practical use anywhere that prioritizes langsec over ease-of-delivery. The focus of C++ on features rather than safeties is echoed by almost every language invented prior to Rust. (I don’t know why Rust was the agent of change in that priority, but I’m very glad for it!) EDIT: COBOL is good at this, or tries to be. Lots of loopholes but it’s clear from this article anyways that they tried to make it a safe language. But they prioritized features like “call arbitrary C functions” over safety, and you can just write unsafe code without even a hint that you’re doomed. That’s perhaps the essence of what I see as the difference: Rust forces you to declare your unsafe intentions to do unsafe things. https://www.kiuwan.com/blog/security-business-oriented-languages-cobol-rpg/ https://www.kiuwan.com/blog/security-business-oriented-langu...
    - steveklabnik 8y ago
      > (I don’t know why Rust was the agent of change in that priority, but I’m very glad for it!) Mozilla did an analysis of security bugs in Firefox and many of them were memory safety issues. That’s part why they sponsored it, at least.

by msla 8y ago

pjmlp 8y ago

> Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. The first systems programming language to introduce this concept was ESPOL , created in 1961, already with the notion of unsafe code blocks. Even better, according to surviving manuals, binaries with unsafe blocks were tainted and required enabling execution by the admin user.

danra 8y ago

> C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. How so? Take std::unique_ptr for example, which exists since C++11. It facilitates using the language in a safer manner, and at a higher level of abstraction (you no longer have to manually malloc and free/new and delete - you just have the concept of scoped ownership), while at the same time not adding any “behind the scenes” magic (e.g. garbage collection) so as not to leave room for any high-level language to be more performant than it is - that’s the real motto of C++, to my understanding.

msla 8y ago
> while at the same time not adding any “behind the scenes” magic (e.g. garbage collection) Stuff the compiler does statically is still magic. Anything which makes it more difficult to see the assembly language through the code is magic.
- msla 8y ago
  It seems odd that this comment, of all of the ones I've made, is getting downvoted. Did I break a taboo? Am I not supposed to notice that the + operator in C++ programs can represent vastly different amounts of CPU work and memory usage in different contexts? Or that RAII does substantial amounts of work which is hidden from the source code? Seems like magic is magic regardless of whether it happens at compile time or runtime.

floatingatoll 8y ago

The interest in making languages safer, rather than in making code written in them safer, seems to have developed into a bigger factor recently than it was in the 90s. I can’t personally think of any not-Rust languages that prioritize operating safety over ease of coding (compared to Rust). Perl lets you rewrite the global interpreter at runtime, PHP enables decades-old code to continue running, Apple Basic offered PEEK and POKE for writing arbitrary bytes to anywhere addressable by the memory controller. I’m sure some exist, but my point is that we have been favoring expanded capabilities for decades and only now are we starting to favor expanded safeties. When taken in that light, it makes perfect sense that C++ has always wanted to expand the capabilities of C without caring about safeties. What else could have resulted from that history?

steveklabnik 8y ago
In some sense. I’m not sure when “langsec” started, but it’s certainly older than rust.
- floatingatoll 8y ago
  While it is certainly true that Langsec has been around since we invented programming, Rust is the only viable language I’ve encountered in practical use anywhere that prioritizes langsec over ease-of-delivery. The focus of C++ on features rather than safeties is echoed by almost every language invented prior to Rust. (I don’t know why Rust was the agent of change in that priority, but I’m very glad for it!) EDIT: COBOL is good at this, or tries to be. Lots of loopholes but it’s clear from this article anyways that they tried to make it a safe language. But they prioritized features like “call arbitrary C functions” over safety, and you can just write unsafe code without even a hint that you’re doomed. That’s perhaps the essence of what I see as the difference: Rust forces you to declare your unsafe intentions to do unsafe things. https://www.kiuwan.com/blog/security-business-oriented-languages-cobol-rpg/ https://www.kiuwan.com/blog/security-business-oriented-langu...
  - steveklabnik 8y ago
    > (I don’t know why Rust was the agent of change in that priority, but I’m very glad for it!) Mozilla did an analysis of security bugs in Firefox and many of them were memory safety issues. That’s part why they sponsored it, at least.