49 ms·

> I want to ban crates that panic from my dependency chain. Which means banning anything that allocates memory and thousands of stdlib functions/methods.

by lenkite 11mo ago

echelon 11mo ago
See the immediately preceding sentence. I'm fine with allocation failures. I don't want stupid unwrap()s, improper slice access, or other stupid and totally preventable behavior. There are things inside the engineer's control. I want that to not panic.
- throwaway2037 11mo ago
  Your pair of posts is very interesting to me. Can you share with me: What is your programming environment such that you are "fine with allocation failures"? I'm not doubting you, but for me, if I am doing systems programming with C or C++, my program is doomed if a malloc fails! When I saw your post, I immediately thought: Am I doing it wrong? If I get a NULL back from malloc(), I just terminate with an error message.
  - deredede 11mo ago
    Not GP but I read "I'm fine with allocation failures" as "I'm OK with my program terminating if it can't allocate (but not for other errors)".
    - johnisgood 11mo ago
      I mean, yeah, if I am using a library, as an user of this library, I would like to be able to handle the error myself. Having the library decide to panic, for example, is the opposite of it.
  - PhilipRoman 11mo ago
    Not to mention overcommit has become standard behavior on many systems, so you wouldn't even get a NULL unless you really tried.
  - echelon 11mo ago
    If I can't allocate memory, I'm typically okay with the program terminating. I don't want dependencies deciding to unwrap() or expect() some bullshit and that causing my entire program to crash because I didn't anticipate or handle the panic. Code should be written, to the largest extent possible, to mitigate errors using Result<>. This is just laziness. I want checks in the language to safeguard against lazy Rust developers. I don't want their code in my dependency tree, and I want static guarantees against this. edit: I just searched unwrap() usage on Github, and I'm now kind of worried/angry: https://github.com/search?q=unwrap%28%29+language%3ARust&type=code https://github.com/search?q=unwrap%28%29+language%3ARust&typ... A lot of this is just pure laziness.

> I want to ban crates that panic from my dependency chain. Which means banning anything that allocates memory and thousands of stdlib functions/methods.

by lenkite 11mo ago

> I want to ban crates that panic from my dependency chain. Which means banning anything that allocates memory and thousands of stdlib functions/methods.

echelon 11mo ago

See the immediately preceding sentence. I'm fine with allocation failures. I don't want stupid unwrap()s, improper slice access, or other stupid and totally preventable behavior. There are things inside the engineer's control. I want that to not panic.

throwaway2037 11mo ago
Your pair of posts is very interesting to me. Can you share with me: What is your programming environment such that you are "fine with allocation failures"? I'm not doubting you, but for me, if I am doing systems programming with C or C++, my program is doomed if a malloc fails! When I saw your post, I immediately thought: Am I doing it wrong? If I get a NULL back from malloc(), I just terminate with an error message.
- deredede 11mo ago
  Not GP but I read "I'm fine with allocation failures" as "I'm OK with my program terminating if it can't allocate (but not for other errors)".
  - johnisgood 11mo ago
    I mean, yeah, if I am using a library, as an user of this library, I would like to be able to handle the error myself. Having the library decide to panic, for example, is the opposite of it.
- PhilipRoman 11mo ago
  Not to mention overcommit has become standard behavior on many systems, so you wouldn't even get a NULL unless you really tried.
- echelon 11mo ago
  If I can't allocate memory, I'm typically okay with the program terminating. I don't want dependencies deciding to unwrap() or expect() some bullshit and that causing my entire program to crash because I didn't anticipate or handle the panic. Code should be written, to the largest extent possible, to mitigate errors using Result<>. This is just laziness. I want checks in the language to safeguard against lazy Rust developers. I don't want their code in my dependency tree, and I want static guarantees against this. edit: I just searched unwrap() usage on Github, and I'm now kind of worried/angry: https://github.com/search?q=unwrap%28%29+language%3ARust&type=code https://github.com/search?q=unwrap%28%29+language%3ARust&typ... A lot of this is just pure laziness.