4 ms·
The value proposition of Rust is precisely having zero-cost abstractions and highest-performance code with compile-time verification of correctness. That being
by 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 agoI 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 agoAs 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 agoI 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 agoIt doesn't have the same connotations as `unsafe`.
- likeabbas 4y agoBut it’s the true definition being stated. Unsafe is subjective, compiler unverifiable isn’t
- ZephyrBlu 4y agoSo? 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.
- likeabbas 4y agoI 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.
- proto_lambda 4y agoUsers who don't even know the meaning of "unsafe" almost definitely shouldn't be writing unsafe code.
- likeabbas 4y agoThat's an elitist mindset
- anonymoushn 4y agoIn 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.
- jsheard 4y agoIt'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 https://rust.godbolt.org/z/7rjKE93Kn It currently only works with constant shuffle masks but dynamic shuffles are on the to-do list.
- anonymoushn 4y agoThis 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 :(
- 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 agoOk 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 agoWe 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 agoAnd 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 agoRust 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.