Live data from Hacker News

There is no memory safety without thread safety

ralfj.de

421–430 of 517 posts

Re: There is no memory safety without thread safety

#421
post #388

Earlier quoted context omitted.

It's not the runtime; it's how the borrow-checker interoperates with threads. This is an aesthetics argument more than anything else, but I don't think the type theory around threads and memory safety in Rust is as "cooked" as single-thread borrow checking. The type assertions necessary around threads just get verbose and weird. I expect with more time (and maybe a new paradigm after we've all had more time to use Ru…

You know that Rust supports scoped threads? For the borrow checker, they behave like same-thread closures. Borrow checking is orthogonal to threads. You may be referring to the difficulty satisfying the 'static liftime (i.e. temporary references are not allowed when spawning a thread that may live for an arbitrarily long time). If you just spawn an independent thread, there's no guarantee that your code will reach jo…

I'll have to look more closely at scoped threads. What I'm referring to is that compared to the relatively simple syntax of declaring scopes for arguments to functions and return values to functions, the syntax when threads get involved is (to take an example from the Rust Book, Chapter 21):

  pub fn spawn(f: F) -> JoinHandle
      where
          F: FnOnce() -> T,
          F: Send + 'static,
          T: Send + 'static,
... yikes. This is getting into "As easy to read as a C++ template" territory.

Re: There is no memory safety without thread safety

#422
post #305

Earlier quoted context omitted.

