7 ms·

I would question if 100% memory safety is a goal worth achieving in itself. Everything comes with a price. At some point, making memory management more safe sta

I would question if 100% memory safety is a goal worth achieving in itself. Everything comes with a price. At some point, making memory management more safe starts to come with some trade offs, performance, code flexibility and others. Sometimes "good enough" is actually good enough. Why C++ will probably not be changed by other languages is the freedom it provides. It is a language equivalent of giving you absolute power of everything, including digging a massive hole, falling into it and not being able to crawl back out. Yes, Rust is safer in and of itself, and "encourages" safety, but it is also like riding a bike with a safety wheels and cushions strapped everywhere. At some point it will start just getting in your way more than helping you. In the end it boils down to purity and elegance vs. efficiency and practicality. And I'm bigger fan of efficiency and practicality than purity and elegance.

dikaiosune 10y ago
> At some point it will start just getting in your way more than helping you. This doesn't match my experience using Rust, and I've in fact found quite the opposite.
xg15 10y ago
Those are some nice metaphors, but what would a concrete example be, where you absolutely need unsafe memory operations to archieve certain performance levels? ("Need" meaning "it's fundamentally impossible to do it safely", not just "the language provides no way to do this")
- comex 10y ago
  There is no such thing as "fundamentally impossible to do it safely": if you use a theorem prover like Coq then you can formally verify any* code as correct, not just memory safe but truly bug free. See seL4. You'll have to write like 20 lines of proof code for every line of real code, and that code is difficult to write... but it's possible. On the other end of the scale, Rust doesn't have much annotation overhead, but if you truly want zero cost, the borrow checker has significant limitations - you can't have any cycles in your ownership graph, not even parent pointers. The alternative is to live with reference counting overhead, and I'm not sure how much benchmarking has been done of exactly how much overhead that is, but the community tends to value pragmatism over purity, so a lot of data structure libraries take the third option and use `unsafe` fairly liberally behind the scenes. (Which makes the parent's point somewhat inaccurate - Rust is not pure 100% memory safety; unfastening the seatbelt is possible. You just have to explicitly request it.) Of course, there is a huge gulf between those two paradigms. There are languages out there that could be said to live somewhere in the middle, like ATS, but they're not popular, and in general I think the spectrum is quite poorly explored. Certainly in theory there should be a fair amount of room to build from Rust's pragmatic approach and improve on it, by expanding what kinds of ownership models can be checked and/or reducing annotation overhead - but so far nobody has figured out what such an improvement could actually look like (except maybe this C++ thing, if it's not vaporware, heh), so it's up in the air how far this can be taken. I expect and hope Rust itself will continue to improve. * Technically not any, due to Gödel's incompleteness theorem, but certainly any code a human would write. (Anyone who cites either the incompleteness theorem or the halting problem as having practical relevance to basically anything in computing is mistaken.)
  - leni536 10y ago
    > * Technically not any, due to Gödel's incompleteness theorem Sorry, but it's not true, see Gödel's completeness theorem. It basically states that any "true" statement is provable. So you can verify any correct code as correct. There are problems if you try to verify a not correct code as correct though.
    - rntz 10y ago
      Godel's completeness theorem applies to first-order predicate logic, which is not powerful enough on its own even to express, let alone prove, 1+1=2. First order logic is best thought of as a framework on which other, useful logics may be built. And as soon as you add enough power to first-order-logic to capture Peano arithmetic, you run into incompleteness. C++ behavior is almost certainly more complex than Peano arithmetic.
    - catnaroek 10y ago
      > It basically states that any "true" statement is provable. It states that every statement that is true in all models of a first-order theory is provable within the theory.
- AnimalMuppet 10y ago
  Back in the day, I worked on embedded systems that had memory-mapped IO. That is, there would be a hardware register at address 0xF0010010, and you would access it like it was regular memory. So you'd write: *(unsigned long*)0xF0010010 = 0x11; to make the hardware do some particular thing. But if that's how you're controlling your hardware, how are you going to do it "safely"? You'd need your compiler to know which addresses are valid and which are not, which means your compiler needs to know about your custom hardware, and your compiler needs to change each time you revise a circuit board. That seems like an approach that is unlikely to be productive.
  - wnoise 10y ago
    Or your compiler takes a specification file listing memory-mapped addresses...
catnaroek 10y ago
> Yes, Rust is safer in and of itself, and "encourages" safety, but it is also like riding a bike with a safety wheels and cushions strapped everywhere. At some point it will start just getting in your way more than helping you. On the contrary, having the compiler worry about correct resource management frees you to concentrate on other things. > In the end it boils down to purity and elegance vs. efficiency and practicality. You'd be surprised. Elegance and efficiency are aligned more often than not.
- berkut 10y ago
  > On the contrary, having the compiler worry about correct resource management frees you to concentrate on other things. It's a hindrance when you're trying to prototype things to see if something's even worth while.
  - catnaroek 10y ago
    > It's a hindrance when you're trying to prototype things to see if something's even worth while. I don't see the value in deliberately writing software of non-optimal quality. Bugs can happen to anyone, but I take issue with not aiming for excellence.
    - berkut 10y ago
      To see if an algorithm is viable for example. Obviously if you write code for a prototype that has several limitations (say it's single-threaded) in order to determine if a new algorithm provides the correct result, you probably don't want to be concerned at this stage with complete safety if you can run it for the prototype in single threaded mode and probably not have any issues. That might allow you to make a decision as to whether to continue down that path quicker than having to write a more robust solution and then realise it doesn't actually work with certain input data or something.
      - catnaroek 10y ago
        > To see if an algorithm is viable for example. C++ isn't exactly the first language I would pick to test the viability of an algorithm. Too much ceremony, distracting me from the essence of the algorithm. ML seems more up to the task.

dikaiosune 10y ago

> At some point it will start just getting in your way more than helping you. This doesn't match my experience using Rust, and I've in fact found quite the opposite.

xg15 10y ago

Those are some nice metaphors, but what would a concrete example be, where you absolutely need unsafe memory operations to archieve certain performance levels? ("Need" meaning "it's fundamentally impossible to do it safely", not just "the language provides no way to do this")

comex 10y ago
There is no such thing as "fundamentally impossible to do it safely": if you use a theorem prover like Coq then you can formally verify any* code as correct, not just memory safe but truly bug free. See seL4. You'll have to write like 20 lines of proof code for every line of real code, and that code is difficult to write... but it's possible. On the other end of the scale, Rust doesn't have much annotation overhead, but if you truly want zero cost, the borrow checker has significant limitations - you can't have any cycles in your ownership graph, not even parent pointers. The alternative is to live with reference counting overhead, and I'm not sure how much benchmarking has been done of exactly how much overhead that is, but the community tends to value pragmatism over purity, so a lot of data structure libraries take the third option and use `unsafe` fairly liberally behind the scenes. (Which makes the parent's point somewhat inaccurate - Rust is not pure 100% memory safety; unfastening the seatbelt is possible. You just have to explicitly request it.) Of course, there is a huge gulf between those two paradigms. There are languages out there that could be said to live somewhere in the middle, like ATS, but they're not popular, and in general I think the spectrum is quite poorly explored. Certainly in theory there should be a fair amount of room to build from Rust's pragmatic approach and improve on it, by expanding what kinds of ownership models can be checked and/or reducing annotation overhead - but so far nobody has figured out what such an improvement could actually look like (except maybe this C++ thing, if it's not vaporware, heh), so it's up in the air how far this can be taken. I expect and hope Rust itself will continue to improve. * Technically not any, due to Gödel's incompleteness theorem, but certainly any code a human would write. (Anyone who cites either the incompleteness theorem or the halting problem as having practical relevance to basically anything in computing is mistaken.)
- leni536 10y ago
  > * Technically not any, due to Gödel's incompleteness theorem Sorry, but it's not true, see Gödel's completeness theorem. It basically states that any "true" statement is provable. So you can verify any correct code as correct. There are problems if you try to verify a not correct code as correct though.
  - rntz 10y ago
    Godel's completeness theorem applies to first-order predicate logic, which is not powerful enough on its own even to express, let alone prove, 1+1=2. First order logic is best thought of as a framework on which other, useful logics may be built. And as soon as you add enough power to first-order-logic to capture Peano arithmetic, you run into incompleteness. C++ behavior is almost certainly more complex than Peano arithmetic.
  - catnaroek 10y ago
    > It basically states that any "true" statement is provable. It states that every statement that is true in all models of a first-order theory is provable within the theory.
AnimalMuppet 10y ago
Back in the day, I worked on embedded systems that had memory-mapped IO. That is, there would be a hardware register at address 0xF0010010, and you would access it like it was regular memory. So you'd write: *(unsigned long*)0xF0010010 = 0x11; to make the hardware do some particular thing. But if that's how you're controlling your hardware, how are you going to do it "safely"? You'd need your compiler to know which addresses are valid and which are not, which means your compiler needs to know about your custom hardware, and your compiler needs to change each time you revise a circuit board. That seems like an approach that is unlikely to be productive.
- wnoise 10y ago
  Or your compiler takes a specification file listing memory-mapped addresses...

catnaroek 10y ago

> Yes, Rust is safer in and of itself, and "encourages" safety, but it is also like riding a bike with a safety wheels and cushions strapped everywhere. At some point it will start just getting in your way more than helping you. On the contrary, having the compiler worry about correct resource management frees you to concentrate on other things. > In the end it boils down to purity and elegance vs. efficiency and practicality. You'd be surprised. Elegance and efficiency are aligned more often than not.

berkut 10y ago
> On the contrary, having the compiler worry about correct resource management frees you to concentrate on other things. It's a hindrance when you're trying to prototype things to see if something's even worth while.
- catnaroek 10y ago
  > It's a hindrance when you're trying to prototype things to see if something's even worth while. I don't see the value in deliberately writing software of non-optimal quality. Bugs can happen to anyone, but I take issue with not aiming for excellence.
  - berkut 10y ago
    To see if an algorithm is viable for example. Obviously if you write code for a prototype that has several limitations (say it's single-threaded) in order to determine if a new algorithm provides the correct result, you probably don't want to be concerned at this stage with complete safety if you can run it for the prototype in single threaded mode and probably not have any issues. That might allow you to make a decision as to whether to continue down that path quicker than having to write a more robust solution and then realise it doesn't actually work with certain input data or something.
    - catnaroek 10y ago
      > To see if an algorithm is viable for example. C++ isn't exactly the first language I would pick to test the viability of an algorithm. Too much ceremony, distracting me from the essence of the algorithm. ML seems more up to the task.