Rust--: Rust without the borrow checker

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.”

eru9• 7 months ago

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.

MangoToupe5• 7 months ago

Certain people feel very emotional about the compilers and interpreters they use

You couldn't pay me to work with them

josephg5• 7 months ago

Don't worry, they probably wouldn't want to work with you either.

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.

corrode27116• 7 months ago

And you were right.

dang• 7 months ago

Could you please not post this sort of snarky-generic-meta comment? They attract upvotes and then stick at the top of the thread, choking out actually interesting discussion. (That's where this one was, but I'm going to mark it off topic and downweight it now.)

I completely understand your frustration about how common shallow-indignant comments are. But it doesn't help to post shallow-indignant or snarky comments of your own about it - it just produces even more of the same, or worse.

The way to combat shallow-indignant, predictable, tedious, etc., threads is to find something that you're genuinely curious and open about, and post from that place instead.

https://news.ycombinator.com/newsguidelines.html

fithisux2• 7 months ago

This should be called trust, because it does view the developer as evil.

fithisux2• 7 months ago

I meant "it does not view"

gspr2• 7 months ago

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.

bananaflag• 7 months ago

I get your point, but still you haven't identified a use for the borrow checker sans the compiler.

tialaramex13• 7 months ago

Why would this matter? The borrowck is (a) not needed during bring-up because as its name suggests it is merely a check, so going without it just means you can write nonsense and then unbounded undefined behaviour results, but (b) written entirely in Rust so you can just compile it with the rest of this "exotic hardware" Rust compiler you've built.

gspr2• 7 months ago

Yeah, you're right, I'm misremembering something here. Thanks for the correction.

raluk• 7 months ago

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.

0xdeafbeef2• 7 months ago

Rust can set restricts to all pointers, because 1 mut xor many shared refs rule. Borrow checker empowers this. https://en.wikipedia.org/wiki/Restrict

imtringued2• 7 months ago

The crazy part about this is that (auto) vectorization in Rust looks something like this: iter.chunks(32).map(vectorized)

Where the vectorized function checks if the chunk has length 32, if yes run the algorithm, else run the algorithm.

The compiler knows that the chunk has a fixed size at compile time in the first block, which means it can now attempt to vectorize the algorithm with a SIMD size of 32. The else block handles the scalar case, where the chunk is smaller than 32.

vanviegen2• 7 months ago

Without the borrow checker, how should memory be managed? Just never deallocate?

flohofwoe• 7 months ago

It would be the same as in any language with manual memory management, you'd simply get a dangling pointer access. The 'move-by-default' semantics of Rust just makes this a lot trickier than in a 'copy-by-default' language though.

It's actually interesting to me that the Rust borrow checker can 'simply' be disabled (e.g. no language- or stdlib-features really depending on the borrow checker pass) - not that it's very useful in practice though.

masklinn7• 7 months ago

The borrow checker does not deal with ownership, which is what rust’s memory management leverages. The borrow checker validates that borrows (references) are valid aka that they don’t outlive their sources and that exclusive borrows don’t overlap.

The borrow checker does not influence codegen at all.

eptcyka• 7 months ago

The same as C++, destructors get called when an object goes out of scope.

nineteen999• 7 months ago

Love the "Note for LLMs" and the NSFW license.

user39393822• 7 months ago

Rust- is you use C with ring buffers. If you think you need dynamic memory allocation your program is underspecified.

oskarbh7• 7 months ago

How does "zero dynamic allocation" work in practice for something like a text editor IE. vscode or other apps that let users open arbitrary files?

lpcvoid• 7 months ago

Just impose a maximum buffer size ;)

Const-me3• 7 months ago

It’s technically possible to do, just very complicated and hard. Quite often, prohibitively so.

Still, the main idea is despite the input files are arbitrarily large, you don’t need an entire file in memory because displays aren’t remotely large enough to render a megabyte of text. Technically, you can only load a visible portion of the input file, and stream from/to disk when user scrolls. Furthermore, if you own the file format, you can design it in a way which allowing editing without overwriting the entire file: mark deleted portions without moving subsequent content, write inserts to the end of files, maybe organize the file as a B+ tree, etc.

