9 ms·

> 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

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

andrepd 4y ago
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.
- likeabbas 4y ago
  I think `unsafe` would have been more aptly named `compiler_unverifiable`. IMO there would be less apprehension to using `unsafe` when it's needed.
  - ZephyrBlu 4y ago
    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.
    - likeabbas 4y ago
      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.
      - proto_lambda 4y ago
        > 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.
        likeabbas 4y ago
        `compiler_unverifiable` isn't risky enough for you?
        ZephyrBlu 4y ago
        It doesn't have the same connotations as `unsafe`.
        likeabbas 4y ago
        But it’s the true definition being stated. Unsafe is subjective, compiler unverifiable isn’t
        ZephyrBlu 4y ago
        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.
  - Yoric 4y ago
    `unchecked` might be more palatable, but I agree that there is some uncomfortable mismatch between the meanings of "unsafe" and `unsafe`.
- junofan 4y ago
  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.
- cormacrelf 4y ago
  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.
  - mikepurvis 4y ago
    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.
  - throwawaymaths 4y ago
    > 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.
    - twic 4y ago
      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.
lenkite 4y ago
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-applications/ https://www.svix.com/blog/heap-fragmentation-in-rust-applica...
- tomjakubowski 4y ago
  You might want custom local allocators. You can already replace the global allocator with one designed to reduce fragmentation, as described in the article.
- Diggsey 4y ago
  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).

andrepd 4y ago

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.

likeabbas 4y ago
I think `unsafe` would have been more aptly named `compiler_unverifiable`. IMO there would be less apprehension to using `unsafe` when it's needed.
- ZephyrBlu 4y ago
  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.
  - likeabbas 4y ago
    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.
    - proto_lambda 4y ago
      > 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.
      - likeabbas 4y ago
        `compiler_unverifiable` isn't risky enough for you?
        ZephyrBlu 4y ago
        It doesn't have the same connotations as `unsafe`.
        likeabbas 4y ago
        But it’s the true definition being stated. Unsafe is subjective, compiler unverifiable isn’t
        ZephyrBlu 4y ago
        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.
- Yoric 4y ago
  `unchecked` might be more palatable, but I agree that there is some uncomfortable mismatch between the meanings of "unsafe" and `unsafe`.
junofan 4y ago
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.
cormacrelf 4y ago
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.
- mikepurvis 4y ago
  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.
- throwawaymaths 4y ago
  > 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.
  - twic 4y ago
    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.

lenkite 4y ago

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-applications/ https://www.svix.com/blog/heap-fragmentation-in-rust-applica...

tomjakubowski 4y ago
You might want custom local allocators. You can already replace the global allocator with one designed to reduce fragmentation, as described in the article.
Diggsey 4y ago
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).