Hacker News Reader

Comment by cormacrelf | Hacker News Reader

> This one is probably closest to what one would write in languages like C++. The data structure just assumes the allocator will outlive it, and it is up to the user to either use an static allocator, or pretend to using unsafe code to cast away the lifetime while making sure that the allocator outlives the data structure without the compiler's support.

I know many in the Rust community will frown upon this approach, but to be honest I don't think that it is a terrible solution in the context of an advanced feature like custom allocation strategies. Tessellator does not expose an unsafe API, but it documents that if its users were to break the rules they'd simply have to make sure the allocator outlives the data structure. In any other language with this kind of control over memory management, this contract would have to be manually upheld by users of the API and it is considered normal.

… no thanks.

View on HN

The value proposition of Rust is precisely having zero-cost abstractions and highest-performance code with compile-time verification of correctness.

That being said, I don't oppose the occasional judicious use of unsafe. If 99% of your code is verified, it's not 100%, but that's still a massive improvement over a C++ codebase.

I think `unsafe` would have been more aptly named `compiler_unverifiable`. IMO there would be less apprehension to using `unsafe` when it's needed.

As someone who mainly uses higher level languages, doesn't care for C/C++ and really likes Rust, I'm glad it was named so strongly and that safety and correctness is very important in the community.

It creates a strong incentive to only write safe Rust, which is great for the vast majority of people.

I think the incentive to write compiler verifiable Rust would be the same as safe Rust, but with less fear for the situations where you do need to bypass the borrow checker such as with cyclical references in graphs (currently doing this right now by re-writing a basic NN in Rust). Even the standard library uses unsafe for certain situations.

> with less fear for the situations where you do need to bypass the borrow checker such as with cyclical references in graphs

That's a pretty tricky thing to get right, and with the consequence for getting it wrong being UB, at least a little fear is warranted.

`compiler_unverifiable` isn't risky enough for you?

It doesn't have the same connotations as `unsafe`.

But it’s the true definition being stated. Unsafe is subjective, compiler unverifiable isn’t

So?

This is like applications adding artificial delay to operations so users aren't surprised they complete so quickly.

User understanding is more important than definitional correctness.

I don’t understand why you want people to be afraid of code though. It’s just code. We don’t need a scary connotation to make people think they should shoot for completely compiler verifiable rust in every line they can write.

Users who don't even know the meaning of "unsafe" almost definitely shouldn't be writing unsafe code.

That's an elitist mindset

It's a user-friendly mindset.

User-friendly is subjective. I think it would be more user friendly to tell users "hey, this code you're writing can't be verified by the compiler" rather than "hey, this code is unsafe. beware"

What it boils down to is "Users who don't even know what a trigger is should be discouraged from handling footguns". Sure, if you don't have the resources to learn about the subject, you might miss out on some fun, but it's much more likely that you'd blow off your foot instead, which would be much less fun.

In this case it would be nice if operations that are type-safe and don't read or write memory at all, such as mm256_shuffle_epi8, were available in safe rust.

It's a work in progress, on nightly there is a safe and portable SIMD abstraction under development in std::simd.

e.g. "mm256_shuffle_epi8" on X64+AVX2, ARM64+NEON and plain ARM: https://rust.godbolt.org/z/7rjKE93Kn

It currently only works with constant shuffle masks but dynamic shuffles are on the to-do list.

This is helpful for the use cases that want to rearrange bytes in a fixed pattern, but it cannot yet express a stream vbyte decoder (out = pshufb(in, shuffle_patterns[len_mask])) or a check for which bytes are in small set of bytes with distinct lower nibbles and the high bit not set (eq(in, pshufb(set, in))) yet.

If it's to be portable it needs an extra instruction on one platform or the other because tbl and vpshufb do different things :(

`unchecked` might be more palatable, but I agree that there is some uncomfortable mismatch between the meanings of "unsafe" and `unsafe`.

Ok Rust is about a lot of things, but correctness is not one of those things. Dafny is an example of a programming language that’s about correctness.

We can talk in specifics: this example was about making people use unsafe to avoid having to type <'static> in the general case. The author had been trying for a number of paragraphs to avoid polluting the type name with generics or lifetimes. This is what going too far looks like.

The std APIs look like this:

   struct Box<T, A: Allocator = Global>

And it’s been this way in stable releases for the last year or so. The same has been done for Vec and all the other std::collections. What percent of Rust programmers do you think even noticed at all? 1%? The most flexible design and the least impacting on regular users. You can use A = &'a dyn Allocator if you like, equally you can choose a ZST and not pay for 16 bytes of storage. The library author has no need to choose in advance at all, which is great if they’re determined to make weirdly constrained choices, ultimately forcing most uses of the API to be unsafe. I stopped reading after that so I don’t know which design they went for.

And if the generated documentation is really the main sticking point, it would be perfectly possible to special case the allocator type parameter in rustdoc so that it hides or otherwise deemphasizes it.

> The most flexible design

Not quite. For the most general case, you probably want allocator to be a proper parameter instead of a type parameter. For example, suppose you have a green thread that you want to have its own isolated heap. Then you can't assume that any given allocator is a singleton in its type; The struct itself must somehow be able to find to its "owner" on release. In the green thread case you can't "just use threadlocal" because a green thread might not be sticky to an os thread.

Rust already has almost exactly this problem with keeping track of the current task in the async framework. As far as I know, the solution is indeed to use a thread local, and be scrupulous about updating it on task entry. It's ugly but it seems to work.

They thought of that. There are Box::new_in variants for all the other ways of creating a Box. You can put data in there to identify a green thread’s heap. https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#m...

Well, I hope we get custom allocation soon in Rust. Its really strange not having the same in an advertised system programming language.

Can help in incidents like the below:

https://www.svix.com/blog/heap-fragmentation-in-rust-applica...

You might want custom local allocators. You can already replace the global allocator with one designed to reduce fragmentation, as described in the article.

You can already do custom allocation in Rust. These efforts are about bringing support for custom allocators to the types in `std` so that you can combine use of a normal `Vec` with a custom allocator, instead of needing to definte your own `Vec` (or at least pull one in from a 3rd party crate).

Reply on news.ycombinator.com