That’s how software like Word 97 supported editing of documents much larger than available memory. As you can imagine, the complexity of such file format, and the software handling them, was overwhelming. Which is why software developers stopped doing things like that as soon as computers gained enough memory to keep entire documents, and instead serialize them into sane formats like zipped XMLs in case of modern MS office.

mrits2• 7 months ago

Instead of over specifying a program you can just use dynamic memory allocation

rcxdude• 7 months ago

Avoiding dynamic allocation does not avoid memory unsafety in C.

user39393822• 7 months ago

Let’s put it this way. If it wasn’t a feature rust wouldn’t exist.

throwawayffffas2• 7 months ago

It would be great if it only allowed multiple mutable borrows. That's the only one that always bugs me, for mostly innocuous stuff.

threethirtytwo• 7 months ago

This isn’t actually unsafe unless shared across threads right? Maybe the borrow checker needs to be more nuanced to differentiate this rather then outright banning it all together. It would increase the logic of the borrow checker by a lot though.

aw16211075• 7 months ago

This isn’t actually unsafe unless shared across threads right?

Multiple mutable borrows do not need multiple threads to cause UB. Consider the following:

    fn main() {
        let mut v = vec![0, 1, 2];
        let e = &mut v[0];
        v.push(3);
        *e = 4;
    }

rustc refuses to compile this code due to multiple mutable borrows of `v` [0]:

    error[E0499]: cannot borrow `v` as mutable more than once at a time
     --> <source>:4:5
      |
    3 |     let e = &mut v[0];
      |                  - first mutable borrow occurs here
    4 |     v.push(3);
      |     ^ second mutable borrow occurs here
    5 |     *e = 4;
      |     ------ first borrow later used here

If rustc allowed multiple mutable borrows here, `v.push(3)` would cause the underlying vec to reallocate, which invalidates `e`, and so `*e = 4` would cause UB.

[0] https://rust.godbolt.org/z/bsxKTWG3K

xlii• 7 months ago

    > 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.

w4rh4wk5• 7 months ago

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.

0xdeafbeef2• 7 months ago

What the point, though? You will get compiling code, but later you would need to reachitecture code to avoid violating rust rules.

withinboredom3• 7 months ago

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.

Philpax• 7 months ago

After a while, you just don't write code that would cause substantial borrow-checker problems, even when prototyping. I'd say the slow compile times are much more of an impediment for a practicing Rust prototyper than the borrow checker.

ismailmaj• 7 months ago

undefined behavior on steroids be like:

hacker_homie• 7 months ago

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.

hoppp2• 7 months ago

Then you have code full of warnings and undefined behavior?

I think fighting the borrow checker is more like a rite of passage. Rust is not my favorite language but the borrow checker is great.

leoh• 7 months ago

This is not a hacker’s take

dataflow5• 7 months ago

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?

tialaramex13• 7 months ago

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 millions of people want broken garbage, Herb Sutter even wrote a piece celebrating how many more C++ programmers and projects there were last year, churning out yet more broken garbage, it's a metaphor for 2025 I guess.

ozgrakkurt• 7 months ago

I have been using kde for years now without a single problem. Calling cpp garbage sounds wrong.

amelius• 7 months ago

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.

jjgreen2• 7 months ago

It is possible to like something without hating people who like something else, can't people just live and let live?

ada00002• 7 months ago

herb sutter and the c++ community as a whole have put a lot of energy into improving the language and reducing UB; this has been a primary focus of C++26. they are not encouraging people to “churn out more broken garbage”, they are encouraging people to write better code in the language they have spent years developing libraries and expertise in.

lordgroff2• 7 months ago

The attitude expressed here and that tends to surface in any Rust discussion is the reason I completely lost interest in the language.

pron7• 7 months ago

For all its faults, and it has many (though Rust shares most of them), few programming languages have yielded more value than C++. Maybe only C and Java. Calling C++ software "garbage" is a bonkers exaggeration and a wildly distorted view of the state of software.

Spivak2• 7 months ago

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 is that some incorrect programs are also valid.

You see the same trade being made with various type systems and people still debate about it but ultimately accept that they're both valid and not garbage.

