withoutboats's comments

This touches on some interesting history: lifetimes were originally (in other PL literature) called "regions" (MS Research's Verona also uses this terminology). Lifetime was chosen because an analogy to time seemed more intuitive for this concept than an analogy to space - space analogies being usually used for sections of program memory, rather than periods of program execution.

This is sort of the problem: its very natural to refer to that as a lifetime! In fact, more natural than the lifetime of a reference, because we intuitively think of variables as being "alive" and references as being short-term "views" of the variables.

As in the sibling comment, "scope" could be used, but indeed maybe we should have just called lifetimes "scopes" or something (though they are not lexical, whereas scopes are usually thought of as lexical pyramids).

I probably would just say lifetime usually, but I would be being imprecise and potentially unclear!

Your post suggests a bit of confusion about the meaning of "lifetime" in Rust - a confusion which is common and why we are somewhat unhappy with how that terminology has played out.

Variables don't have a "lifetime," references do. When we talk about lifetimes we talk about the lifetime of references to variables, during which time the variable cannot be moved, dropped, etc. The "lifetime of the variable must be greater than the lifetime of the reference" is a common mental model but this lifetime of the variable doesn't really come into play in reality.

Your 1) and 2) always coincide in the abstract model, though the compiler may optimize out memcpys that have no impact. When you move a pointer around, you don't move the object it points to.

I don't want to be defensive but this is completely off base, and very disheartening to see you post. Allowing users to write safe self-referential code was never a design goal of Pin - only to make it safe to manipulate self-referential objects generated by the compiler, which it has succeeded at. The incredibly overblown soundness hole had far more to do with the quirks of #[fundamental] than Pin (and the soundness hole is being resolved without changing the Pin APIs at all or breaking any user code).

The guarantees of Pin are now even being used beyond self-referential types but also for intrusive data structures in tokio's concurrency primitives. Pin is not for everyday users, but it is one of the greatest success stories of Rust's unsafe system. That you would call it a mess to a forum of non-users is quite disspiriting.

This situation is the sad and absurd result of two processes going on in the Rust community.

The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of grief for the maintainer of actix and prevented real (but far overblown) code issues from being fixed in a productive way.

But I think Steve undersells the absurdity of the unsafe anxiety. Some Rust commmunity members are conflating two wildly different scenarios together. The first is a library exposing an API which, if used in an unlikely and contrived way, could result in a program using that library containing undefined behavior. Then, since that program has undefined behavior, it could contain a memory bug. If that were the case, someone could potentially exploit that bug to attack a user of that program. You'll notice this is a series of conditional statements - its a funnel of decreasing probability.

So yes, library APIs which can allow UB in safe code - even unlikely and contrived safe code - must be fixed. The goal of Rust is that safe APIs can never cause UB. But people should have a proportionate understanding of the risk profile of these bugs (again: a programmer using this API in an unlikely way could create a program with a bug that could potentially be exploitable). This is a miniscule increase in the risk of another heartbleed, it is not the same thing as heartbleed.

The spark that lit the kindling of the toxic Reddit community was a blog post by Shnatsel, a member of the RustSec team. This blog post didn't get attention here, but I want to take a moment to look at how ridiculously it frames things by examining its analysis of a different project: reqwest (sort of the most standard HTTP client library in Rust).

Here's the link: https://medium.com/@shnatsel/smoke-testing-rust-http-clients...

The fuzz test, which is what the library is about, found no security issues. It found some hangs in 6% of cases and Shnatsel traces them to a known deadlock issue. This is a great result.

But Shnatsel spends most of this talking about a custom hashmap implemented in the http library, which the RustSec group did a security audit of just a few months ago. That security audit found only two issues, both UB that would result from a contrived use of a minor library API (they are linked in the blog post, but not explained). These two issues were fixed, and the fix released, by the maintainers of the http crate in 10 days.

This is an incredible success! The security audit of a foundational library found two minor issues which were promptly fixed, and the fuzz confirms that the entire stack on top of it seems to contain no memory issues. Wonderful result, but how does Shnatsel frame this?

> First things first: it didn’t segfault! I am actually impressed because I had really low expectations going into this.

Come on! The blog post is full of these kinds of snide zingers which are totally unfounded in the face of the actual evidence presented. When you have someone writing in this disingenuous, meanspirited way about open source maintainers and then putting this in front of a groupthinking rage machine community like Reddit, of course you're going to get harassment. This behavior is totally unacceptable, and it's very sad to see it promoted in the Rust community.