I believe your productivity drops as you say. I don't think it's inherent to the language though, at least not most of it. Rather it think it's a matter of familiarity and experience in each. When you're less practiced in a language, you're slower at it. I can write python fast, but im pretty slow at ruby. I've written a lot of python rust and go, and am about equally productive in them (although how that productivit…

Rust is objectively harder to write than Go (or any other GC-language) because it exposes more concerns for the programmer to take care of. With Rust, you must always ensure your program complies with the borrow checker's rules (which is what makes Rust memory-safe) which includes having to add lifetime annotations to your variables in many cases. Go just doesn't have any of that. You could argue Rust still has an ad…

>Rust is objectively harder to write than Go (or any other GC-language) because it exposes more concerns for the programmer to take care of.

comparing apples to apples: Once you get a tiny bit of experience, almost all of that goes away. The common patterns and idioms in the language allow you to write whole programs without ever thinking about lifetimes or memory allocation or anything else different from the gc language case.

comparing apples to oranges: you do need to worry about those things when writing tricky memory management code that you couldn't even get from most gc lanuages... yeah then you have to worry about the things since it's a case where those things are the point.

> You could argue Rust still has an advantage in that it prevents bugs that in Go you're free to write, but then what you're claiming is that this compensates for the extra work you have to do upfront in Rust.

I have evidence in the form of multiple services and programs running in prod under heavy use for years without having to revist the code to deal with bugs. Meanwhile the stuff written in go has to be touched a lot to deal with bugs. The extra couple of weeks upfront to do it in rust is mitigated after the first incident with the go code. The effort proves worthwhile after the second incident.

Also tangentially related: the cost of an incident in the form of lost business, refunds, etc is usually far higher than the cost of a couple developer weeks.

>because an experienced Go developer probably has internalized how to avoid those bugs and the cost of preventing them can be nearly negligible

Some of them yes. But this is literally the same argument I'm making about rust experience meaning that you don't spend all that much extra effort up-front. Like I said, I'm about equally productive in go, python or rust.

> I think that's why most people seem to agree Rust is probably only advantageous where the cost of data races in production is higher than the cognitive cost (which translates into increased effort) on the programmer.

I think people who say this haven't gotten much experience in rust. In my experience they spent a week trying to learn rust and decided to stop and compare it to their years of other languages and paradigms.

Re: There is no memory safety without thread safety

#423
post #368

Earlier quoted context omitted.

The problem isn't that you couldn't hardcode a scarier value; it's that you have to demonstrate a plausible scenario in realistic code where an attacker controls both the value and the address it's written to. While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at (checks notes) https://www.memorysafety.org/ .

> While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at And yet Go violates the definition they give -- it doesn't prevent out-of-bounds accesses. (And just to be sure we're talking about the same thing, I'm specifically talking about Go here. All the other languages on their list are actually memory safe, as far as I know.) > you have…

> So your definition of memory safety includes some notion of "plausible" and "realistic"? Neither https://www.memorysafety.org/docs/memory-safety/ nor Wikipedia have such a qualification in their definition. It would help if you could just spell out your definition in full, rather than having us guess.

This is a strawman argument, you're arguing semantics here. You're a smart person, so you know exactly what he means. The perception created by your article is that people shouldn't use Go because it's not memory-safe. But the average developer hearing "not memory-safe" thinks of C/C++ level issues, with RCEs everywhere.

Unless you can show a realistic way this could be exploited for RCE in actual programs, you're just making noise. Further down the thread, you admit yourself that you're in a PLT research bubble and it shows.

Re: There is no memory safety without thread safety

#424

False. Java got this right. Fil-C gets it right, too. So, there is memory safety without thread safety. And it’s really not that hard. Memory safety is a separate property unless your language chooses to gate it on thread safety. Go (and some other languages) have such a gate. Not all memory safe languages have such a gate.

It's not that black and white and the solution isn't necessarily pick language X and you'll be fine. It never is that simple. Basically, functional languages make it easier to write code that is safe. But they aren't necessarily the fastest or the easiest to deal with. Erlang and related languages are a good example. And they are popular for good reasons. Java got quite a few things right but it took a while for it t…

What does any of this have to do with memory safety?

Re: There is no memory safety without thread safety

#425
post #388

Earlier quoted context omitted.

You know that Rust supports scoped threads? For the borrow checker, they behave like same-thread closures. Borrow checking is orthogonal to threads. You may be referring to the difficulty satisfying the 'static liftime (i.e. temporary references are not allowed when spawning a thread that may live for an arbitrarily long time). If you just spawn an independent thread, there's no guarantee that your code will reach jo…

I'll have to look more closely at scoped threads. What I'm referring to is that compared to the relatively simple syntax of declaring scopes for arguments to functions and return values to functions, the syntax when threads get involved is (to take an example from the Rust Book, Chapter 21): pub fn spawn (f: F) -> JoinHandle where F: FnOnce() -> T, F: Send + 'static, T: Send + 'static, ... yikes. This is getting into…

The signature for scoped threads is both simpler and more complicated depending on how you look at it:

https://doc.rust-lang.org/stable/std/thread/fn.scope.html

But really, that first type signature is not very complex. It can get far, far, far worse. That’s just what happens when you encode things in types.

(It reads as “spawn is a function that accepts a closure that returns a type T. It returns a JoinHandle that also wraps a T. Both the closure and the T must be able to be sent to another thread and have a static lifetime.”)

Re: There is no memory safety without thread safety

#426
post #68

Earlier quoted context omitted.

Rust can yield a higher quality solution, but we can't make a perfect solution, we can only approach perfection. If we want to go further, we could introduce formally-proven code, too. Personally I'm interested in the intersection of proof assistants and Rust, like creusot-rs, and have been investigating it. But as much as I love LARPing about correctness (believe me I do,) it's just simply the case that we won't rig…

A lot of sass people i know are more and more choosing rust for boring code. This includes several people who said things like "go is good enough, i don't want to deal with all the rust completely". Once your sass products get enough users, and you're dealing with millions or billions of requests per day, those rare bugs start showing up quite often... And it turns out programming towards correctness is desirable, if…

> A lot of sass people i know are more and more choosing rust for boring code

It seems like you're in some kind of bubble, especially when looking at Rust usage in the industry.

> Once your sass products get enough users, and you're dealing with millions or billions of requests per day, those rare bugs start showing up quite often...

This is a blanket statement that's simply not true and I'm speaking as someone who uses Go in the exact scenario you described.

What kind of bugs are actually happening to these people? Do you have any real-world examples of the issues you're referring to, ones that suddenly start occurring only at the scale of millions or billions of requests per day to them?

Re: There is no memory safety without thread safety

#427

Earlier quoted context omitted.

...by that definition, can a C program be memory safe as long as it doesn't have any relevant bugs, despite the choice of language? (I realize that in practice, most people are not aware of every bug that exists in their program.)

This is way outside my domain but isn’t the answer: yes, if the code is formally proven safe? Doesn’t NASA have an incredibly strict, specific set of standards for writing safety critical C that helps with writing programs that can be formalized?

https://david-haber.github.io/posts/the-right-stuff/

Re: There is no memory safety without thread safety

#428
post #368

Earlier quoted context omitted.

> While you're wondering why I keep claiming Go is a memory-safe language, you can also go ask the ISRG, which says the same thing I am at And yet Go violates the definition they give -- it doesn't prevent out-of-bounds accesses. (And just to be sure we're talking about the same thing, I'm specifically talking about Go here. All the other languages on their list are actually memory safe, as far as I know.) > you have…

> So your definition of memory safety includes some notion of "plausible" and "realistic"? Neither https://www.memorysafety.org/docs/memory-safety/ nor Wikipedia have such a qualification in their definition. It would help if you could just spell out your definition in full, rather than having us guess. This is a strawman argument, you're arguing semantics here. You're a smart person, so you know exactly what he mean…

You definitely shouldn’t use Go, but it’s not because of the discussion in TFA. I jest, rhetorically.

Seriously, why are we bashing a researcher for being academic? This makes no fucking sense. Nobody claimed anywhere that people should stop using Go.

Re: There is no memory safety without thread safety

#429

Earlier quoted context omitted.

Unsafety in a language is fine as long as it is clearly demarcated. The problem with Go's approach is there no clear demarcation of the unsafety, making reasoning about it much more difficult.

The "go" keyword is that demarcation

“go” being a necessary keyword even for benign operations makes its use an unsafety marker pointless; you end up needing to audit your entire codebase anyway. The whole point of demarcation is that you have a small surface area to go over with a fine-toothed comb.

Re: There is no memory safety without thread safety

#430
post #166

Earlier quoted context omitted.

a segfault is completely unintentional. Had the kernel been older it could be used to execute code.

> a segfault is completely unintentional Usually, but not always! https://jcdav.is/2015/10/06/SIGSEGV-as-control-flow/

> Faulted trying to access 0x10 - the offset in the string we were trying to read from :)

Is guaranteed that every offset you can try to read is guaranteed to create a segfault?

Post reply on HN