MangoToupe5• 7 months ago

If Rust optimizes based on borrow-checker assumptions

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

CGamesPlay• 7 months ago

Yes. An analog would be uninitialized memory. The compiler is free to make optimizations that assume that uninitialized memory holds every value and no value simultaneously (because it is undefined behavior to ever read it).

In the following example, z is dereferenced one time and assigned to both x and y, but if z and x are aliased, then this is an invalid optimization.

    fn increment_by(x: &mut i32, y: &mut i32, z: &i32) {
        *x = *z;
        *y = *z;
    }

https://rust.godbolt.org/z/Mc6fvTzPG

OptionOfT• 7 months ago

Yes. An analog would be uninitialized memory. The compiler is free to make optimizations that assume that uninitialized memory holds every value and no value simultaneously (because it is undefined behavior to ever read it).

Even casting a MaybeUninit<i32>::uninit() to i32 is UB, even though every bit pattern in that memory space is a valid i32.

What's interesting is your code example is solved in Rust. By preventing a reference and a mutable reference all of the sudden the code becomes easier to reason about. No need for special attributes: https://www.lysator.liu.se/c/restrict.html#comparison-with-n...

masklinn7• 7 months ago

This can't possibly be guaranteed to work just by disabling the checker, can it?

It works in the sense that the borrow checker stops bothering you and the compiler will compile your code. It will even work fine as long as you don't write code which invokes UB (which does include code which would not pass the borrow checker, as the borrow checker necessarily rejects valid programs in order to forbid all invalid programs).

dataflow5• 7 months ago

It will even work fine as long as you don't write code which invokes UB (which does include code which would not pass the borrow checker, as the borrow checker necessarily rejects valid programs in order to forbid all invalid programs).

To be clear, by "this" I meant "[allowing] code that would normally violate Rust's borrowing rules to compile and run successfully," which both of us seem to believe to be UB.

Sytten• 7 months ago

Correct, I was reading a very interesting blog post [1] on how the rust compiler will change the LLVM annotaions like sending noalias for mutable pointer. This changes a lot the generated machine code. Disabling the borrow checker won't enable those LLVM flags.

[1] https://lukefleed.xyz/posts/who-owns-the-memory-pt1/

djdjfljfgddfg2• 7 months ago

I guess this is like putting an unsafe { } around all your code...

aw16211075• 7 months ago

Not really. Unsafe blocks don't change the semantics of Rust code or disable Rust's normal checks, so if you have something that doesn't compile due to a borrow checker error adding an unsafe block around that code will do precisely nothing to get around that error.

Narishma• 7 months ago

No, unsafe doesn't disable the borrow checker.

jokoon• 7 months ago

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.

mentalgear• 7 months ago

I can just second that. Maybe someone (or some LLM) can write a nice superset of Rust that is more readable - so the barrier of entry drops significantly and we can all write better, more efficient and memory-safe code!

torginus2• 7 months ago

