Measter

> Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.

One thing I've noticed when people make these arguments is that they tend to ignore the fact that most (all?) of these other safeties they're talking about depend on being able to reason about the behaviour of the program. But when you violate memory safety a common outcome is undefined behaviour, which has unpredictable effects on program behaviour.

These other safeties have a hard dependency on memory safety. If you don't have memory safety, you cannot guarantee these other safeties because you can no longer reason about the behaviour of the program.

There are also limits to what the borrow checker is capable of verifying. There will always be programs which are valid under the rules the borrow checker is enforcing, but the borrow checker rejects.

It's kinda annoying when you run into those. I think I've also ran into a situation where the borrow checker itself wasn't the issue, but rather the way references were created in a pattern match causing the borrow checker to reject the program. That was also annoying.

That support could be Microsoft driven. Parts of Windows 11 are written in Rust, and having that platform in Tier 1 makes their lives easier.

There's no push to add Debian's officially supported platforms to Rust because Rust already supports those platforms.

Based on this, and many other similar threads, it's the anti-Rust zealots insulting Rust users.

Zig only does bounds checking by default in Debug and ReleaseSafe builds. If you build with ReleaseFast or ReleaseSmall it will happily do an out of bounds read: https://godbolt.org/z/733PxPEPY

There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically.

The GCCRS project can't even build libcore right now, let alone libstd. In addition, it is currently targeting Rust 1.50's feature set, with some additions that the Linux kernel needs. I don't see it being a useful general purpose compiler for years.

What's more likely is that rustc_codegen_gcc, which I believe can currently build libcore and libstd, will be stabilised first.

Not even close. Borrow checking takes less time than type checking.

Wouldn't this also mean that if a user was using one of those browser extensions that automatically click "yes" to close the pop, then the site would not have informed consent, and therefore would not be allowed to collect the data?

You have to get the bindings from somewhere, which means you either need to write them yourself, or use someone else's work.

A few years ago I did some testing with a quick Arduino-based setup I cobbled together and got some interesting results.

The first test was the simple one-light-one-button test. I found that I had reaction time somewhere in the 220-270ms range. Pretty much what you'd expect.

The second test was a sound reaction test: it makes a noise, and I press the button. I don't remember the exact times, but my reaction times for audio were comfortably under 200ms. I was surprised at how much faster I was responding to sound compared to sight.

The last test was two lights, and two buttons. When the left light came on I press the left button; right light, right button. My reaction times were awful and I was super inaccurate, frequently pressing the wrong button. Again, I don't remember the times (I think near 400ms), but I was shocked at how much just adding a simple decision slowed me down.

For me it doesn't think I'm reading the prompt correctly, and refuses to accept the input.

I'm also British, from Devon.

It's not the lifetime of T, but the lifetime of whatever is storing T.

You're right that Rust doesn't have constructors or assignment operators, but its abstract machine also views memory as simply being a bag of bytes, rather than inherently typed like C/C++'s model.

Ironically, Rust doesn't need any of that, you literally can just cast to a different pointer type between arbitrary types and start using it without it inherently being UB (you know, as long as your access patterns are more generally valid).

Here's my experience of recommendations right now: videos I've already seen, videos on topics I have no interest in, or a completely empty page.

You've misunderstood what Steve is saying, and what safe/unsafe means in Rust. In Rust, if I have a block of code that doesn't use any operations that require the unsafe keyword, then I am guaranteed (modulo compiler bugs) that this block of code is free of all undefined behaviour.

It does not guarantee that code in any function being called within that block is free of it, but it does guarantee this block of code is.

Profiles don't give you that.

It can be preferable to avoid unsafe when reasonable to do so. Programmers are merely human and will make a mistake at some point, and by avoiding unsafe you at least get the guarantee that the buggy behaviour is sound and (aside from race conditions) more predictable.

RefCell does do runtime checks, but the cost is checking the counter, a conditional branch, then incrementing/decrementing the counter twice.

Because the counter is non-atomic and non-volatile the optimiser can sometimes optimise out the actual modification of the counter. It's not free, but it's not also not a huge expense.

pub(crate) came later. I think it's something an edition could change, but I don't remember seeing people suggest it.

The same Andrew who rejected even basic interfaces in favour of duck-typed generics or manually written vtables?

In the section about the ambiguous provenance from synthesising pointers, it's explained that the compiler will infer the correct provenance from usage. Would it not be worth having some way for the programmer to inform the compiler directly, with something analogous to Rust's Strict Provenance ptr::with_addr?

To convert it to C syntax, it's a function with roughly this signature:

    void* with_addr(void* ptr, uintptr_t addr)

Where the returned pointer has the address of `addr` and the provenance of `ptr`.

Prove it. Show me the stats that the standard library is over 50% unsafe.

But many of those valid criticisms require some familiarity with the language. With syntax they can just point at it and claim it's bad without having to learn anything first.

Oh this is simple, this is just a bit of basic expansion to generate boilerplate. The real experts can do some gnarly and amazing stuff with macros.

For giggles, here's one I whipped up, along with an example use: https://godbolt.org/z/Eezj35dzc

My biggest issue with the whole "function colour" thing is that many functions have different colours. Like, these two:

    fn foo() -> String
    fn bar() -> Result<String, Error>

I can't just treat `bar` the same as `foo` because it doesn't give me a String, it might have failed to give me a String. So I need to give it special handling to get a String.

    async fn qux() -> String

This also doesn't give me a String. It gives me a thing that can give me a String (an `impl Future<Output=String>`, to be more specific), and I need to give it special handling to get a String.

All of these function have different colours, and I don't really see why it's suddenly a big issue for `qux` when it wasn't for `bar`.

I wouldn't agree with that. Jon's content is great, but it's really not aimed at beginners, and some of his stuff really gets into the weeds.

It can do. Additionally, because each part is now smaller it's now easier to ensure that each part, in isolation, does what it says on the tin. It also means that other projects can reuse the parts. An example of the last point would be the Regex crate.

Regex is split into subcrates, one of which is regex-syntax: the parser. But that crate is also a dependency of over 150 other crates, including lalrpop, proptest, treesitter, and polars. So other projects have benefited from Regex being split up.

What you're calling "tree shaking" is more commonly called "dead code elimination" in compilers, and is one of the basic optimisations that any production compiler would implement.