[dead]
Rust--: Rust without the borrow checker
171–180 of 269 posts
Re: Rust--: Rust without the borrow checker
#172Earlier quoted context omitted.
If you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. Evidently mil…
I have been using kde for years now without a single problem. Calling cpp garbage sounds wrong.
KDE is a great desktop environment , but it's also notorious for being a buggy and unpolished DE [1]. It's good your experience wasn't like that, but it's certainly not how the software is generally perceived.
[1]: Of course, different versions have different levels of stability. Also, some of these bugs and problems wouldn't be prevented by using an alternative language such as Rust.
Re: Rust--: Rust without the borrow checker
#173Earlier quoted context omitted.
Did I write that I hated somebody? I don't think I wrote anything of the sort. I can't say my thoughts about Bjarne for example rise to hatred, nobody should have humoured him in the 1980s, but we're not talking about what happened when rich idiots humoured The Donald or something as serious as that - nobody died, we just got a lot of software written in a crap programming language, I've had worse Thursdays. And alth…
Correct me if I'm wrong, but I don't think you think that C++ programmers actually want to write "broken garbage", so when you say "millions of people want broken garbage" the implication is that a) they do write broken garbage, b) they're so stupid don't even know that is what they are doing. I can't really read else than in the same vein as an apartheid-era white South-African statement starting "all blacks ...", i…
I can't help how you feel about it, but what I see is people who supposedly "don't want" something to happen and yet take little or no concrete action to prevent it. When it comes to their memory safety problem WG21 talks about how they want to address the problem but won't take appropriate steps. Years of conference talks about safety, and C++ 26 is going to... encourage tool vendors to diagnose some common mistakes. Safe C++ was rejected, and indeed Herb had WG21 write a new "standing rule" which imagines into existence principles for the language that in effect forbid any such change.
Think Republican Senators offering thoughts and prayers after a school shooting, rather than Apartheid era white South Africans.
Re: Rust--: Rust without the borrow checker
#174Earlier quoted context omitted.
If you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. Evidently mil…
I have been using kde for years now without a single problem. Calling cpp garbage sounds wrong.
Well FWIW, the original poster's anti-C++ statements aside, removing the borrow checker does nothing except allow you to write thread-unsafe (or race condition-unsafe) code. Therefore, the only change this really makes is allowing you to write slightly more ergonomic code that could well break somewhere at some point in time unexpectedly.
Re: Rust--: Rust without the borrow checker
#175way too many people in this thread are taking this project seriously
Re: Rust--: Rust without the borrow checker
#176Earlier quoted context omitted.
Is rust simple aesthetics to you? Why use rust, or any language at all really, at all then? The whole point of formal languages is to point a gun at the people who refuse to be adults. If we can't have this, C itself offers zero benefit over assembly.
You don't think assembly is more tedious to write than C? I don't think that's because of what C does/doesn't "allow" you to do.
Of course it is. C does allow named functions and variables. C doesn’t allow arbitrary jumps.
Those are two reasons why C is less tedious than assembly.
Re: Rust--: Rust without the borrow checker
#177Rust without async maybe?
This would actually be good though!
Re: Rust--: Rust without the borrow checker
#178Fighting the borrow checker is something you do when you're learning Rust. After you learn how to design things that way in the first place, it's just there to keep you honest.
To be fair, working on the Rust compiler is also something to do when you're learning Rust. I guess this person is killing two birds with one stone.
Re: Rust--: Rust without the borrow checker
#179Earlier quoted context omitted.
How are we still having the same trade off discussion being argued so black and white when reality has shown that both options are preferred by different groups. Rust says that all incorrect programs (in terms of memory safety) are invalid but the trade is that some correct programs will also be marked as invalid because the compiler can't prove them correct. C++ says that all correct programs are valid but the trade…
>C++ says that all correct programs are valid but the trade is that some incorrect programs are also valid. C++ does not say this, in fact no statically typed programming language says this, they all reject programs that could in principle be correct but get rejected because of some property of the type system. You are trying to present a false dichotomy that simply does not exist and ignoring the many nuances and tr…
Nope. C++ really does deliberately require that compilers will in some cases emit a program which does... something even though what you wrote isn't a C++ program.
Yes, that's very stupid, but they did it with eyes open, it's not a mistake. In the C++ ISO document the words you're looking are roughly (exact phrasing varies from one clause to another) Ill-formed No Diagnostic Required (abbreviated as IFNDR).
What this means is that these programs are Ill-formed (not C++ programs) but they compile anyway (No diagnostic is required - a diagnostic would be an error or warning).
Why do this? Well because of Rice's Theorem. They want a lot of tricky semantic requirements for their language but Rice showed (back in like 1950) that all the non-trivial semantic requirements are Undecidable. So it's impossible for the compiler to correctly diagnose these for all cases. Now, you could (and Rust does) choose to say if we're not sure we'll reject the program. But C++ chose the exact opposite path.
Re: Rust--: Rust without the borrow checker
#180Earlier quoted context omitted.
> This is the koolaid I am not willing to drink. > If you can add safety very carefully on top of unsafe stuff (without any help from compiler), why not just use `c` and add safety by just being very careful? There is help from the compiler - the compiler lets the safe code expose an interface that creates strict requirements about how it is being called with and interacted with. The C language isn't expressive enoug…
>the compiler lets the safe code expose an interface that creates strict requirements about how it is being called with and interacted with.. The compiler does not and cannot check if these strict requirements are enough for the intended "safety". Right? It is the judgement of the programmer. And what is stopping a `c` function with such requirements to be wrapped in some code that actually checks these requirements…
> The compiler does not and cannot check if these strict requirements are enough for the intended "safety". Right? It is the judgement of the programmer.
Yes*. It's up to the programmer to check that the safe abstraction they create around unsafe code guarantees all the requirements the unsafe code needs are upheld. The point is that that's done once, and then all the safe code using that safe abstraction can't possibly fail to meet those requirements - or in other words any safety related bug is always in the relatively small amount of code that uses unsafe and builds those safe abstraction.
> And what is stopping a `c` function with such requirements to be wrapped in some code that [doesn't] actually checks these requirements are met?
Assuming my edit to your comment is correct - nothing. It's merely the case that any such bug would be in the small amount of clearly labelled (with the unsafe keyword) binding code instead of "anywhere".
> The only thing that the rust compiler enables is to include a feature to mark a specific function as unsafe.
No, the rust compiler has a lot more features than just a way to mark specific functions as unsafe. The borrow checker, and it's associated lifetime constraints, enforcing that variables that are moved out of (and aren't `Copy`) aren't used, is one obvious example.
Another example is marking how data can be used across threads with traits like `Send` and `Sync`. Another - when compared to C anyways - is simply having a visibility system so that you can create structs with fields that aren't directly accessible via other code (so you can control every single function that directly accesses them and maintain invariants in those functions).
> In both cases there is zero help from the compiler to actually verify that the checks that are done on top are sufficient.
Yes and no, "unsafe" in rust is synonymous with "the compiler isn't able to verify this for you". Typically rust docs do a pretty good job of enumerating exactly what the programmer must verify. There are tools that try to help the programmer do this, from simple things like being able to enable a lint that checks every time you wrote unsafe you left a comment saying why it's ok, and that you actually wrote something the compiler couldn't verify in the first place. To complex things like having a (very slow) interpreter that carefully checks that in at least one specific execution every required invariant is maintained (with the exception of some FFI stuff that it fails on as it is unable to see across language boundaries sufficiently well).
The rust ecosystem is very interested in tools that make it easier to write correct unsafe code. It's just rather fundamentally a hard problem.
* Technically there are very experimental proof systems that can check some cases these days. But I wouldn't say they are ready for prime time use yet.