I feel exactly the same - C++ might be a much more complex and arcane language when you consider its entire feature set, and all the syntactic machinery (I figured out by looking at STL or Boost code, just how much of C++ I don't know or understand), you can choose to not engage with most of the language. Hell, even stuff like unique_ptr is optional when you're just starting out.

But with Rust, you have to understand almost all of the language very intimately to be a productive programmer, and Rust is not that great at hiding complexity, as in fairly innocious decisions often have far-reaching consequences down the line.

mrits2• 7 months ago

I've shipped a lot of Rust software without the understanding or even attempting to learn a lot of the language. There is plenty of things in core libraries around traits that I have no idea how they work or really care.

drogus• 7 months ago

you have to understand almost all of the language very intimately to be a productive programmer,

I've seen absolute Rust noobs write production code in Rust, I have no idea where did you get that notion from. Most of the apps I've written or I've worked with don't even need to use explicit lifetimes at all. If you don't need absolute performance with almost none memory allocations, it's honestly not rocket science. Even more so if you're writing web backends. Then the code doesn't really differ that much from Go.

sesm• 7 months ago

C++ doesn't have low barrier of entry, I almost quit programming as a teen because of C++.

torginus2• 7 months ago

Imo the worst thing about starting out with C++ (which is much better with Rust), is the lack of credible package management/build system that allows you to just install packages.

This used to be even more true previously than today. Nowadays, there's stuff like vcpkg, and tons of resources, but I still wouldn't call it straightforward compared to something like nuget or cargo.

It tooke me more time to figure out CMake than entire other programming languages.

tialaramex13• 7 months ago

There's a weird cognitive bias where somehow people justify "I compiled this Hello World C++ project " as "C++ is easy" and yet "I wasn't able to understand how this optimized linear algebra library works" gets classed as "Rust is hard".

In reality it matters what you already know, and whether you want to understand deeply or are just interested in enough surface understanding to write software. There's a reason C++ has an entire book about its many, many types of initialization for example.

vanviegen2• 7 months ago

Yes, Rust has a pretty steep learning curve. If you're not writing very low level stuff and don't need to squeeze out every last bit of performance, there are many other, simpler languages to choose from.

I think we may safely assume that Rust's designers are smart people that have made every effort to keep Rust as simple as it can be, given its intended use.

estebank2• 7 months ago

If you're not writing very low level stuff and don't need to squeeze out every last bit of performance, Rust code can be very simple and easy to understand as well.

Someone12342• 7 months ago

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 knowledge/understanding the compiler will call you out immediately. C/C++ will happily let your dangerously bad code compile and kinda-run, until it doesn't.

I'm not anti-C/C++, I've actually written tons. I love C in particular. But saying that they're beginner-friendly feels wrong, a lot of people quit the language because "random stuff" starts to go wrong, and they lack the knowledge to determine why.

josephg5• 7 months ago

Yep. I've heard it said that Rust forces you to experience all the pain up front. C will happily compile very broken code.

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.

spoiler• 7 months ago

I think the barrier to entry with Rust is lower than C++. Like was way lower... And I've been writing C++ for way long than Rust, so I'm probably a bit biased

josephg5• 7 months ago

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 feel torn with this sentiment.

On one hand, I totally agree. Rust's "foreign" ideas (borrowck, lifetimes, match expressions, traits, etc) make it harder to learn because there's a bunch of new concepts that nobody has really worked with before. Some of this stuff - lifetimes and borrows especially - really demand a lot of imagination on behalf of the programmer to be able to understand what's actually going on. The amount of thinking I do per shipped line of code seems higher for rust than it does for languages like Go, Typescript and C#. And sometimes C.

On the other hand, I learned C about 30 years ago. Not only have I forgotten how hard it was to learn, but I had the brain of a teenager at the time. And now I'm in my (early) 40s. I'm scared that some of the struggle I went through learning rust came because my brain is old now, and I've forgotten what its like to be out of my depth with a programming language. Learning rust requires shaking up some old neurons. And that's really good for us, but it sucks.

In reality, I think its a bit of both. I've been using rust a lot for about 3-4 years now. Its gotten way easier. But I still prototype a fair bit of algorithmic code in typescript first because I find TS makes it easier to iterate. That implies rust is actually more complex. But, some people pick rust as their first language and it seems to work out fine? I'm not sure.

I don't think the borrow checker forced rust to be such a complicated language.

Which parts of rust seem complicated? I've found a lot of the things I struggled with at first got a lot easier with familiarity. I love traits and match expressions. I love rust's implementation of generics. I love most things about cargo and the module system. But also, some parts of rust annoy me a lot more now, a few years in.

I disagree with your comment. I think the main source of complexity in rust comes from lifetimes - which are required by the borrow checker. For example, its not obvious when you need to put lifetimes in explicitly and when you can elide them. When does the borrow checker understand my code? (Eg, can you mutably borrow two different elements in an array at the same time?). I also still don't really understand Higher-Rank Trait Bounds.

I also still find Pin really confusing. In general I think async and Futures in rust have some big design flaws. It also really bothers me that there's a class of data types that the compiler can generate and use, which are impossible to name in the language. And some of the rules around derive and traits are annoying and silly. Eg derive(Clone) on a generic struct adds the constraint T: Clone, which is straight out wrong. And rust needs a better answer to the orphan rule.

But in general, if you take out the borrow checker, I find rust to be simpler and easier to read than most C++. There's no headers. No exceptions. No wild template nonsense. And there's generally way less weird magic going on. Eg, Foo(bar); could mean about 8 different things in C++. Rust isn't like that. Rust is simple enough you can just read the standard library, even as a beginner, and its great. C++'s STL is a disaster to read.

Rust is definitely more complex than C. But you do get some lovely features for that extra cognitive overhead. Whether or not thats worth it is up to you. In general - and I've been saying this for years - I feel like the language I really want is rust 2. I can't wait for someone to take rust's best ideas and refine them into a simpler language.

masklinn7• 7 months ago

To me it feels like rust is barely readable sometimes. [...] C++ have a low barrier of entry and any beginner can write code.

Here's rust code:

    fn main() {
        println!("Hello, world");
    }

Here is the equivalent C++ for the vast majority of its life (any time before C++23, has MS even shipped C++23 support yet?):

    #include <iostream>

    int main() {
      std::cout << "Hello World!" << std::endl;
      return 0;
    }

C++ initialisation alone is a more complex topic than pretty much any facet of Rust. And it's not hard to find C++ which is utterly inscrutable.

andrewshadura• 7 months ago

I don’t have a slightest idea why would anyone want this. Borrow checking is one of the greatest benefits of Rust.

Someone12342• 7 months ago

It is funny.

ViewTrick10023• 7 months ago

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.

amluto• 7 months ago

It does seem like satire. The very first example is:

    fn main() {
        let a = String::from("hello");
        let b = a;
        println!("{a}");  // Works! Prints: hello
    }

This is not “I have correct code but Rust can’t tell it’s correct.” This is “wow, this code is intentionally outrageously wrong, obviously dereferences a pointer that is invalid, and happens to work anyway.”

17186274406• 7 months ago

this code is intentionally outrageously wrong

Can you explain why? Why can't both a and b point at the same string object? Does `let b = a;` do something like a destructive move?

torben-friis2• 7 months ago

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?

eru9• 7 months ago

I don't think so, I don't think Rust's borrow checker is free of false negatives.

gliptic• 7 months ago

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.

torben-friis2• 7 months ago

No, I get that from an architectural perspective they are separate processes. The point is, unlike in other languages, the compiler is developed assuming the input has been borrow checked, right? So it is surprising to me that it doesn’t blow up somewhere when that invariant doesn’t hold.

MangoToupe5• 7 months ago

Rust's concept of lifetime and scopes exists independently of the borrow checker

juliangoldsmith• 7 months ago

The silenced errors aren't guaranteed to be memory leaks or use after frees. There are some situations where memory is being handled properly, but the borrow checker isn't able to prove it.

One example might be a tree-like struct where a parent and child have references to each other. Even if everything is cleaned up properly, the borrow checker has no way to know that when the struct is created. Solving it requires unsafe at some point, usually through something like RefCell.

antonvs• 7 months ago

In other words, are the silenced errors guaranteed to be memory leaks/use after frees?

No, not at all. The examples at the beginning of the article show this - they'll execute correctly. The borrow checker is quite conservative, and rules out all sorts of code that won't (normally!) cause runtime errors.

It's fairly easy to see this if you think about the core of Rust's ownership model: every value in Rust has a single owner. The compiler enforces that for any value, there's either one mutable reference or any number of immutable references to it at a time.

This model has the advantage of being simple, easy to reason about, and ruling out large classes of errors. But like most static checks, including e.g. traditional type checks, it also rules out a great deal of otherwise valid code.

It's easy to think of examples in which you have multiple mutable references to a value that won't cause errors. Aside from trivial examples like in the article, in C-like languages you can have many concurrent mutable references to the same mutable value. You can safely (with some caveats) manage access to it via locks, protocols, documentation, or just being careful. Rust with the borrow checker simply doesn't allow multiple concurrent mutable references to the same value to exist. Rust without the borrow checker, as in the article, would allow this.

gpm7• 7 months ago

I'm pretty sure that every example except example-3 in the readme intentionally invokes undefined behavior - if that helps you picture how it works ;)

tmtvl• 7 months ago

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.

p0w3n3d• 7 months ago

There are easier ways of making segfault than writing a custom compiler.

NooneAtAll3• 7 months ago

I'd prefer the opposite - borrow checker, but remove the useless "fn" and "let" keywords

reverseblade2• 7 months ago

Should be named in rust we don't trust

0xMohan• 7 months ago

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.

joelthelion• 7 months ago

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.

estebank2• 7 months ago

Instead of disabling the borrow checker what should be possible is to promote borrows to Rc/Arc as needed. I would want to restrict this mode to one where it can only work locally, never publishable to crates.io. It would be particularly useful when running tests, then instead of a compile error you can also get a runtime error with better information about the cases the borrow checker was actually encountering.

corrode27116• 7 months ago

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.

whatshisface2• 7 months ago

I think there is probably a way to do what you're doing with unsafe. You could write a library that copies handles and can dump potentially freed memory afterwards.

g-mork• 7 months ago

Some kind of cargo plugin that transforms all references in the project into pointers and casts prior to feeding to rustc would probably be the best practice and highly maintainable route I'd go. like "cargo expand" but with a fancy catchier name that encourages new users to rely on it. "cargo autofix" might work

jvanderbot• 7 months ago

There's definitely a way to do it without unsafe! It just isn't as simple as dropping one println out so.... Lets alter the compiler?

I gotta applaud that level of my-way-or-the-highway

CodeMage• 7 months ago

Then I thought "why not just remove the borrow checker?" without any real motivation.

Reminds me of a chemistry kit I had as a kid. None of this tame, safe stuff you can buy these days. Mine was a gift from my dad and I never thought of asking him where he dug it up, but it had stuff like pure sulfuric acid in it.

One day, when I was done with all of the experiments I had planned to do, I decided to mix a few things and heat them up, just for fun, without any real motivation other than "let's see what happens".

Let's just say I was lucky we only had to replace some of the clothes my mom had left out for me to put away. ;)

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?

Then you do it using the "unsafe" keyword, and you think long and hard about how to design and structure the code so that the unsafe code is small in scope, surface, and blast radius.

That's precisely what unsafe code is for: to get around the borrow checker and assert you know what you're doing. Of course, if you're wrong, that means your program will blow up, but at least you know that the culprit is hiding in one of those unsafe areas, rather than literally anywhere in the whole codebase.

Alternately, you can switch to a language with a different ethos.

The ethos of Rust is caring for memory safety so much that you willingly limit yourself in terms of what kind of code you write and you only step out of those limits reluctantly and with great care. That's something that resonates with a lot of people and Rust has been built on top of that for years.

If you suddenly take the product of those years of hard work, strip out the foundation it has been built on, and unironically offer it as a good idea, a lot of people won't like it and will tell you so. Mind, I'm not excusing the personal attacks, I'm just explaining the reaction.

corrode27116• 7 months ago

Anything fun is dangerous. Or anything dangerous is fun. Something like that.

npalli• 7 months ago

You just need to master one package managed in depth and you will get what you really want with Modern C++.

oblio• 7 months ago

You, sir, might one day belong to the Computing Hall of Fame, together with the creators of Brainf*k, Visual Basic, PHP, Javascript, ColdFusion, etc. :-p

zaptheimpaler• 7 months ago

This is incredible! I honestly think Rust is an awesome language because it has a lot of high-level niceties like HOF, powerful libraries but can simultaneously let you manage memory manually or put assembly next to your regular code - the borrow checker is an annoyance in a lot of cases like prototyping as you said. I would loove if this was an official mode that Rust supported, Rust could really work in any niche with that capability.

bkovitz• 7 months ago

Thanks for explaining why you made Rust--! I figured it was just whimsical play, and I find it delightful. I'm especially delighted to hear that it wasn't even hard to disable the borrow checker.

I hope you will answer the question here from @dataflow about whether, without the borrow checker, compiler optimizations will emit incorrect code. Did you have to make further modifications to disable those optimizations?

ethin• 7 months ago

I ran into the borrowc so many times when doing OS dev. Which is why I hold the position that Rust is (not) a suitable language for OS development/kernels/embedded systems. In such scenarios, multithreading/multiprocessing is something you explicitly have to do, since although most systems that aren't x86 may start all processors simultaneously, your bootstrap code (should!) explicitly park all other cores before continuing. But the problem I always ran into was that Rust wanted me to do something weird for a system that was (not) multi-threaded. As in, I didn't even support threads of any kind. Or coroutines. But I still had to wrap statics in Lazy<T> or Rc<T> or something because "uwuw this is unsafe oh the world is going to end!" And all I wanted was to tell the borrow checker to shut up for once because yes, I actually did know what I was doing, thank you very much.

I get the idiom of "trust the compiler, it knows your code better than you". But there are also instances where the compiler just needs to trust the programmer because the programmer is, in fact, smarter than the compiler in those instances.

indigoabstract2• 7 months ago

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".

whatshisface2• 7 months ago

If you could disable the borrow checker globally, projects would do it, and it would become impossible to compile anything with it enabled.

You can already disable it locally: the unsafe keyword is for that.

gpm7• 7 months ago

The unsafe keyword doesn't disable the borrow checker... it lets you interact with different pointer types that aren't borrow checked, but if you're using the normal reference types in rust the same guardrails are still in place.

klysm• 7 months ago

Doesn’t work - you need the borrow checker guarantees to implement downstream compilation steps. You can just turn off assumptions

gpm7• 7 months ago

you need the borrow checker guarantees to implement downstream compilation steps.

You don't technically. The borrow checker doesn't effect the semantics of the program (like, for example, type inference does) and the rest of the compiler doesn't need to (and in fact, doesn't) use its analysis to figure out how to compile the code.

