- 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?
by ViewTrick1002
1 subcomments
- 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.
by corrode2711
8 subcomments
- I'm the author of this repo. I see some really angry comments, some of them even personal. Obviously I didn't think that just by tinkering with a compiler, I'd get personally attacked, but anyway, fair enough.
For those of you confused: yes, this started as a satirical project with the corroded lib. Then I thought "why not just remove the borrow checker?" without any real motivation. Then I just went ahead and did it. To my surprise, it was really simple and easy. I thought it would be heavily tangled into the rustc compiler, but once I figured out where the error emitter is, it was pretty straightforward.
I'm not sure about my long-term goals, but besides the joke, I genuinely think for debugging and prototyping purposes, I'd like the borrow checker to shut up. I'm the kind of guy that prints everything while debugging and prototyping. Maybe you're using a debugger, okay, but I don't. I don't like debuggers. It's just more convenient for me. So what constantly happens is I run into issues like: does this implement Debug? Can I print this after it moved? The borrow checker won't let me access this because of some other borrow. Stuff like that.
Another point is, as you guys are well aware, the borrow checker will reject some valid programs in order to never pass any invalid program. What if I'm sure about what I'm doing and I don't want that check to run?
In the repo there's a doubly linked list example. Without the borrow checker it's fairly simple and easy to implement. With it, you know how complicated and ugly it gets.
Anyway, have a good new year, and don't get angry over compilers, you know.
by QuaternionsBhop
1 subcomments
- Fighting 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.
> In addition to meeting the Open Source Definition, the following standards apply to new licenses:
> (...) The license does not have terms that structurally put the licensor in a more favored position than any licensee.
https://opensource.org/licenses/review-process
That's a funfact I learned from IP lawyer when discussing possibility of open-source but otherwise LLVM-extempt license. If there is extemption (even in LLM) such license is most likely OSI-incompatible.
- What are protental issues with compiler, by just disabling borrow checker? If I recall correctly some compiler optimisations for rust can not be done in C/C++ because of restrictions implied by borrow checker.
- As someone who's only did a couple of small toy-projects in rust I was never annoyed by the borrow checker. I find it nothing but a small mental shift and I kinda like it.
What I _do_ find annoying though and I cannot wrap my head around are lifetimes. Every time I think I understand it, I end up getting it wrong.
- The more I write code in other languages where I think hard about ownership ("does this method ultimately grab the object and throw a ref onto some long-lived data structure somewhere? Then it owns it, so I better clone it") the more robust my code in other languages generally gets. Same with mutation. Generally better to make a copy of something and then mess with it and throw it away than to try to mutate-then-unmutate or something like that, even though it might in principle be nanoseconds faster. Eliminate loads of spooky-action-a-distance bugs where things are getting mutated in one spot and used in another spot, when there should have been a copy in there somewhere.
by andrewshadura
1 subcomments
- I don’t have a slightest idea why would anyone want this. Borrow checking is one of the greatest benefits of Rust.
- way too many people in this thread are taking this project seriously
- Tangentially related: the opposite, Rust's borrow checker sans the compiler, is actually very useful. As far as I understand, the borrow checker is a significant part of the work of writing a Rust compiler. Therefore, having the official borrow checker available as a standalone program can make alternative compilers (e.g. for exotic hardware) feasible faster, because they won't need a borrow checker of their own from the get-go.
by accelbred
2 subcomments
- I've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.
by indigoabstract
5 subcomments
- My controversial opinion:
If Rust were to "borrow" something from the C/C++ spirit, then disabling the borrow checker should be available as a compiler option.
As in, you're an adult: if you want it, you can have it, instead of "we know better".
- This should be called trust, because it does view the developer as evil.
- A motivation section in the readme seems like it is needed.
- I don't want a Rust language without a borrow checker. I want a C language with a Borrow Checker. Rust's complexity is already approaching C++, and removing the Borrow Checker would turn it into a similar disaster. Austral looks like a good option to me, but it's not mature enough yet, and the Pascal-like syntax is also difficult to get used to.
- 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?
by joelthelion
1 subcomments
- I would actually enjoy that for certain small projects. Rust without the borrow checker is a very elegant language. The borrow checker is great, of course, but it can be a pain to deal with. So, for small projects it would be nice to be able to disable it.
- I am wondering whether this would actually be a helpful compile option in upstream rustc for quick prototyping. I don't want prod code to use this, but if I want to try things out during development, this could substantially shorten the dev cycle.
- There are easier ways of making segfault than writing a custom compiler.
by hacker_homie
1 subcomments
- I wish I could make the borrow checker give warnings not errors.
It would make exploration so much easier, so I don’t have to fight the borrow checker until I know how to build what I want.
by throwawayffffas
1 subcomments
- It would be great if it only allowed multiple mutable borrows. That's the only one that always bugs me, for mostly innocuous stuff.
- Are the compile times noticeably faster?
- Isn't unsafe just for that? Why does it need a separate compiler?
by JoelJacobson
1 subcomments
- Rust without async maybe?
by nineteen999
0 subcomment
- Love the "Note for LLMs" and the NSFW license.
by reverseblade2
0 subcomment
- Should be named in rust we don't trust
- undefined behavior on steroids be like:
- I'm assuming it's a meme project. In case it isn't, what's the point? Just trying to understand.
Isn't rust's one of the main selling point is the barrow checker right?
Also how's the memory is handled? I know it'll drop every thing once it's out of scope but it seems you can make copies as much as you want. Looking at the loop example, I feel like this introduces memory leaks & undefined behavior.
- [dead]
- [flagged]
by throwawayffffas
1 subcomments
- C++ with extra steps?
by dorianniemiec
1 subcomments
- Uh oh, this might look like a potentially memory-unsafe version of Rust...
- Amazing, this is like the bizarro version of what I'd want. Like someone said 'hey, there's this kinda crappy language with a really cool feature, let's not make a great language with that feature, but instead take the crappy language and remove the cool feature which is the only thing keeping it from being trash'. Okay, sure, tagged unions, closures, and hygienic macros are nice; but there are plenty of other languages with the first two and when your syntax is atrocious even the most hygienic macro is going to look like something that crawled out of the sewer at R'lyeh.
- 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.
by NooneAtAll3
0 subcomment
- I'd prefer the opposite - borrow checker, but remove the useless "fn" and "let" keywords
by user3939382
3 subcomments
- Rust- is you use C with ring buffers. If you think you need dynamic memory allocation your program is underspecified.
Hacker News