Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust--: Rust without the borrow checker

github.com

Post reply on HN
Print view View original

211–220 of 269 posts

Re: Rust--: Rust without the borrow checker

#211

Post by tialaramex »

pron wrote: post #198
nemetroid wrote: post #145

Earlier quoted context omitted.

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

> When language X offers significant advantages over language Y

So e.g. the silver bullet characteristics reported by Google among others in "More fast and fix things" ?

https://security.googleblog.com/2025/11/rust-in-android-move...

There's always resistance to change. It's a constant, and as our industry itself ages it gets a bit worse. If you use libc++ did you know your sort didn't have O(n log n) worst case performance until part way through the Biden administration? A suitable sorting algorithm was invented back in 1997, those big-O bounds were finally mandated for C++ in 2011, but it still took until a few years ago to actually implement it for Clang.

Re: Rust--: Rust without the borrow checker

#212

Post by ninkendo »

qsera wrote: post #158
gpm wrote: post #137

Earlier quoted context omitted.

> "safety" does not show up in types It does in rust. An `unsafe fn()` is a different type than a (implicitly safe by the lack of keyword) `fn()`. The difference is that unsafe fn's can be encapsulated in safe wrappers, where as IO functions sort of fundamentally can't be encapsulated in non-IO wrappers. This makes the IO tagged type signatures viral throughout your program (and as a result annoying), while the safet…

>The difference is that unsafe fn's can be encapsulated in safe wrappers 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? > IO tagged type signatures viral throughout your program (and as a result annoying).. Well, that is what good type systems do. Carry informat…

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

Y'know people complain a lot about Rust zealots and how they come into discussions and irrationally talk about how Rust's safety is our lord and savior and can eliminate all bugs or whatever...

But your take (and every one like it) is one of the weakest I've heard as a retort.

At the end of the day "adding safety very carefully atop of unsafe stuff" is the entire point of abstractions in software. We're just flipping bits at the end of the day. Abstractions must do unsafe things in order to expose safe wrappers. In fact that's literally the whole point of abstractions in the first place: They allow you to solve one problem at a time, so you can ignore details when solving higher level problems.

"Hiding a raw pointer behind safe array-like semantics" is the whole point of a vector, for instance. You literally can't implement one without being able to do unsafe pointer dereferencing somewhere. What would satisfy your requirement for not doing unsafe stuff in the implementation? Even if you built a vector into the compiler, it's still ultimately emitting "unsafe" code in order to implement the safe boundary.

If you want user-defined types that expose things with safe interfaces, they have to be implemented somehow.

