Behold: PRQL. I only know it exists not if the errors are good, my SQL needs are simple, but perhaps for some complex data wrangling it could be nicer idk
the point was not on the unsafe word, but a very specific feature of Rust that helps enclosing unsafe code where the compiler wouldn’t be able to 100% verify your logic. no such thing in C++. C++ does not even attempt to verify safety
your response is basically “get better at coding dumbass, I am the safety validator”
The worst thing you can do in non-unsafe Rust is perform an out-of-bounds indexing operation, or anything else that panics. The error you get tells you the panic’s exact location in the source code, down to the line and column. Meanwhile, C and C++ either don’t produce an error at all when accessing uninitialized memory (which is arguably the worst behavior), or it segfaults with zero extra info.
The only way to make Rust segfault is by performing unsafe operations, and those must always be clearly marked.
A stack overflow is technically a segmentation violation. At least on linux the program recives the SIGSEGV signal.
This compiles and I am no rust dev but this does not use unsafe code, right?
While the compiler shows a warning, the error message the program prints when run is not very helpfull IMHO:
thread'main' has overflowed its stack
fatal runtime error: stack overflow
[1] 45211 IOT instruction (core dumped) ../target/debug/rust
Edit: Even the compiler warning can be tricked by making it do recusion in pairs:
Except that many other languages have proven that C++ is simply terrible at providing meaningful errors.
I wish there was something like that for SQL
We can always make a Rust Query Language
Behold: PRQL. I only know it exists not if the errors are good, my SQL needs are simple, but perhaps for some complex data wrangling it could be nicer idk
Feels like some arcane divination magic, I WANT IT
The whole point of a segfault is that you can’t really know anything about it. Even in rust, when you get a segfault there is no meaningful error.
point is, Rust manages to give you not a segfault but a meaningful error almost all the time until you use unsafe
If you’re getting a segfault in C++, it’s also cause you used unsafe code. It’s just not officially enclosed in an “unsafe” block.
the point was not on the unsafe word, but a very specific feature of Rust that helps enclosing unsafe code where the compiler wouldn’t be able to 100% verify your logic. no such thing in C++. C++ does not even attempt to verify safety
your response is basically “get better at coding dumbass, I am the safety validator”
The worst thing you can do in non-unsafe Rust is perform an out-of-bounds indexing operation, or anything else that panics. The error you get tells you the panic’s exact location in the source code, down to the line and column. Meanwhile, C and C++ either don’t produce an error at all when accessing uninitialized memory (which is arguably the worst behavior), or it segfaults with zero extra info.
The only way to make Rust segfault is by performing unsafe operations, and those must always be clearly marked.
Challange accepted. The following Rust code technically segfaults:
fn stackover(a : i64) -> i64 { return stackover(a); } fn main() { println!("{}", stackover(100)); }A stack overflow is technically a segmentation violation. At least on linux the program recives the SIGSEGV signal. This compiles and I am no rust dev but this does not use
unsafecode, right?While the compiler shows a warning, the error message the program prints when run is not very helpfull IMHO:
thread 'main' has overflowed its stack fatal runtime error: stack overflow [1] 45211 IOT instruction (core dumped) ../target/debug/rustEdit: Even the compiler warning can be tricked by making it do recusion in pairs:
fn stackover_a(a : i64) -> i64 { return stackover_b(a); } fn stackover_b(a : i64) -> i64 { return stackover_a(a); } fn main() { println!("{}", stackover_a(100)); }Fair point.