4 ms·

ok... what's the compelling reason why rust's strategy has to be the only way to achieve memory safety? i think some people would argue RAII but you could triv

ok... what's the compelling reason why rust's strategy has to be the only way to achieve memory safety? i think some people would argue RAII but you could trivially just make all deacquisition steps an explicit keyword that must take place in a valid program, and have something (possibly the compiler, possibly not) check that they're there.

EasyMark 2y ago
sometimes things just become the thing to use from momentum. I've personally never been that picky about languages. I code in whatever they pay me to code in. I still code most of my personal projects in c++ and python though.
- throwawaymaths 2y ago
  sounds like a recipe for stockholm syndrome. dont settle! demand more from your programming languages. losing sleep at 2am because you cant figure out a bug in prod is not worth it!
  - baq 2y ago
    Not OP, but: If they aren’t paying for fixing bugs at 2am I’m not fixing bugs at 2am. Simple :)
solidsnack9000 2y ago
I don't think a good conversation can be had if we start by arguing about whether or not "rust's strategy has to be the only way to achieve memory safety". There are other ways to achieve memory safety. Java's strategy is definitely a valid one; it's just not as suitable for systems programming. The strength of Rust's approach ultimately stems from its basis in affine types -- it is a general purpose and relatively rigorous (though not perfect, see https://blog.yoshuawuyts.com/linearity-and-control/ https://blog.yoshuawuyts.com/linearity-and-control/) approach to managing resources. One implication of this is that a point you raised in a message above this one, that "rust's default heap allocation can't be trivially used", actually doesn't connect. All variables in Rust -- stack allocated, allocated on the heap, allocated using a custom allocator like the one in Postgres extensions -- benefit from affine typing.
- throwawaymaths 2y ago
  My point about "strategy" is not theoretical, it's implementation. why does your lifetime typing have to be in the compiler? it could be a part of a static checking tool, and get out of the way of routine development, and guarantee safety on release branches via CI for example. also you could have affine types without RAII. without macros, etc. etc. theres a very wide space of options that are theoretically equivalent to what rust does that are worth exploring for devex reasons.
  - kelnos 2y ago
    How do you know that those other options haven't been explored, and rejected? And remember that your gripes with Rust aren't everyone's gripes. Some of the things you hate about Rust can be things that other people love about Rust. To me, I want all that stuff in the compiler. I don't want to have to run extra linters and validators and other crap to ensure I've done the right thing. I've found myself so much more productive in languages where the compiler succeeding means that everything that can (reasonably) be done to ensure correctness according to that language's guarantees has been checked and has passed. Put another way, if lifetime checking was an external tool, and rustc would happily output binaries that violate lifetime rules, then you could not actually say that Rust is a memory-safe language. "Memory-safe if I do all this other stuff after the compiler tells me it's ok" is not memory-safe. But sure, maybe you aren't persuaded by what I've said above. So what? Neither of us are Linux kernel maintainers, and what we think about this doesn't matter.
    - throwawaymaths 2y ago
      you're arbitrarily drawing the line where memory safe is. i could say rust is memory unsafe because it allows you to write code in an unsafe block. or you could lose memory safety if you use any sort of ~ECS system or functionally lose memory "safe"ty if you turn a pointer lookup into an index into an array (a common strategy for performance, if not to trick the borrow checker). what you really should care about is: is your code memory safe, not is your language memory safe. and this is what is so annoying about rust evangelists. To rust evangelists it's not about the code being memory safe (for example you bet your ass SEL4 is memory safe, even if the code is in C)

EasyMark 2y ago

sometimes things just become the thing to use from momentum. I've personally never been that picky about languages. I code in whatever they pay me to code in. I still code most of my personal projects in c++ and python though.

throwawaymaths 2y ago
sounds like a recipe for stockholm syndrome. dont settle! demand more from your programming languages. losing sleep at 2am because you cant figure out a bug in prod is not worth it!
- baq 2y ago
  Not OP, but: If they aren’t paying for fixing bugs at 2am I’m not fixing bugs at 2am. Simple :)

solidsnack9000 2y ago

I don't think a good conversation can be had if we start by arguing about whether or not "rust's strategy has to be the only way to achieve memory safety". There are other ways to achieve memory safety. Java's strategy is definitely a valid one; it's just not as suitable for systems programming. The strength of Rust's approach ultimately stems from its basis in affine types -- it is a general purpose and relatively rigorous (though not perfect, see https://blog.yoshuawuyts.com/linearity-and-control/ https://blog.yoshuawuyts.com/linearity-and-control/) approach to managing resources. One implication of this is that a point you raised in a message above this one, that "rust's default heap allocation can't be trivially used", actually doesn't connect. All variables in Rust -- stack allocated, allocated on the heap, allocated using a custom allocator like the one in Postgres extensions -- benefit from affine typing.

throwawaymaths 2y ago
My point about "strategy" is not theoretical, it's implementation. why does your lifetime typing have to be in the compiler? it could be a part of a static checking tool, and get out of the way of routine development, and guarantee safety on release branches via CI for example. also you could have affine types without RAII. without macros, etc. etc. theres a very wide space of options that are theoretically equivalent to what rust does that are worth exploring for devex reasons.
- kelnos 2y ago
  How do you know that those other options haven't been explored, and rejected? And remember that your gripes with Rust aren't everyone's gripes. Some of the things you hate about Rust can be things that other people love about Rust. To me, I want all that stuff in the compiler. I don't want to have to run extra linters and validators and other crap to ensure I've done the right thing. I've found myself so much more productive in languages where the compiler succeeding means that everything that can (reasonably) be done to ensure correctness according to that language's guarantees has been checked and has passed. Put another way, if lifetime checking was an external tool, and rustc would happily output binaries that violate lifetime rules, then you could not actually say that Rust is a memory-safe language. "Memory-safe if I do all this other stuff after the compiler tells me it's ok" is not memory-safe. But sure, maybe you aren't persuaded by what I've said above. So what? Neither of us are Linux kernel maintainers, and what we think about this doesn't matter.
  - throwawaymaths 2y ago
    you're arbitrarily drawing the line where memory safe is. i could say rust is memory unsafe because it allows you to write code in an unsafe block. or you could lose memory safety if you use any sort of ~ECS system or functionally lose memory "safe"ty if you turn a pointer lookup into an index into an array (a common strategy for performance, if not to trick the borrow checker). what you really should care about is: is your code memory safe, not is your language memory safe. and this is what is so annoying about rust evangelists. To rust evangelists it's not about the code being memory safe (for example you bet your ass SEL4 is memory safe, even if the code is in C)