The downstream compiler does assume that the code followed the rules for accessing references - i.e. didn't violating aliasing rules. The borrow checker guarantees this, but it's fundamentally a conservative check. It rejects programs it can't guarantee are correct, and rice's theorem proves that there are always correct programs that it can't guarantee are correct.

That said if you just treat rust-references like C-pointers you will run into issues. The aliasing rules for rust references are stricter. Also not fully agreed upon yet - the currently closest to accepted definition is in the "tree borrows" paper but it has yet to be adopted as the official one by the rust team.

pornel2• 7 months ago

That's not the spirit Rust wants to have. You can already disable borrow checker selectively by using "raw" pointers in places where you think you know better, and this is used very commonly. Every String in Rust has such raw pointer inside.

It doesn't make much sense to globally relax restrictions of Rust's references to be like C/C++ pointers, because the reference types imply a set of guarantees: must be non-null (affects struct layout), always initialized, and have strict shared/immutable vs exclusive access distinction. If you relax these guarantees, you'll break existing code that relies on having them, and make the `--yolo` flag code incompatible with the rest. OTOH if you don't remove them, then you still have almost all of borrow checker's restrictions with none of the help of upholding them. It'd be like a flag that disables the sign bit of signed integers. It just makes an existing type mean something else.

MangoToupe5• 7 months ago

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.

