Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no memory safety without thread safety

ralfj.de

Post reply on HN
Print view View original

411–420 of 517 posts

Re: There is no memory safety without thread safety

#411

Post by littlestymaar »

kllrnohj wrote: post #384
rurban wrote: post #327

Earlier quoted context omitted.

Which was the ultimate failure of Rust, because as Pony benchmarks have shown, you get safety and speed by proper security and architecture. Rust just survived by lying about the its safeties. What kills performance are not memory copies, but locks. Parallel nonblocking IO and a non POSIX stdlib will bring you far away from C++ or Rust performance.

> What kills performance are not memory copies, but locks. I'm pretty sure if every thread executing an LLM model had to have its own copy that that would murder performance more than any lock does, and it won't even be close. It's cheaper to copy than to lock when the data is small , but that does not scale and it also ignores things like reader/writer locks where the data is primarily read-only, at least during the…

> It's cheaper to copy than to lock when the data is small

Exactly this.

Re: There is no memory safety without thread safety

#413

Post by rurban »

littlestymaar wrote: post #410
rurban wrote: post #327

Earlier quoted context omitted.

Which was the ultimate failure of Rust, because as Pony benchmarks have shown, you get safety and speed by proper security and architecture. Rust just survived by lying about the its safeties. What kills performance are not memory copies, but locks. Parallel nonblocking IO and a non POSIX stdlib will bring you far away from C++ or Rust performance.

Oh yeah, the “ultimate failure of Rust”, and tell me how industrially successful Pony has been compared to Rust? (Don't get me wrong, I liked the idea behind Pony for backend code , it's much saner than Go for the same target space. But it failed to capture that market, because Go was already there. And it was never a competitor to Rust because this model is only viable for web back end tasks, not for general computi…

It isn't it a shame that the industry always falls for the liars?

The pony model was also better for compute tasks, not just IO. Because it provided safe concurrency, 10x faster than go.

Re: There is no memory safety without thread safety

#414

Post by camgunz »

I feel like I'm defending Go constantly these days. I don't even like Go!

Go can already ensure "consistency of multi-word values": use whatever synchronization you want. If you don't, and you put a race into your code, weird shit will happen because torn reads/writes are fuckin weird. You might say "Go shouldn't let you do that", but I appreciate that Go lets me make the tradeoff myself, with a factoring of my choosing. You might not, and that's fine.

But like, this effort to blow data races up to the level of C/C++ memory safety issues (this is what is intended by invoking "memory safety") is polemic. They're nowhere near the same problem or danger level. You can't walk 5 feet through a C/C++ codebase w/o seeing a memory safety issue. There are... zero Go CVEs resulting from this? QED.

EDIT:

I knew I remembered this blog. Here's a thing I read that I thought was perfectly reasonable: https://www.ralfj.de/blog/2021/11/18/ub-good-idea.html. Quote:

"To sum up: most of the time, ensuring Well-Defined Behavior is the responsibility of the type system, but as language designers we should not rule out the idea of sharing that responsibility with the programmer."

Re: There is no memory safety without thread safety

#415

Post by pclmulqdq »

zozbot234 wrote: post #345
blub wrote: post #341

Earlier quoted context omitted.

This comment highlights a very important philosophical difference between the Rust community and the communities of other languages: - in other languages, it’s understood that perhaps the language is vulnerable to certain errors and one should attempt to mitigate them. But more importantly, those errors are one class of bug and bugs can happen. Set up infra to detect and recover. - in Rust the code must be safe, must…

> ... it's understood that perhaps the language is vulnerable to certain errors and one should attempt to mitigate them. But more importantly, those errors are one class of bug and bugs can happen. Set up infra to detect and recover. > in Rust the code must be safe, must be written in a certain way, must be proven correct to the largest extent possible at compile time. Only for the Safe Rust subset. Rust has the 'uns…

A not-so-secret secret of Rust is that liberal use of 'unsafe' is pretty much required for certain classes of high-performance code.

Re: There is no memory safety without thread safety

#416

Post by J_Shelby_J »

blub wrote: post #341
socalgal2 wrote: post #257

Earlier quoted context omitted.

> But: everybody understands that. Everybody does not understand that otherwise there would be zero of these issues in shipping code. This is the problem with the C++ crowd hoping to save their language. Maybe they'll finally figure out some --disallow-all-ub-and-be-memory-safe-and-thread-safe flag but at the moment it's still insanely trivial to make a mistake and return a reference to some value on the stack or any…

This comment highlights a very important philosophical difference between the Rust community and the communities of other languages: - in other languages, it’s understood that perhaps the language is vulnerable to certain errors and one should attempt to mitigate them. But more importantly, those errors are one class of bug and bugs can happen. Set up infra to detect and recover. - in Rust the code must be safe, must…

> This leads to the very serious, solemn attitude typical of Rust developers.

Opposite really. I like rust because I can be care free and have fun.

Re: There is no memory safety without thread safety

#417

Post by dcsommer »

camgunz wrote: post #414

I feel like I'm defending Go constantly these days. I don't even like Go! Go can already ensure "consistency of multi-word values": use whatever synchronization you want. If you don't, and you put a race into your code, weird shit will happen because torn reads/writes are fuckin weird. You might say "Go shouldn't let you do that", but I appreciate that Go lets me make the tradeoff myself, with a factoring of my choos…

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.

Re: There is no memory safety without thread safety

#418

Post by aatd86 »

Why does it segfault? Because you have not used a sufficiently clever value for the integer that wouldn't when used as an address?

Just wondering.

Realistically that would be quite rare since it is obvious that this is unprotected shared mutable access. But interesting that such a conversion without unsafe may happen. If it segfaults all the time though then we still have memory safety I guess.

The article is interesting but I wish it would try to provide ideas for solutions then.

Re: There is no memory safety without thread safety

#419

Post by camgunz »

dcsommer wrote: post #417
camgunz wrote: post #414

I feel like I'm defending Go constantly these days. I don't even like Go! Go can already ensure "consistency of multi-word values": use whatever synchronization you want. If you don't, and you put a race into your code, weird shit will happen because torn reads/writes are fuckin weird. You might say "Go shouldn't let you do that", but I appreciate that Go lets me make the tradeoff myself, with a factoring of my choos…

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

Re: There is no memory safety without thread safety

#420

Post by pclmulqdq »

samus wrote: post #334
nicoburns wrote: post #324

Earlier quoted context omitted.

You are however replying to thread where a Dropbox engineer calls it "a right of passage" to introduce such bugs to their codebase. Which suggests that it is by no means unheard of for these problems to crop up in real-world code.

Doesn't Dropbox write a lot of Python extensions in C for speedup?

Excuse me, but in this thread we are bashing go, not making logical arguments.
Post reply on HN