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

241–250 of 269 posts

Re: Rust--: Rust without the borrow checker

#241

Post by adastra22 »

steveklabnik wrote: post #219
bluehex wrote: post #218

Earlier quoted context omitted.

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.

I think his point is the lifetime you’d put there is identical to the lifetime that is inferred/elided. So there is literally no difference.

Re: Rust--: Rust without the borrow checker

#242

Post by adastra22 »

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.

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

Re: Rust--: Rust without the borrow checker

#243

Post by ViewTrick1002 »

steveklabnik wrote: post #219
bluehex wrote: post #218

Earlier quoted context omitted.

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.

Exactly.

Cloning values, collecting iterators into Vecs and then continue the transformation rather than keeping it lazy all the way through. Skipping structs/enums with references.

Re: Rust--: Rust without the borrow checker

#244

Post by dataflow »

jojomodding wrote: post #239
dataflow wrote: post #238

Earlier quoted context omitted.

> Disagreeing with your plainly incorrect assertion is not "not following" what you're saying. I'm sorry, that particular comment wasn't disagreeing so much as missing my point entirely. It gave an example that would've still suffered from the same problem I was talking about if the optimizer relied on the same borrowing assumptions (hence my subsequent comment clarifying this) and it also diverted the discussion tow…

https://plf.inf.ethz.ch/research/pldi25-tree-borrows.html (Note that I am an author of that paper, and also that this is just a proposal of the rules and not yet adopted as normative.) What you seem to be forgetting in this discussion is that unsafe code exists. The example above does not pass the borrow checker, but with a small amount of unsafe code (casting a reference to a pointer and back to erase the lifetime c…

Thanks for the link. Like you said, that's not normative, so it doesn't really dictate anything about what the compiler would currently do if you violated borrow checking, right?

> What you seem to be forgetting in this discussion is that unsafe code exists. (...) unsafe code exists and so you can't just say all programs not passing the borrow checker are UB.

Unsafe code does not turn off the borrow-checker though? So I don't see how its existence implies the opposite of what I wrote.

Moreover, my entire concern here is about violating assumptions in earlier stages of the compiler that later stages don't already see violated (and thus might be unprepared for). Unsafe is already supported in the language, so it doesn't fall in that category to begin with.

Re: Rust--: Rust without the borrow checker

#245

Post by tialaramex »

pron wrote: post #221
tialaramex wrote: post #217

Earlier quoted context omitted.

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.

Observing a pattern with a causal explanation - in an environment with selective pressure things spread at a rate proportional to their relative competitive advantage (or relative "fitness") - is nothing at all like retroactively finding arbitrary and unexplained correlations. It's more along the lines of "no candidate has won the US presidential election with an approval of under 30% a month before the election". Of…

You're basically just re-stating my point. You mistakenly believe the pattern you've seen is predictive and so you've invented an explanation for why that pattern reflects some underlying truth, and that's what pundits do for these presidential patterns too. You can already watch Harry Enten on TV explaining that out-of-cycle races could somehow be predictive for 2026. Are they? Not really but eh, there's 24 hours per day to fill and people would like some of it not to be about Trump causing havoc for no good reason.

Notice that your pattern offers zero examples and yet has multiple entirely arbitrary requirements, much like one of those "No President has been re-elected with double digit unemployment" predictions. Why double digits? It is arbitrary, and likewise for your "about a decade" prediction, your explanation doesn't somehow justify ten years rather than five or twenty.

Re: Rust--: Rust without the borrow checker

#246

Post by qsera »

adastra22 wrote: post #240
qsera wrote: post #234

Earlier quoted context omitted.

I think it comes down to 1. In `c` one have to remember a few, fairly intutive things, and enforce them without fail. 2. In rust, one have to learn, remember ever increasing number of things and constantly deal with non-intutive borrow-checker shenanigans that can hit your project at any point of the development forcing you to re-architecture your project, despite doing everything to ensure "safety". But the borrow-c…

Do you have any examples of that?

What is the point. If I share something, someone is going to come along and say. That is not how you are "supposed" to do it in rust.

And that is exactly my point. You need to learn a zillion rust specific patterns for doing every little thing to work around the borrow-checker and would be kind of unable to come up with your own designs with trade-offs that you choose.

And that becomes very mechanical and hence boring. I get that it would be safe.

So yes, if I am doing brain surgery, I would use tools that prevent me from making quick arbitrary movements. But for everything else a glove would do.

Re: Rust--: Rust without the borrow checker

#247

Post by adastra22 »

qsera wrote: post #246
adastra22 wrote: post #240

Earlier quoted context omitted.

Do you have any examples of that?

What is the point. If I share something, someone is going to come along and say. That is not how you are "supposed" to do it in rust. And that is exactly my point. You need to learn a zillion rust specific patterns for doing every little thing to work around the borrow-checker and would be kind of unable to come up with your own designs with trade-offs that you choose. And that becomes very mechanical and hence borin…

To learn something is generally the point. Either me, or you. I’ve been developing in rust for half a decade now and genuinely do not know what you were talking about here. I haven’t experienced it.

So either there are pain points that I’m not familiar with (which I’m totally open to), or you might be mistaken about how rust works. Either way, one or both of us might learn something today.

Re: Rust--: Rust without the borrow checker

#248

Post by qsera »

adastra22 wrote: post #247
qsera wrote: post #246

Earlier quoted context omitted.