indigoabstract2• 7 months ago

I think it's more in the spirit of playfulness, like in "don't take yourself too seriously". It's why people want to mod Minecraft and Doom for example.

Because it's fun.

I can totally understand why you wouldn't want to do this though - the plethora of incompatible lisp dialects come to mind. That's why I said it was controversial.

Wowfunhappy• 7 months ago

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.

shmerl• 7 months ago

Isn't unsafe just for that? Why does it need a separate compiler?

idontsee• 7 months ago

The borrow checker still applies in unsafe { } blocks. What it means (iirc) is that you can do pointer/memory stuff that would otherwise not be allowed. But you still fully adhere to Rust semantics

andrewaylett2• 7 months ago

Unsafe isn't so unsafe that it disables the borrow checker!

The two main things the compiler allows in an unsafe block but not elsewhere are calling other code marked "unsafe" and dereferencing raw pointers. The net result is that safe code running in a system that's not exhibiting undefined behaviour is defined to continue to not exhibit undefined behaviour, but the compiler is unable in general to prove that an unsafe block won't trigger undefined behaviour.

You can side-step the borrow checker by using pointers instead of references, but using that power to construct an invalid reference is undefined behaviour.

JoelJacobson• 7 months ago

Rust without async maybe?

juped• 7 months ago

