71–80 of 269 posts
This can't possibly be guaranteed to work just by disabling the checker, can it? If Rust optimizes based on borrow-checker assumptions (which I understand it can and does) then wouldn't violating them be UB, unless you also mess with the compiler to disable those optimizations?
This is a binary assumption that you can understand to evaluate to "true" in the absence of a borrow checker. If it is "false" it halts the compiler
Earlier quoted context omitted.
What the point, though? You will get compiling code, but later you would need to reachitecture code to avoid violating rust rules.
Sometimes, you just need to know if an idea will even work or what it would look like. If you have to refactor half the codebase (true story for me once), it makes the change a much harder sell without showing some benefits. IE, it keeps you from discovering better optimizations because you have to pay the costs upfront.
To me it feels like rust is barely readable sometimes. When I read some rust cost, I am often incapable to guess what it does, so it does not feel intuitive. I wish they made something simpler. At least C and C++ have a low barrier of entry and any beginner can write code. I don't think the borrow checker forced rust to be such a complicated language.
> At least C and C++ have a low barrier of entry and any beginner can write code. C/C++ is great at giving that false sense of competence. Then suddenly you're getting a segfault, and you'll never determine why with beginner knowledge, since the crash-line and the mistake-line aren't even in the same zipcode (and or same Git changeset). Rust forces you to not "skip" knowledge steps. If you have a gap in your knowledg…
One of my formative memories learning C came after I wrote a function which accidentally returned a pointer to a variable on the stack. It took me about a week to track that bug down. I found it eventually - and then realised the compiler had been warning me about it the whole time. I'd just been ignoring the warnings "while I got my code working". Ugh. The rust borrow checker wouldn't let you even compile code like that.
If you're going to be working in a programming language for years or even decades, I think the extra complexity (and extra difficulty while learning) is an investment that will pay off. But I'd be very happy for rust to stay a niche language for systems software. C#, Go, Typescript and Swift seem like great choices for making webpages and apps.
I’m not picturing how it works. In rust you don’t have a garbage collector and you don’t manually deallocate - if the compiler is not certain of who drops memory and when, what happens with those ambiguous drops ? In other words, are the silenced errors guaranteed to be memory leaks/use after frees?
Earlier quoted context omitted.
People don't want garbage. But in any case, they don't want straightjackets like the borrow checker. Hence, they use GC'd languages like Go whenever they can.
Straightjackets can be very useful. Haskell (and OCaml etc) give you both straightjackets and a garbage collector. Straightjackets and GC are very compatible. Compared to C, which has neither straightjackets nor a GC (at least not by default).
Earlier quoted context omitted.
People don't want garbage. But in any case, they don't want straightjackets like the borrow checker. Hence, they use GC'd languages like Go whenever they can.
Straightjackets can be very useful. Haskell (and OCaml etc) give you both straightjackets and a garbage collector. Straightjackets and GC are very compatible. Compared to C, which has neither straightjackets nor a GC (at least not by default).
Only if you’re insane.
I’m not picturing how it works. In rust you don’t have a garbage collector and you don’t manually deallocate - if the compiler is not certain of who drops memory and when, what happens with those ambiguous drops ? In other words, are the silenced errors guaranteed to be memory leaks/use after frees?
The borrow checker doesn't decide when things are dropped. It only checks reference uses and doesn't generate any code. This will work exactly the same as long as your program doesn't violate any borrowing rules.
For everyone unaware, this repo is a meme: https://www.reddit.com/r/rust/comments/1q0kvn1/corroded_upda... As a follow on to the corroded meme crate: https://github.com/buyukakyuz/corroded > What Is This > The rust compiler thinks it knows better than you. It won't let you have two pointers to the same thing. It treats you like a mass of incompetence that can't be trusted with a pointer. > We fix that.
fn main() {
let a = String::from("hello");
let b = a;
println!("{a}"); // Works! Prints: hello
}
[flagged]
Certain people feel very emotional about the compilers and interpreters they use You couldn't pay me to work with them
Some programmers think and care a lot about software correctness in a kind of mathematical way. Others just want to ship features and enjoy their lives. Both approaches are fine. They just don't necessarily mix super well.
Some people like to tell you that diverse teams work better. Years ago I worked with someone who had a PhD in psychometrics. She said that's kind of a lie. If you actually look at the research it shows something more interesting. She said the research shows that having a diverse set of backgrounds makes a team perform better. But having a diverse set of values makes a team perform worse. It makes sense. If one person on the team wants to vibe code and someone else wants to make every line of code perfect, you're all in for a bad time.
Earlier quoted context omitted.
Honestly, I thought it was serious because I’ve seen people do things exactly like this, just in different languages. By “this” I mean “spend all their time fighting against the language/framework because they don’t like it, rather than just picking a different language.”
There can be good reasons for choosing a language that you otherwise don't like. Eg legacy software, or because your boss tells you, or because of legal requirements, or because of library availability etc.
EDIT: That last sentence is a bit harsher than I intended. I’m trying to convey the importance of professionalism in our work and remembering the experience of working with people who couldn’t do this brought back some bad memories!