Rust--: Rust without the borrow checker • Hacker News Board

Re: Rust--: Rust without the borrow checker

#191

Post by oblio » Thu, Jan 01, 2026, 9:15 PM UTC

corrode2711 wrote: post #110

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…

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

Re: Rust--: Rust without the borrow checker

#192

Post by ViewTrick1002 » Thu, Jan 01, 2026, 9:26 PM UTC

Maxatar wrote: post #182

sakisv wrote: post #164

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.

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.

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

Re: Rust--: Rust without the borrow checker

#193

Post by masklinn » Thu, Jan 01, 2026, 9:29 PM UTC

giancarlostoro wrote: post #152

accelbred wrote: post #147

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.

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

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

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

Re: Rust--: Rust without the borrow checker

#194

Post by [deleted] » Thu, Jan 01, 2026, 9:31 PM UTC

[deleted]

Re: Rust--: Rust without the borrow checker

#195

Post by lamontcg » Thu, Jan 01, 2026, 9:32 PM UTC

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.

Re: Rust--: Rust without the borrow checker

#196

Post by [deleted] » Thu, Jan 01, 2026, 10:16 PM UTC

indigoabstract wrote: post #114

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

[deleted]

Re: Rust--: Rust without the borrow checker

#197

Post by Spivak » Thu, Jan 01, 2026, 10:21 PM UTC

Maxatar wrote: post #160

Spivak wrote: post #148

Earlier 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…

I knew I should have also put the (in terms of memory safety) on the C++ paragraph but I held off because I thought it would be obvious both talking about the borrow checker and in contrast to Rust with the borrow checker.

Yes, when it comes to types C++ will reject theoretically sound programs that don't type correctly. And different type system "strengths" tune themselves to how many correct programs they're willing to reject in order to accept fewer incorrect ones.

I don't mean to make it a dichotomy at all, every "checker", linter, static analysis tool—they all seek to invalidate some correct programs which hopefully isn't too much of a burden to the programmer but in trade invalidate a much much larger set of incorrect programs. So full agreement that there's a lot of nuance as well as a lot of opinions when it goes too far or not far enough.

Re: Rust--: Rust without the borrow checker

#198

Post by pron » Thu, Jan 01, 2026, 10:23 PM UTC

nemetroid wrote: post #145

lordgroff wrote: post #126

Earlier quoted context omitted.

And for which there's often no serious alternative to in many domains anyway.

Yes, many or even most domains where C++ sees a large market share are domains with no other serious alternative. But this is an indictment of C++ and not praise. What it tells us is that when there are other viable options, C++ is rarely chosen. The number of such domains has gone down over time, and will probably continue to do so.

The number of domains where low-level languages are required, and that includes C, C++, Rust, and Zig, has gone down over time and continues to do so. All of these languages are rarely chosen when there are viable alternatives (and I say "rarely" taking into account total number of lines of code, not necessarily number of projects). Nevertheless, there are still some very important domains where such languages are needed, and Rust's adoption rate is low enough to suggest serious problems with it, too. When language X offers significant advantages over language Y, its adoption compared to Y is usually quite fast (which is why most languages get close to their peak adoption relatively quickly, i.e. within about a decade).

If we ignore external factors like experience and ecosystem size, Rust is a better language than C++, but not better enough to justify faster adoption, which is exactly what we're seeing. It's certainly gained some sort of foothold, but as it's already quite old, it's doubtful it will ever be as popular as C++ is now, let alone in its heydey. To get there, Rust's market share will need to grow by about a factor of 10 compared to what it is now, and while that's possible, if it does that it will have been the first language to ever do so at such an advanced age.

Re: Rust--: Rust without the borrow checker

#199

Post by gpm » Thu, Jan 01, 2026, 10:41 PM UTC

1718627440 wrote: post #187

amluto wrote: post #78

Earlier quoted context omitted.

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

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

I'm not 100% sure the semantics here are nailed down - but I think there's no guarantee that `a` continues to exist after assignment to `b`. The value in it has been moved out of it after all... The memory which was used for the variable `a` can probably be re-used for something else, e.g. for some inlined variable used by `println!`...

In normal rust `let a = b` where the variable is of a non-Copy type (including String) is "destructive" in the sense that you can no longer use b.

The question about semantics in normal rust turns to "so if I have a raw-pointer to a hanging around and use unsafe code to copy the value out of it what do I get" and I'm not 100% sure... but I think the answer is probably it's a use after free and you get undefined behavior. The rust-- version is basically just this except you don't have to explicitly make that raw pointer to read the old memory.

Re: Rust--: Rust without the borrow checker

#200

Post by 3836293648 » Thu, Jan 01, 2026, 10:43 PM UTC

LtWorf wrote: post #125

ozgrakkurt wrote: post #45

Earlier quoted context omitted.

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

People who can't do something, sometimes assume nobody else possibly could.

People hate C because it's hard, people hate C++ because it truly is rubbish. Rubbish that deserved to be tried but that we've now learned was a mistake and should move on from.