There's miles between understanding pinning well enough to call `Box::pin` (a safe API) and understanding pinning well enough to call `Pin::get_mut_unchecked` (an unsafe API). When we talk about understanding pinning, we mean the latter.

There is a huge gradient of use cases between "high level web frameworks" and "writing everything from scratch" and we've thought about the impact on users at every step of that gradient. But I'm not about to explain it to you, because you are being disingenuous and aggressive.

The syntax is different but Rust has this feature- its called auto traits, and its how we handle traits related to threadsafety. Its not a solution for what Pin solves because the whole notion that a type might be moveable or not moveable is actually a misstatement of the problem that Pin is solving.

The name for that reference type is a shared reference. It's literally the default reference type. It's not a sufficient guarantee for the use cases Pin supports.

This is exactly the kind of comment that makes me dislike Hacker News so strongly, because I find it endemic here.

The idea that someone could think an issue is theoretical and then discover it is practically significant is obvious and no insight at all - it reduces to "people are sometimes wrong." I am declaring based on my significant relevant expertise that this issue is not practically important. Your comment contributes nothing but baseless contradiction.

(and the idea I was expressing was "shared references never under any circumstance implement the DerefMut trait")

No one has ever proposed a solution - first class or not - which wouldn't be significantly more invasive and infectious. Does it sound fun in code that doesn't have anything to do with futures to spend time worrying if this generic should be `T: ?Move` or not?

This was certainly not our intention, or what I've heard from users.

(I was the primary designer of the Pin API.)

Since (to a first approximation) every individual who has the expertise and contextual knowledge to really evaluate this issue is a poster on internals.rust-lang.org, its pretty surprising to find this thread on the front page of Hacker News. I imagine some Hacker News users who upvoted this link did so out of technical interest, but I suspect a large portion of the attention comes from some combination of these misconceptions:

- The misconception that this could have a practical impact on users (the code being discussed on the thread is all obviously pathological & contrived).

- The misconception that Rust's type system and standard library never contain soundness issues and that this is an exceptional event (in fact we have a number of longstanding soundness issues).

We have a policy of fixing all soundness issues, so this issue will be fixed. In the meantime, while we decide the best solution, it will have no practical impact on Rust users. And none of the solutions we are considering would involve significant breakage to users, or invalidate any real code.

At a high level: the soundness issue occurs because the Pin API was designed based on certain reasoning about the behavior of pointers. This reasoning would be sound but for the fact that we have allowed certain exceptions in relationship to pointers to what are called the "orphan rules" (which usually enable local reasoning like this). These exceptions allow users to introduce code which, while contrived, allows them to violate the guarantees of the Pin API. Such is life.

Thankyou.

Mods: This user's posting history makes clear they are an anti-Semitic conspiracy theorist. Why have you not banned them?

https://news.ycombinator.com/item?id=20972062

https://news.ycombinator.com/item?id=20918028

I won't be doing that.

You seem like a really unpleasant person and it doesn't really seem worth my time to interact with you, but I want to point out that your post actually contains no relevant information: "to post as I have done" is a tautological reference to my violation, as "to post as I have done" describes the entire sum of my post and behavior. This provides no insight, and seems mainly an opportunity for you to be smug.

My suspicion is that people object to calling this persons' claims essentially a lie, which is just the truth. It is dishonest to use the performance numbers of an incomplete project while listing the features of the complete project, which will certainly decrease performance. The website is replete with obviously absurd claims, like a completely baseless claim about throughput that assumes compile time is linear in code size.

But what's actually pathetic in this affair is the anguish and upset of a bunch of internet nerds over a project that has received, in its 3 months of existence, less than $2500 USD. This is peanuts, but everyone is outraged over a "scam" because the real scam is open source getting a bunch of people to work for free, hoping at a chance of getting peanuts like this.

It's pretty obvious that this person has essentially lied: they have not implemented the complex features they claim while they hype benefits like compile time and lack of non-zero cost features that will have to disappear when they have implemented what they promised. But I think what's more interesting, more telling, is the level of vitriol over 12k/year in patreon subscriptions. Funding in open source is so absurdly unequal that people are outraged over someone earning table scraps.

EDIT: No idea why this was flagged, I don't understand the norms of this strange website.

The user is the programmer in this context, the user of the programming language, not the end user of the program.