As for why this is qualitatively different from "why not just use c", it's because unsafety is something you have to opt into in rust, and isn't something you can just do by accident. I've been developing in rust every day at $dayjob for ~2 years now and I've never needed to type the unsafe keyword outside of a toy project I made that FFI'd to GTK APIs. I've never "accidentally" done something unsafe (using Rust's definition of it.)

It's an enormous difference to something like C, where simply copying a string is so rife with danger you have a dozen different strcpy-like functions each of which have their own footguns and have caused countless overflow bugs: https://man.archlinux.org/man/string_copying.7.en

Re: Rust--: Rust without the borrow checker

#213

Post by josephg »

qsera wrote: post #87
josephg wrote: post #79

Earlier quoted context omitted.

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

There is a third kind. Those who want to have a lot of fun by using their imagination to come up with interesting ways build something, but in rust, the borrow checker often won't have any of it. In rust you have to learn and internalize lot of the non-intutive borrow checker reasoning to remain sane. If you remember to spend a fraction of that effort to remember the "unsafe" things you could end up doing in C, then…

> But "Rust for everything!?"..Give me a fucking break!

Nobody is arguing for that though? [1]

I love rust and use it all the time, but personally I think its the wrong choice for application development and web development. And together they make up almost all software jobs. Garbage collectors (like in C#, Java, JS, Go, etc) are fast enough, and they're way easier to work with.

I find system software really interesting. And I think rust is a great systems language! I'd use it in a heartbeat for databases, operating systems and web browsers. Places where correctness, security and performance matter more than creativity and feature velocity. But most people don't work on software like that. I think most programmers shouldn't bother with rust.

---

[1] At least, nobody sensible. I went to NodeCamp about a decade ago when everyone was jazzed on javascript and node. Someone told me - with stars in their eyes - about how amazing everything would be if the whole operating system was written in javascript. I told him that was stupid idea, but he wasn't having any of it. Rust has some of the same people now. Just give it a few years and they'll move on to something else.

Re: Rust--: Rust without the borrow checker

#214

Post by LtWorf »

zzrrt wrote: post #146
LtWorf wrote: post #125

Earlier quoted context omitted.

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

I’m sure some people could tiptoe through minefields daily for years, until they fail. Nobody is perfect at real or metaphorical minefields, and hubris is probably the only reason to scoff at people suggesting alternatives.

Just FYI rust projects have CVEs as well.

Re: Rust--: Rust without the borrow checker

#215

Post by pron »

tialaramex wrote: post #211
pron wrote: post #198

Earlier quoted context omitted.

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

> When language X offers significant advantages over language Y So e.g. the silver bullet characteristics reported by Google among others in "More fast and fix things" ? https://security.googleblog.com/2025/11/rust-in-android-move... There's always resistance to change. It's a constant, and as our industry itself ages it gets a bit worse. If you use libc++ did you know your sort didn't have O(n log n) worst case perf…

Except, as you say, all those factors always exist, so we can compare things against each other. No language to date has grown its market share by a factor of ten at such an advanced age [1]. Despite all the hurdles, successful languages have succeeded faster. Of course, it's possible that Rust will somehow manage to grow a lot, yet significantly slower than all other languages, but there's no reason to expect that as the likely outcome. Yes, it certainly has significant adoption, but that adoption is significantly lower than all languages that ended up where C++ is or higher.

[1]: In a competitive field, with selection pressure, the speed at which technologies spread is related to their relative advantage, and while slow growth is possible, it's rare because competitive alternatives tend to come up.

Re: Rust--: Rust without the borrow checker

#216

Post by tialaramex »

danudey wrote: post #174
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.

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.

Nope. Anything which wouldn't pass the borrowck is actually nonsense. This fantasy that magically it will just lose thread safety or have race conditions is just that, a fantasy.

The optimiser knows that Rust's mutable references have no aliases, so it needn't safeguard mutation, but without borrow checking this optimisation is incorrect and arbitrary undefined behaviour results.

Re: Rust--: Rust without the borrow checker

#217

Post by tialaramex »

pron wrote: post #215
tialaramex wrote: post #211

Earlier quoted context omitted.

> When language X offers significant advantages over language Y So e.g. the silver bullet characteristics reported by Google among others in "More fast and fix things" ? https://security.googleblog.com/2025/11/rust-in-android-move... There's always resistance to change. It's a constant, and as our industry itself ages it gets a bit worse. If you use libc++ did you know your sort didn't have O(n log n) worst case perf…

Except, as you say, all those factors always exist, so we can compare things against each other. No language to date has grown its market share by a factor of ten at such an advanced age [1]. Despite all the hurdles, successful languages have succeeded faster. Of course, it's possible that Rust will somehow manage to grow a lot, yet significantly slower than all other languages, but there's no reason to expect that a…

This sounds like you're just repeating the same claim again. It reminds me a little bit of https://xkcd.com/1122/

We get it, if you squint hard at the numbers you can imagine you're seeing a pattern, and if you're wrong well, just squint harder and a new pattern emerges, it's fool proof.

Re: Rust--: Rust without the borrow checker

#218

Post by bluehex »

ViewTrick1002 wrote: post #192
Maxatar wrote: post #182

Earlier quoted context omitted.

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.

How does lifetime elision affect performance? I thought the compiler just inferred lifetimes that you would have had to manually annotate. Naively, it seems to me that the performance should be identical.

Re: Rust--: Rust without the borrow checker

#219

Post by steveklabnik »

bluehex wrote: post #218
ViewTrick1002 wrote: post #192

Earlier quoted context omitted.

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

How does lifetime elision affect performance? I thought the compiler just inferred lifetimes that you would have had to manually annotate. Naively, it seems to me that the performance should be identical.

Strictly speaking, elision just adds lifetimes based on common patterns, so yes, it wouldn't directly affect performance.

I believe your parent is implying that if you skip using a lifetime and do something else instead to make it easier, that may be less performant.

Re: Rust--: Rust without the borrow checker

#220

Post by djdjfljfgddfg »

dataflow wrote: post #25

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?

I guess this is like putting an unsafe { } around all your code...
Post reply on HN