What is the point. If I share something, someone is going to come along and say. That is not how you are "supposed" to do it in rust. And that is exactly my point. You need to learn a zillion rust specific patterns for doing every little thing to work around the borrow-checker and would be kind of unable to come up with your own designs with trade-offs that you choose. And that becomes very mechanical and hence borin…

To learn something is generally the point. Either me, or you. I’ve been developing in rust for half a decade now and genuinely do not know what you were talking about here. I haven’t experienced it. So either there are pain points that I’m not familiar with (which I’m totally open to), or you might be mistaken about how rust works. Either way, one or both of us might learn something today.

All lessons are not equally valuable. Seemingly arbitrary reasoning for some borrow checker behavior is not interesting enough for me to learn.

In the past, I would come across something and would lookup and the reasoning for it often would be "What if another thread do blah blah balh", but my program is single threaded.

Re: Rust--: Rust without the borrow checker

#249

Post by pron »

tialaramex wrote: post #245
pron wrote: post #221

Earlier quoted context omitted.

Observing a pattern with a causal explanation - in an environment with selective pressure things spread at a rate proportional to their relative competitive advantage (or relative "fitness") - is nothing at all like retroactively finding arbitrary and unexplained correlations. It's more along the lines of "no candidate has won the US presidential election with an approval of under 30% a month before the election". Of…

You're basically just re-stating my point. You mistakenly believe the pattern you've seen is predictive and so you've invented an explanation for why that pattern reflects some underlying truth, and that's what pundits do for these presidential patterns too. You can already watch Harry Enten on TV explaining that out-of-cycle races could somehow be predictive for 2026. Are they? Not really but eh, there's 24 hours pe…

> You mistakenly believe the pattern you've seen is predictive

Why mistakenly? I think you're confusing the possibility of breaking a causal trend with the likelihood of doing that. Something is predictive even if it doesn't have a 100% success rate. It just needs to have a higher chance than other predictions. I'm not claiming Rust has a zero chance of achieving C++'s (diminished) popularity, just that it has a less than 50% chance. Not that it can't happen, just that it's not looking like the best bet given available information.

> Notice that your pattern offers zero examples

The "pattern" includes all examples. Name one programming language in the history of software that's grown its market share by a factor of ten after the age of 10-13. Rust is now older than Java was when JDK 6 came out and almost the same age Python was when Python 3 came out (and Python is the most notable example of a late bloomer that we have). Its design began when Java was younger than Rust is now. Look at how Fortran, C, C++, and Go were doing at that age. What you need to explain isn't why it's possible for Rust to achieve the same popularity as C++, but why it is more likely than not that its trend will be different from that of any other programming language in history.

> Why double digits? It is arbitrary, and likewise for your "about a decade" prediction

The precise number is arbitrary, but the rule is that the rate of adoption of any technology (or anything in a field with selective pressure) spreads at a rate proportional to its competitive advantage. You can ignore the numbers altogether, but the general rule about the rate of adoption of a technology or any ability that offers a competitive advantage in a competitive environment remains. The rate of Rust's adoption is lower than that of Fortran, Cobol, C, C++, VB, Java, Python, Ruby, C#, PHP, and Go and is more-or-less similar to that of Ada. You don't need numbers, just comparisons. Are the causal theory and historical precedent 100% accurate for any future technology? Probably not, as we're talking statistics, but at this point, it is the bet that this is the most likely outcome that a particular technology would buck the trend that needs justification.

I certainly accept that the possibility of Rust achieving the same popularity that C++ has today exists, but I'm looking for the justification that that is the most likely outcome. Yes, some places are adopting Rust, but the number of those saying nah (among C++ shops) is higher than that of all programming languages that have ever become very popular. The point isn't that bucking a trend with a causal explanation is impossible. Of course it's possible. The question is whether it is more or less likely than not breaking the causal trend.

Re: Rust--: Rust without the borrow checker

#250

Post by Const-me »

eru wrote: post #224
Const-me wrote: post #66

Earlier quoted context omitted.

> What if you don't know ahead of time how big that monitor is that you are displaying stuff on? Use a reasonable upper estimate? > ad-hoc re-implementation of virtual memory? If you rely on actual virtual memory instead of specially designed file format, saving large files will become prohibitively slow. On each save you have to stream the entire document from page file to actual memory, serialize the document, prod…

> If you rely on actual virtual memory instead of specially designed file format, saving large files will become prohibitively slow. On each save you have to stream the entire document from page file to actual memory, serialize the document, produce the entire file, then replace. And then when resuming editing after the save, you probably have to load the visible portion back from disk. How large is large? Loading an…

> How large is large?

About the same size as amount of physical memory. For Word 97, minimum system requirement was 8MB RAM. That’s not just for the word, also the entire OS.

> Loading and saving a few GiB from my SSD is pretty fast

Indeed, that’s one of the reasons why modern word processors stopped doing complicated tricks like the ones I described, and instead serialize complete documents.

> a special file format and use virtual memory

That’s not the brightest idea: inflates disk bandwidth by at least a factor of 2. A modern example of software which routinely handles datasets much larger than physical memory is database engines (large ones, not embedded). They avoid virtual memory as much as possible because IO amplification leads to unpredictable latency.

> Saddling some guy on an underpowered Chromebook

The guy will be fine. The program might allocate a large buffer on startup but will only use the small initial slice because chromebooks don’t come with particularly large screens. Linux kernel does not automatically commit allocated memory.

Post reply on HN