This would actually be good though!

accelbred3• 7 months ago

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.

giancarlostoro• 7 months ago

I've been wishing for Rust to become more ergonomic, what ergonomics does Rust currently have that other languages lack?

Null-Set• 7 months ago

I love how everything is an expression with a value. And match expressions are quite nice, especially with the option type. I really miss those when working in javascript.

zeroxfe• 7 months ago

If Go had rust-style ADTs and pattern matching, and some parallel of "?" to short-circuit error handling, I'd be thrilled.

accelbred3• 7 months ago

For me its everything being an expression, macro_rules, dyn, automatic conversions (the few that it does have), traits, and the ? operator.

masklinn7• 7 months ago

Affine types / destructive moves, type-level safety signal (sync/send), container-type locks.

I really miss these when doing concurrent stuff in other languages.

maxbond2• 7 months ago

To add to the sibling comments, a world-class LSP enabling you to get a great experience in any editor/IDE out of the box. This is not at all exclusive to Rust of course, most strongly typed languages have one at this point, but I've been working in Python lately and this is what I miss the most. (I'm using an LSP in Python, but it isn't as good at the best of times, and it seems like no matter how many times I fix it's configuration it's broken again the next day.)

adastra226• 7 months ago

…then just use Rust? I’m confused. Most of this stuff never comes up if you aren’t doing things where memory safety would be an issue.

accelbred3• 7 months ago

The code I have in C is often code that does't fit in Rusts safety model. Dealing with ffi is annoying because slices have no defined layout. `dyn` is limited compared to what I can do with a manual vtable. I have seriously attempted porting my personal stuff to Rust, but theres enough papercuts that I go back to C. I want the parts of Rust I find to be helpful without those parts I don't.

QuaternionsBhop• 7 months ago

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.

tinco• 7 months ago

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.

sakisv2• 7 months ago

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.

Maxatar5• 7 months ago

Lifetimes are the input to the borrow checker, so it doesn't make much sense to say you have never been bothered by the borrow checker but you are bothered by lifetimes.

ViewTrick10023• 7 months ago

Due to lifetime elision you can mostly skip lifetimes if you leave a bit of performance on the table.

sakisv2• 7 months ago

Ah, that's a fair point. In that case then yes, I have been bothered by the borrow checker very much indeed lol.

culebron21• 7 months ago

Somehow at some point lifetimes started clicking for me. I think the key was when I understood that in a function, not everything needs the same lifetime. e.g.

    struct MyRef<'a> { item: &'a i64 }
    struct MyType { items: Vec<i64> }
    impl MyType {
        fn get_some_ref(&self, key: &usize) -> MyRef<'a> {
            MyRef { item: &self.items[key] }
        }
    }

the function this way is incorrect. When I was a beginner, I would have thought that every & in the signature needed a lifetime. In a slightly complicated code, the borrow checker then demanded lifetimes everywhere, they'd infect everything, but the code would still never compile.

Then I understood that not everything needs to be tied to the same lifetime. In this example, MyRef should be tied to the MyStruct, but not to the `key`:

        fn get_some_ref<'a>(&'a self, key: &usize) -> MyRef<'a>

zemo• 7 months ago

way too many people in this thread are taking this project seriously

lamontcg• 7 months ago

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.

dmitrygr• 7 months ago

Generally better to make a copy of something
Eliminate loads of spooky-action-a-distance bugs

This line of thinking so sickens me. Many things are not easy when done right. That is no excuse to avoid understanding how to do them right. Sure, making endless copies is easier. But this is why machines now need 16GB of ram and four cores to run the calculator.

LexiMax• 7 months ago

But this is why machines now need 16GB of ram and four cores to run the calculator.

This has more to do with the fact that the web stack has become the de-facto app development platform, and thus we inherit the bloat and optimization oversights of that platform.

You're not going to make a 16GB calculator just because you personally prefer copies over shared ownership in a language that gives you the tools to avoid bloat in a myriad of ways.

mistivia• 7 months ago

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.

Rust--: Rust without the borrow checker

Related Stories